Feature Request
We are requesting support for direct connectivity from the Adapter to PI Data Archive servers/collectives using the AF SDK, as an alternative to the current PI Web API/OMF-based architecture.
Problem
The current Adapter framework for on-premises deployments has a hard dependency on the PI Web API. Deploying the PI Web API requires an AF Server and SQL Server to be available, which introduces significant infrastructure and configuration overhead simply to deploy and configure a PI Adapter.
There is also a significant limitation when working with environments that contain multiple PI systems. OMF can only be configured to write data to a single PI Data Archive server or collective. This makes the current architecture unsuitable for organizations where data is distributed across multiple PI systems.
For example, an organization may have:
With the current OMF architecture, a single Adapter configuration cannot write to both PI systems. Supporting this scenario requires additional Adapter/OMF configurations and associated infrastructure, increasing deployment and operational complexity.
Requested Enhancement
Provide the ability for an on-premises Adapter to connect directly to and write data to a specified PI Data Archive server or collective using the AF SDK, without requiring the PI Web API, AF Server, or SQL Server as intermediary components.
Ideally, the Adapter configuration would allow users to specify the target PI Data Archive/collective and support multiple independent PI targets within the same deployment.
Benefits
Direct AF SDK connectivity would:
Eliminate the dependency on the PI Web API, AF Server, and SQL Server.
Significantly simplify on-premises deployment and configuration.
Reduce the infrastructure footprint required to deploy an Adapter.
Support environments with multiple PI systems and collectives.
Allow data to be routed to the appropriate PI system based on the organization's existing PI architecture.
Provide a more natural integration model for on-premises PI Data Archive environments.
This capability would make the Adapter framework substantially more flexible and practical for enterprise environments where multiple PI systems are already deployed and data is intentionally separated across those systems.
Another possible remedy would be to have the PI system read OMF directly and connect over a port other than 80/HTML. This seems like a more natural fit. If OMF is to be the ingress choice of the future it seems like it should have a direct connection.