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.
3 of 3 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!
1 of 1 people found this helpful
We finally implemented a series of ASP.NET Web APIs ( using AF SDK ) to support the handling of element versions.
It was NOT easy at all : the way AF SDK pick up a specific version , or a current version, and apply changes to a version ( i.e. changing a "Version Status" attribute ) is a bit tricky, but the rules are always the same.
One of the big discussions with development on enabling versions support in PI Web API was the indexing speed , and in general the increasing number of elements ( and related attributes ) in the AF Database , slowing down the whole query operations when reaching a certain number of elements.
We workarounded this issue creating two databases : HISTORIAN and REALTIME , and implementing an "Element Version Status" attributes to keep track of the lifecycle of an element.
Is where our Asset Development Process take place. We create Assets with their information ( attributes ) even in the development stage, and every single modification is recorded and traced creating new versions ( going through a management of changes procedure )
When an Asset in the HISTORIAN database is "Activated" ( as a result of a new or a change asset element process ) it is copied to the REALTIME database , overriding all previous information.
This means the REALTIME database contains only the "Active" status of the Digital Plant and can be used for real-time operations, while the HISTORIAN database maintain the whole Digital Plant history of changes and can be used for advanced analytics over historical data.
As there are no predefined functions in SDK to move an element from one DB to another, we had to write these APIs too,
I don't know if this is the best solution , but it was what my idea and seems working fine.
I have the same requirement and was wondering whether this thread has been changed or if you guys have a roadmap to know when we can expect some AF Elements version management with PI WEB API? Specially for Gregor Beck and Raymond Verhoeff or anyone who has some feedback on that.
Otherwise, I will need to plan some .NET development. By the way, I was also wondering whether there is any project to extend PI WEB API?
I am not sure why we did not suggest to post an enhancement request to add support for AFElement Versions to PI Web API at Uservoice but I have created one now. You may want to up-vote Add support for AFElement Versions and explain your use case in a comment.
Mahyar Sepehr wrote:
By the way, I was also wondering whether there is any project to extend PI WEB API?
I am a little uncertain what you are asking here. There is a team of developers actively working on maintaining and enhancing the PI Web API. Other than this, PI Web API is not open source and to my knowledge, there are no plans to make it open source. For this reason, a community project to extend PI Web API is currently not an option. Does this answer your question?