Troubleshooting Web Service Delivery Endpoints in PI Notifications: Lessons from the Field

Adding new delivery endpoints to a large number of existing PI Notifications can be a powerful way to extend your notification capabilities. However, automating such changes via code—versus using the PI System Explorer interface—can sometimes expose subtle issues, especially with older PI Notifications systems. In this post, we’ll explore a real-world scenario involving integration of Web Service endpoints in PI Notifications, common pitfalls to watch for, and best practices to ensure robust integrations.

The Scenario: Automated Updates and Unexpected Errors

A user working with PI Notifications 2012 (version 1.2.1205.10) needed to add a new Web Service delivery endpoint to over 1,000 notification instances. While this automation saved considerable manual effort, an “Object reference not set to an instance of an object” error started appearing when notifications tried to send data to the web service. Notably, notifications configured to send static values worked fine—problems only arose when notifications passed dynamic attribute values to the endpoint.

Key aspects of the scenario:

• PI Notifications version: 2012 v.1.2.1205.10
• Web service endpoint added directly to notifications via AFSDK code
• Attribute values set to be sent via the endpoint
• ContentType sometimes left blank instead of set to OSIsoft.AF.Notification.AFNotificationContent
• Exported XML looked correct after manual intervention via PI System Explorer

Diagnosing the Root Cause

The symptoms—success with static values but failure with attribute-based dynamic content—pointed toward how parameter bindings were being made in code. The following common issues emerged from the investigation:

1. ContentType Misconfiguration:

   • Dynamic attribute values require a specific ContentType (OSIsoft.AF.Notification.AFNotificationContent) to be set in the web service parameter configuration. Leaving this blank can cause the endpoint to fail to resolve the expected data.

2. Template vs. Instance Configuration:

   • When notifications are created from templates, updating only the instance may not be sufficient. Best practice is to update the contact or endpoint at the template level when possible to avoid inconsistencies.

3. Differences after Manual Update:

   • Editing the endpoint in the PI System Explorer UI (removing/re-adding the attribute) seemed to fix the issue, suggesting there was a subtle difference in how the content objects were instantiated or bound by the UI versus code.

4. Version-Specific Bugs:

   • Even though configured correctly, issues persisted in some endpoints, possibly due to known product bugs (referenced as bug 12325), even in later service packs.

Key Takeaways and Best Practices

1. Always Specify the Content Type

When adding attribute-based parameters to a web service endpoint in PI Notifications, ensure the ContentType is set correctly. For dynamic AF Attribute values, use:

ContentType="OSIsoft.AF.Notification.AFNotificationContent"

2. Code versus UI—Export and Compare

After making automated changes, export your notification or contact configuration to XML both before and after manual intervention via the UI. Compare the exports to identify subtle differences the UI may introduce to fix binding or instantiation issues.

3. Prefer Templates When Possible

If you use notification templates, always update endpoints and contacts at the template level. Instance-level changes may not propagate correctly or may introduce inconsistencies—especially in older versions.

4. Upgrade and Patch

Many older versions of PI Notifications contain bugs related to endpoint configuration and dynamic content. Check for known issues on the OSIsoft tech support portal and plan upgrades or apply patches when such issues are encountered.

5. Tech Support is There to Help

If all else fails, OSIsoft PI Tech Support is an excellent resource for troubleshooting these nuanced, version- and configuration-dependent issues.

Example Code for Proper Web Service Endpoint Configuration

Below is a general approach for adding a web service endpoint with correct attribute binding through AFSDK:

var notificationContact = notification.NotificationContacts.Add(contactTemplate);
var contentToSend = ANNotificationContentHelper.CreateAttribute(notification, attribute);
contentToSend.NotificationContacts.Add(notificationContact);

string parameterXml = @"<Parameters>
    <myAttribute ParameterType='System.String' DisplayName='{DisplayName}' ContentType='OSIsoft.AF.Notification.AFNotificationContent'>{AttributeGuid}</myAttribute>
</Parameters>";

notificationContact.ConfigString = "WebServiceMethodParameters=" + parameterXml;
notification.CheckIn();

Make sure you substitute {DisplayName} and {AttributeGuid} with your actual attribute’s display name and GUID.

Conclusion

Automating PI Notifications configuration is a time-saver but requires a keen understanding of the interactions between notification templates, contacts, and parameter content types. Always specify content types for dynamic attributes and validate changes via both code and the PI System Explorer UI. And when mysterious errors persist, don’t hesitate to reach out to PI Tech Support—they’ll help you bridge the gap between code and reliable operations.

— Have you encountered similar issues when automating PI Notifications or other OSIsoft PI configurations? Share your stories and solutions in the comments below!