• State Verified Answer
  • Replies 1 reply
  • Subscribers 2 subscribers
  • Views 71 views
  • Users 0 members are here
Options
Related

Are PI Points better than AF Attributes for writing bulk values?

gmalek

We're trying to integrate time series data from an external Web API into our PI System. Our current program design is to search for AF Attributes (PI Point DR) that will receive outputs, then write a rolling time range of data to each attribute (so multiple values per attribute).

 

I see the PIPoint class has two bulk-write methods - PIPoint.UpdateValues and PIPoint.ReplaceValues, but the AFAttribute class only has AFAttribute.SetValue, which is not a bulk method.

 

Is there a reason not to write to the attributes' PI Points rather than the attributes themselves? The only reason I can think of is there may be a very small performance penalty for retrieving the attributes' PI Points before the write. I imagine this would be a negligible trade-off for large amounts of attributes and/or data.

Parents
  • 0

    The AFAttribute has a Data property which is an AFData class object. It is the AFData object that has bulk methods you want to use:

     

    AFData.UpdateValues overload

    By bulk here, we mean a single AFAttribute may update many of its values in one RPC calls. Note: this method is also used to delete values in bulk.

     

    If you have many AFAttributes and you wish to update value(s) for each, then you would need to use an AFAttributeList and its Data property, which is an AFListData object. which has its own UpdateValues overloads.

     

    When updating an individual AFAttribute, the Attribute property on the AFValue(s) can be null. However, when updating an AFAttributeList, it is critical to have the Attribute property on each AFValue correctly set. This is similar behavior when working with PIPoint, PIPointList, and the Point property on the AFValue.

     

    With that all said, AFAttribute(s) do have similar bulk update methods just like PIPoint(s).

     

    If you are dealing with an AFDatabase, then I would suggest using AFAttributes is the preferred way to go. I see no concern in your last paragraph, but you can retrieve PIPoints in bulk by using the AFAttributeList.GetPIPoint method, though I see no reason to call it.

     

    Another very small performance hit might be if a UOM conversion is needed, that is where the AFAttribute's DefaultUOM differs from its SourceUOM. This again is very negligble and if a UOM conversion is needed, then it should not be avoided.

     

     

Reply
  • 0

    The AFAttribute has a Data property which is an AFData class object. It is the AFData object that has bulk methods you want to use:

     

    AFData.UpdateValues overload

    By bulk here, we mean a single AFAttribute may update many of its values in one RPC calls. Note: this method is also used to delete values in bulk.

     

    If you have many AFAttributes and you wish to update value(s) for each, then you would need to use an AFAttributeList and its Data property, which is an AFListData object. which has its own UpdateValues overloads.

     

    When updating an individual AFAttribute, the Attribute property on the AFValue(s) can be null. However, when updating an AFAttributeList, it is critical to have the Attribute property on each AFValue correctly set. This is similar behavior when working with PIPoint, PIPointList, and the Point property on the AFValue.

     

    With that all said, AFAttribute(s) do have similar bulk update methods just like PIPoint(s).

     

    If you are dealing with an AFDatabase, then I would suggest using AFAttributes is the preferred way to go. I see no concern in your last paragraph, but you can retrieve PIPoints in bulk by using the AFAttributeList.GetPIPoint method, though I see no reason to call it.

     

    Another very small performance hit might be if a UOM conversion is needed, that is where the AFAttribute's DefaultUOM differs from its SourceUOM. This again is very negligble and if a UOM conversion is needed, then it should not be avoided.

     

     

Children
No Data