Understanding Data Paths in PI Web Services: "PI:\..." vs "AF:\..."

PI Web Services has long provided a robust interface for integrating OSIsoft PI System data into .NET applications and web services. When dealing with different data paths and interfaces—especially with a PI System as richly architected as today's—engineers and developers often find themselves needing to understand the nuances between similar-appearing but fundamentally different code paths. This article explains the distinctions between "PI:\..." and "AF:\..." code paths in PI Web Services 2012, delving into their underlying mechanisms and implications for data writing, buffering, and system architecture.

Brief Overview of PI Web Services 2012 Architecture

PI Web Services 2012 is a .NET 4-based application that ships with the AF (Asset Framework) Client 2012. This means it leverages the AF SDK RDA (Remote Data Access) for many operations. PI Web Services interacts with multiple components to read and write data, including PI SDK, AF SDK, PI OLEDB Provider, and PI OLEDB Enterprise.

"PI:\..." vs "AF:\..." Data Paths for Writes

PI:\... Path

When you use a path prefixed with PI:\\... in methods like InsertPIData, the write is directed straight to the PI SDK. This approach bypasses the PI OLEDB Provider. Importantly, using the PI SDK allows the write operation to interact directly with the PI Buffer Subsystem (PIBufss). This subsystem enables data buffering and fanning—critical for high-availability scenarios where you're writing to a PI Collective. Data sent via this method can be buffered and fanned to multiple PI servers in a collective environment, improving data reliability and consistency.

AF:\... Path

When using the AF:\\... prefix and targeting an Attribute with a PI Point Data Reference (DR), the process looks a bit different on the surface:

1. Attribute Resolution: The AF SDK first resolves the AF Attribute to retrieve the underlying PI Point (tag).
2. Write Operation: Once resolved, the system still uses the PI SDK to perform the actual write to the PI Data Archive. That means the same Buffer Subsystem and data fanning mechanisms are in play, ensuring parity with the direct PI path.

This architecture ensures that, for writes, both PI:\\... and AF:\\... approaches ultimately channel through the PI SDK and benefit from buffering and fanning—even though the initial entry points differ.

Underlying Data Access Methods

• PITimeSeries Methods: These use PI SDK and AF SDK exclusively.
• PISoap Services: Here, things diverge:
  • For Event Frame search/retrieval, PI Web Services utilizes the AF SDK directly.
  • For searching AF Elements, Templates, and Attributes, the PI OLEDB Enterprise Provider is employed.

This division reflects the capabilities of the underlying providers at the time PI Web Services was developed.

Why Does This Matter?

Understanding these distinctions is critical for system architects and integrators who need to ensure:

• Writes are buffered/fanned for high availability.
• Your application leverages the correct backend components for performance and reliability.
• You avoid data inconsistencies that could arise from misunderstanding the code path mechanisms.

Key Takeaways

• Both PI:\\... and AF:\\... paths leverage PI SDK for writes to PI Points, enabling buffering and data fanning, even though their entry points might suggest otherwise.
• PI Web Services uses a mix of PI SDK, AF SDK, and OLEDB Providers, depending on the operation.
• Knowing which path your application follows allows you to troubleshoot, optimize, and future-proof your PI System integrations.

By understanding the nuances of these code paths, you can develop more resilient, efficient, and consistent integrations with OSIsoft PI System.