Understanding PI Web API WebID Encoding: Can You Generate WebIDs Client-Side?

The PI Web API has become an indispensable tool for many organizations looking to access and manage data from their PI System in an efficient and programmatic way. One of the core concepts when working with the PI Web API is the WebID, a compact, URL-safe identifier that uniquely represents PI System objects, such as elements, attributes, event frames, and points.

A question often arises among PI System developers: Is it possible to manually generate a WebID from an object's GUID or path, thereby avoiding an extra API round-trip? The answer is nuanced, and in this post, we'll shed some light on how WebIDs work, their encoding mechanisms, and the current state of documentation and support for client-side generation.

What is a WebID?

WebIDs are unique identifiers designed by OSIsoft (now part of AVEVA) to efficiently reference objects within the PI System, especially when interacting via the PI Web API. They play a crucial role in optimizing performance, supporting batch requests, and enabling stateless client-server interactions.

WebIDs incorporate key information about the PI System object, such as:

• The type of object (Element, EventFrame, Attribute, Point, etc.)
• The object's path or GUID, depending on the encoding type
• The system identifier

WebID Generation and Encoding

There are several different WebID formats, including the original and the newer "WebID 2.0" encoding introduced in PI Web API 2017 R2. WebIDs are generally constructed using a combination of base64-encoded data and a type prefix.

For example:

• WebID 2.0 can be generated using either the object's GUID (Global Unique Identifier) or its path. The encoding is designed to be compact and safe for use in URLs.

However, the exact algorithm for encoding a WebID is not fully documented for public use. While the underlying principles—such as base64 encoding and the usage of GUIDs or paths—are known, the precise steps necessary to match the server's encoding and validation logic have not been openly published.

Why Can't I Just Encode WebIDs Myself?

Several challenges prevent straightforward client-side WebID generation:

• Guid Volatility: If you delete and recreate a PI object, its GUID changes, making previously generated WebIDs obsolete or incorrect.
• Undocumented Algorithms: Except for some basic hints in official documentation or forum posts, the detailed WebID 2.0 algorithm hasn't been published. OSIsoft stated in the past that this information would be included in the documentation, but as of the latest updates, it's still under review.
• Potential for Change: The encoding scheme may evolve with future releases, so relying on any unofficial or reverse-engineered method could lead to brittle applications.

Current Best Practices

If your application workflow involves repeated lookups of the same PI System objects, here are some recommended practices:

1. WebID Retrieval at Initialization: Retrieve all needed WebIDs when your application initializes, then cache and reuse them for subsequent requests.
2. Batch Calls: Use PI Web API's batch endpoint to decrease the number of roundtrips when querying multiple objects by path at once.
3. Storage/Caching: Store WebIDs locally with their associated metadata, planning for periodic refreshes in case of system changes.
4. Contact Technical Support: If you absolutely must generate WebIDs client-side, contact OSIsoft/AVEVA Technical Support. For certain WebID types, they may provide guidelines or documentation on generating them in client code. This is more likely for use cases where network constraints make round-trips prohibitive.

Feature Suggestions and the Path Forward

A common feature request is to allow passing WebIDs as parameters in other PI System subsystems, such as AF Notifications, to streamline event-triggered workflows. While not currently supported natively, such ideas are valuable feedback for the product roadmap.

Meanwhile, keep an eye on the official PI Web API documentation and user forums for updates on WebID generation. As soon as the relevant details are published, PI System developers will be better empowered to handle WebIDs client-side where appropriate.

Summary

• WebIDs are critical for efficient PI Web API usage, encoding object identity and type.
• The exact client-side encoding process for WebID 2.0 is not yet publicly documented.
• For now, best practice is to retrieve and cache necessary WebIDs using the PI Web API, or use batch endpoints for efficiency.
• Always consult with OSIsoft/AVEVA Technical Support before attempting to generate WebIDs manually to ensure compatibility and supportability.

References:

• PI Web API Documentation
• OSIsoft Community Forums

Do you have experience or tips for working with PI WebIDs, or are you waiting for client-side documentation? Let us know your thoughts in the comments!