I recently stumbled upon an issue I would like some insights from the experts on..
It looks as if the way the AF SDK returns retrieves data from AF and sources differs depending on the type of source.
It seems that if you query for attribute value that referrers a PI tag the locally running AFSDK client instance in reality gets a reference to the PI tag, after which the AFSDK itself connects to that PI server and than retrieves the data.
(this behavior can be verified by using a port blocker to block the PI server port 5450 and fire up the AF explorer) ) .
The behavior for other/relational sources is more as expected: data access is done via AF server and it security mechanism.
Following picture is a ‘standard’ setup of an AF implementation and a description of the challenge.
I see the following issues with this behavior:
1. No ‘real’ data federation/virtualisation where all data access goes via the AF layer, this violates one of the key attractions of AF.
2. (Possibly) conflicting security mechanisms between AF security and client-to-PI security
3. IT infrastructure challenges due to :
a. configuring PI servers for clients since a consumer of an asset model in AF does not per-se need to be aware of the underlying sources
b. Network setup in enterprise environments.
Assuming my assessment is right (please tell me it is not …)
The solution to this challenge is quite easy: I ask OSIsoft to offer us a PI Point datarefence that uses the same security mechanism and data access pattern as the table lookup data reference