Unfortunately we really need a new element version in such cases as we are talking about a modification of the asset element that contains a series of different informations and relations than the previous.
In R&D this is a frequent operation we need to monitor and track as new versions.
The Audit Trail is useful to see the attribute changes within that version of the asset.
As the process of creating an asset element modification ( new version ) came from another procedure / system we would like to trigger this creation from the 3rd Party web application via a Restfull service call .
So, in practice, we cannot do that , right ?
No, the recent version of PI Web API doesn't support versioning of AF Elements. Could you maintain version information in AF Attributes as suggested byRhys Kirk?
Even Asset Framework generally supports versioning, there's only very few products supporting not only because of the performance impact mentioned by Stephen Kwan in the other thread but also because it makes things way more complicated.
Hello Raymond Verhoeff: Are there any plans supporting AF Element versions with future releases of PI Web API?
The Rhys suggestion doesn't actually fit the requirement. Element Versioning seems complicated but is exactly what we need : a whole new element must be created and the old one kept in the database .
One of the reason we moved to PI AF is the element versioning capability.
2 of 2 people found this helpful
Yes, we are making plans to support access to AF Element versions. This would include the ability to create new versions with a REST call. There's some research under way.
This is great!
Just resuming what I was mentioning in the previoius posts :
I'm working in a business where asset changes are performed in a daily basis , and versioning is the only way to keep track and quickly compare the changes with real time process data. Versioning is a must in a controlled environment.
After several tests on working with Element Versions I went out with the following statements, please feel free to comment on that :
- In order to keep track of relationship between real time data and their correspondent metadata stored in AF Element Attributes at a certain point in time the only simple solution is to create a new Element Version when this metadata changes. Another solution is to create a PI Point for every attribute that can be potentially altered during the asset change ( extremely expensive ).
- Element Versioning impact heavily in the database size as every new version is a new element ( new id ), but this depends on the size of the elements and the kind of data recorded on it
- Only PIAF SDK has methods to works with element versions, PI WEB API doesn't actually expose versioned elements but only the ones responding to default behaviour ( there is a bug in 2016R2 where PI Web API and PIAF SDK searches retrieves different element versions from the same query : PI Web API always show the latest one , or none )
- Enabling Audit Trail ( supported only by the Enterprise versions of MS SQL Server ) give you the ability to record all the changes in the elements and attributes, it will also heavily impact the database size and performance, but doesn't satisfy requirements in statement 1 until you use versioning too.
Our current idea is to keep one AF database as element historian, and one AF database for realtime where only "active" element versions are kept.
When we activate ( we have a configuration attribute "Status" for that ) one Element Version in the AF Historian it will be transferred to the AF Realtime database overriding the existing one.
In this way if we want to make historical comparision between realtime data and metadata we will use the AF Historian Database, otherwise we will point to the AF Realtime database with the Active data.
One of the pending issues is still the simplicity of getting and writing AF Element Versions with the web interfaces, PI Web API are not yet supporting element versions and we are looking forward to have that functionality.
Thanks for your comments,
You can create a custom ASP.NET Web API project with PI AF SDK and then create actions in order to create new element versions. I would continue to use PI Web API for the majority of the HTTP requests and use this custom RESTful web service just for this purpose. By the time this feature is added to PI Web API, you could stop using this custom application. You will have only to update the client code.
Please let us know if you have more questions!