PI Server endpoint point naming for OSIsoft Message Format payloads

Blog Post created by gmoffett Employee on Apr 22, 2019



This post describes point naming behavior by the PI Connector Relay when sending OSIsoft Message Format (OMF) messages to the PI Server and an early look at the current expected behavior for the PI Web API - that will include OMF support in an upcoming version. Worth mentioning that OMF messages can also be sent to Edge Data Store and OSIsoft Cloud Services, however these endpoints are not covered in this post.




Point name is defined by two steps, and possibly a third depending on the OMF type definition.


1. Configuration for OMF applications using PI Connector Administration - documentation: OSIsoft Live Library


This step includes defining an OMF application name, the application name is used as the point prefix, for example: Device2


2. OMF application container definition


Using the example from OSIsoft Message Format (OMF) - what to type? one of the defined types is:

with a container definition:



"id": "Asset2.Temperature",
"typeid": "stream-number"


This container id, specified in the container definition is appended to the point prefix with a period separator: e.g.: Device2.Asset2.Temperature


3. Behavior of the PI Connector Relay


Depending on how you have defined your type, will determine if this third "step" of adding a suffix to the point name is applied. There are two scenarios:


a) The type definition contains one data property: point name is the prefix and container id


Following through with the example above, steps to determine the point name:

1. OMF application name: Device2
2. Container name: Asset2.Temperature

3. Behavior of Relay: no change, since the type definition only has one non-index property, i.e.: value


Point name: Device2.Asset2.Temperature


b) The type definition contains two or more data properties: point name is the prefix, container id and the type property definition name


Using another example from OSIsoft Message Format (OMF) - what to type? the following type:



has two non data properties: latitude and longitude, and container definition:


"id": "Asset2.Location",
"typeid": "gps-coords-dd"


Again, using the three steps here to determine the point name:


1. OMF application name: Device2

2. Container name: Asset2.Location

3. Behavior of Relay: will add type property definition names


Point names:





Ok, why are you telling me this?


1. People are asking...

2. Upcoming release of PI Web API, will include support for OMF messages and as currently planned will introduce two changes compared to the Relay in relation to point naming:

  • Point prefix defined using PI Connector Administration (in step 1) will no longer be supported
  • The property name will always be added to the container name as per the OMF specification, i.e.: ContainerID.PropertyName

For the examples above, when sending via the PI Web API the point names would be:

Asset2.Temperature.value (this would be Asset2.Temperature using the PI Connector Relay)

Asset2.Location.latitude (no change, compared to Relay)

Asset2.Location.longitude (no change, compared to Relay)