1 of 1 people found this helpful
You can find information on WebID here in following section of the user guide: https://livelibrary.osisoft.com/LiveLibrary/content/en/web-api-v1/GUID-0857C3F0-8A4F-4EE7-8E24-ECE4F4DEDD3A From there you can see that "PI Web API decodes the WebID and finds the object's unique ID along with the object's path"
In terms of AF attribute with the PI Point Data Reference:
- a change to the attribute name will cause the WebID to change - Yes, this is correct, WebID of the attribute will be changed in this case. Element name change will also affect attribute WebID. Renaming attribute will not change Element WebID.
- a change to the tagname in the PI point reference will not cause the WebID to change - Attribute configuration does not affect WebID. If you change the tag in the PI Point Data Reference or rename it it will not affect AF Attribute WebID. In short - this is correct
Please let me know if it answers your question.
This is what I needed confirmed - Thanks.
Bruce C. McCamant
TSI Group, Inc.
Sent from my iPhone
Please see WebID for the relevant place in the documentation.
I have tested the behavior, please see the relevant pieces below:
Attribute before name change
Attribute after name change
Please note that the Attribute ID remains the same. The name change results into a path change which causes the changed WebID.
.. but you can still use the "old" WebID to find the Attribute!! This is because the WebID has an objects unique ID and the Path information. PI Web API first attempts to resolve by ID and if this fails by Path. For your use case, the ID doesn't change and hence, even the WebID has changed, the Attribute will be resolved by ID with the first attempt.
If you delete and re-create an Attribute and the re-created Attribute has the exact same name, the ID will be a new one but the Path remains the same and on second attempt, PI Web API will find your Attribute. Only if you delete an Attribute and chose a different name for the re-created Attribute, PI Web API will not be able to find it by the "old" WebID.
The next PI Web API release will introduce WebID version 2.0. I don't know any details yet but the new algorithm is supposed to generate shorter WebID's. The current WebID 1.0, if you like, will remain intact a few versions down the road.
Thanks to both of you for your timely responses.
OK - things are not OK apparently with Web API 2017R2.
We have a customer app using MQ to retrieve PI data via the PI Web API. We upgraded the Web API on Tuesday of this week and confirmed everything was working. We received no notifications of any processes failing.
We had an incident this morning where the Web API could not reach one of the AF servers it had been using for an extended period (February of 2016). In turn their queries were failing. We have pretty much left AF database/element/attribute naming alone for the target AF database - only adding new attributes. They have only had to update their cache for the new additions. This morning after restoring access to the AF database in question, the MQ admin discovered that the WebIDs had changed.
1 of 1 people found this helpful
WebID (1.0) encodes object ID's and object path. When referring an object by WebID, PI Web API tries to resolve the object by its ID (decoded from the WebID) at first attempt and if this fails, the second attempt is to resolve the object by its path. Changed WebID's indicate a change. Could be that the object ID or its path or both has changed. Changed WebID's do not necessarily indicate a problem. If either the object ID or the path of the object is intact, PI Web API should be able to resolve the object. If a stored WebID does not resolve at all, this indicates that both WebID and path have changed.
Can you tell what exactly was done to restore access to this AF Server instance?
If the database was restored from an XML Export, this will have caused new object ID's and hence WebID's may look different now but if the WebID's do not resolve, this indicates that object paths have also changed e.g. if the AF Server name or AF Database name has changed.
PI Web API 2017 R2 introduces WebID 2.0 which can be generated at runtime. There are a few resources already in the forums for WebID 2.0 but I recommend starting with Using PI WebID 2.0 in PI Web API.
Gregor - first to re-affirm
- no content changes were made - path, names
- No AF server was restored
We upgraded on a Tuesday to 2017R2 - WebAPI, AF, Archive, etc. For four days everything worked as advertised with MQ using its cache of v0 WebIDs Then that evening we encountered a number of 'disturbances' where connections between various PI components say interruptions that left open sockets, etc. We only restarted services and/or servers to restore connections, but the MQ queries continued to fail. When the MQ resource connected via browser and queried the PI WebAPI he discovered the webIDs had changed. He updated the cache and we started a case with Tech Support.
Working with the engineer we discovered that the queries now returned v1 webIDs. We were told that this version was supposed to honor both v0 and v1 webIDs, but this obviously is not the case here. We will continue to test this, and we are going to look at the newer features of the PI WebAPI to see if they can use them to prevent future occurrences.
Thank you for the update! I see your Technical Support case is still open. I am curious about the case resolution and will monitor it.
1 of 1 people found this helpful
Web ID 2.0 (version number '1' as shown at the second character of the new Web IDs) was introduced in PI Web API 2017 R2 to address some shortcomings of version 1.0. One of the benefits is that the new version supports five types compared to only one type in the old version. The five types are:
The first three types are commonly used, while the last two types are used for very special use cases. As their names suggest, "Full" type encodes both ID and Path information, "IDOnly" type encodes only ID information, and "PathOnly" type encodes only Path information. Since "IDOnly" type doesn't include Path or name information into the Web ID, it is usually much shorter and, more importantly, it provides a solution to the challenge you might have as shown in your first post in the thread: Can we keep the Web IDs unchanged even when the element/attribute/pi tag names are changed, so that they can be safely used as cache keys?
A new URL parameter "webIdType" was introduced for nearly every "GET" endpoint. A global run-time configuration setting "WebIDType" was also added in the PI Web API configuration database to provide the default Web ID type when the "webIdType" parameter is not specified.
In PI Web API 2017 R2, 2017 R2 SP1 and upcoming 2018 releases, a partial backwards compatibility is supported for the old Web ID version, i.e.
- The old version Web IDs can be used in the requests (the URL or the body of a Batch request).
- PI Web API only return the new version Web IDs in the response.
In 2018 R2 release, we plan to add full support of the old version Web IDs, i.e. PI Web API can return the old version Web IDs as well as the new version.
I hope this post can help clarify some confusions. If you have further questions, please let me know.
In regards to Web ID 2.0, Christopher Sawyer has some interesting posts: