Hi community members!
Is that possible to get AF attribute value type in the code of custom data reference? Maybe it is stored in context variable in GetValue, GetValues overriden functions or somewhere else.
Here is my thought. It is possible.
The Attribute property of the AFDataReference is only set AFTER the instance is created. (The docs suggest that the set method can be overriden to perform any initialization that is necessary but you wouldn't want to do that since you want the value type that the user has set in PSE)
Then Values with an IsGood status of true accessed through the GetValue Overload and SetValue Overload methods will be converted to the type of AFAttribute.Type.
This implies the type is set by AF SDK at the beginning.
Consequently, it means that you can access it via the AFDataReference.Attribute.Type property after the AF SDK has populated the Attribute property.
Ok, thanks for explanation!
Actually the value type of an AFAttribute or an AFAttributeTemplate is easily retrieved inside a CDR. A CDR has 2 properties where one of which is null and the other is not null: Attribute and Template (here template refers to AFAttributeTemplate).
Type defaultType = Attribute?.Type ?? Template.Type;
Type defaultType = (Attribute == null) ? Template.Type : Attribute.Type;
Template can't return data values but Attribute can. Keep in mind that if a returned AFValue IsGood, then it must match the default type. If the AFValue is not good, then it might be a SYSTEM digital state but for a CDR does not have to be. The CDR may return an Exception as the AFValue for instance. If your CDR has the potential to return floating point NaN's, there is a caution. Formula's and Analytics consider a NaN as bad via the IsBad function, but summary calls may treat them as good since a double.NaN is a double, and a NaN considered good in an average makes the whole average NaN. This behavior depends on each data reference. As an aside, the PI Data Archives prior to 2012 could store and return NaN, and because the NaN matched the point type the NaN was considered good. With 2012, NaN's were changed to be digital state 317 Invalid_Float, and therefore considered bad.
I have seen DR's that alter the default type of the attribute or template definition. I personally despise this practice. But reading the default type to change how you output a value is a good practice. For instance, let's say I have a CDR to return a timestamp. If the attribute type is DateTime, I would return a DateTime. If the type was Double, I would return the UtcSeconds. If it was a long, I would return the Ticks, and so on.
Retrieving data ...