How to buffer data written to PI AF Attributes to both members of PI DA collective?

Unless you are using custom data references, AFAttributes are based on the PI Point Data Reference, which means you get the same behavior writing to either. There is a minor difference if the AFAttribute is defined with a SourceUOM and the write command uses a different but compatible UOM. AF will perform a UOM conversion automatically, and then write the data to the PI Data Archive.

ONe, what you will need to do is to enable a Data Archive Tuning Parameter called Replication_EnableSDKWriteValues.

Two, you would need to have the PI buffering correctly configured on any/every Windows host running the AF SDK application.

Three, the AF SDK app should be sure to specify to use buffering, or rather, NOT to bypass buffering.

 The decision on AFAttributes versus PIPoints has nothing to do with the above. You should use which one is most appropriate for the nature of your application. If your app is Asset-based using an AFDatabase and AFElements, then obviously you should use AFAttributes - and by doing so they in turn will be using the PIPoint.

Hi Rick,

Thank you for your response. The tuning parameters are already set = 1, which I assume is the correct value.

Also, we specify AFData.BufferOption = AFBufferOption.Buffer globally in our program, and as the bufferOption parameter in our AFAttribute.Data.UpdateValues calls.

As this runs on my machine currently, we don't have PI Buffer Subsystem running, but I've been told that shouldn't be an issue.

Under these circumstances, would you normally expect the data to pass to both collective members' tags when writing to PI Point attributes?

If so, we have an issue where a PI SDK alias mapping the secondary archive to primary keeps resurfacing, even after manual deletion. Do you think this could explain why data is only passing to the primary's tags?

Hello gmalek​ ,

as mentioned in my response to your other recent question, please do not try to break the Known Servers Table (KST) of a PI Collective.

When creating a custom app, you usually do not need to think about if the receiving PI Data Archive is a standalone PI Data Archive or a PI Collective. PI Buffer Subsystem is your friend and helps you with a) Buffering, b) Fanning and c) Compression.

Buffering is performed through queues for each member of a PI Collective. If a member is down or otherwise unavailable, the queue will grow until it can be emptied again. Under normal circumstances, writes should be immediately performed. They go through the buffer queue but this should not result into data arriving delayed server side.

Fanning means that PI Buffer Subsystem takes care to update the time series data on all members of the PI Collective and a PI Collective can consist of a Primary and up to 99 secondary nodes. Another function performed by PI Buffer Subsystem is Compression. A 'compressed' marker tells the PI Snapshot Subsystem that the compression algorithm is already applied and this way it is ensured that all Collective members receive the same updates.

Please note that there is also Point locking involved. This means a PI Point which receives time series data through a PI Buffer Subsystem instance is locked against unbuffered writes. The only way to write a PI Point with a buffer lock is through PI Buffer Subsystem. With earlier PI versions, only a single PI Buffer Subsystem instance could own the PI Point. These days it is possible to write time series update through multiple sources but they must all be buffered.

Configuring PI Buffer Subsystem should be one of your first actions because PI Buffer Subsystem plays important roles (buffering, compression, fanning).

Without PI Buffer Subsystem, you will likely only be able to update the PI Point on the Primary.

With regards to the Tuning parameter Rick_Davin_3.0​ mentioned. Please do not allow writes on Secondary PI Collective members as this is usually not necessary as explained before.

Hi Gregor,

Thank you for your responses. Networking issues on our servers prevent us from obtaining external data at the moment, so we are trying to run the program from a client workstation as a temporary workaround. Correct me if I'm wrong, but I don't believe the PI Buffer Subsystem normally runs on client workstations. If this is true, then what is the appropriate way to write to both members of a collective when PI Buffer Subsystem is not available?

PI Buffer Subsystems should be configured on the client workstation if you are using the AF SDK. In general, the subsystem should be available anytime the workstation is online and if it can not reconned to one member of the collective, the data will queue. For a truly custom application, that does not use compression, and does require identical data to be written on both members, and goes against best practices, you could use PI CollectiveMember.Connect method. It sounds like you should configure buffering (takes about 2 minutes) and let AF SDK just work and not care if it is connected to a collective or not. In fact, if new members are added/removed then the buffer will resolve that for you.

Thank you - we don't have admin privileges to start PI Buffer Subsystem on the client workstations, but we have found a workaround in the meantime.

Ouch! You do have your hands tied. One workaround is to have the admins setup a PI Web API instance and have data buffered on that server.