1 Reply Latest reply on Aug 16, 2013 1:08 PM by Bhess

    "PI:\\..." and "AF:\\..." code paths in PI Web Services

      Need some clarification.


      PI Web Services 2012 ships with AF Client 2012, and PI Web Services is a .Net 4 application. So we have AF SDK RDA under the hood, right?


      When I'm using the InsertPIData method if I supply a path prefixed "PI:" then the call is passed directly to PI SDK, bypassing the PI OLEDB Provider, that (if configured) passes the data to the PI Buffer Subsystem that in turn writes the value to the PI Collective, and fans to a PI Collective (assuming I am not writing to multiple PI Collectives whereby only 1 PI Collective is buffered/fanned). Now if I issue the same call via a path prefixed "AF:" pointing at an Attribute with the PI Point DR (configured with the same tag from the PI: path), then that gets passed directly to the AF SDK so that value is not buffered/fanned (AF SDK limitation) because it uses RDA and not PI SDK. Is that correct?


      The prefix you choose for ultimately the same PI Point can lead to 2 different code paths and update the same data differently/inconsistently, i.e. the "PI:" prefix will ensure data fanning when working with a PI Collective.


      Data reads from PI & AF are both serviced by the PI OLEDB Provider & PI OLEDB Enterprise Provider respectively, correct?


      (Edit: Posted this in the wrong forum, can someone move it to the Web Services forum?)

        • Re: "PI:\\..." and "AF:\\..." code paths in PI Web Services



          Actually when writing to an 'AF:' path, we initially resolve a PI Point Data Reference to the underlying tag, and cache that value.  The PI SDK is then used for the write, so buffering and fanning should work equivalently for both paths.


          In terms of the underlying data access mechanisms:  for the PITimeSeries methods, the PI SDK and AF SDK are used exclusively.  For the PISoap services, the AF SDK is used for Event Frame search/retrieval and PI OLEDB Enterprise is used for AF Element/Template/Attribute search and retrieval.  The reason for the difference is that the OLEDBE Event Frame capabilities were not yet complete when we began developing the Event Frame capabilities in PI Web Services.


          Hope this helps!


          Brad Hess


          PI Web Services Team