The following summarizes key behaviors and recommendations for using PI SDK buffering with existing PI SDK applications.
Changes to Consider for Existing Applications
Existing custom PI SDK applications will continue to work without changes when you upgrade to PI SDK 2010 R2 or later. However, to get the maximum benefit from the upgrade, OSIsoft recommends that you plan to make the following changes at your earliest convenience:
You can both simplify and enhance applications that currently connect to specific PI collective members using
MemberOpen by modifying them to use
Server.Open instead. This change allows PI Buffer Subsystem to send updates to all active collective members, which is not possible using
MemberOpen is used, data is written to only one specified collective member. In addition, if a collective's membership changes,
Server.Open continues buffering to active collective members without further changes to the application.
For the best possible performance, separate threads for direct calls to the server from threads for calls that write data to the local buffer subsystem. This prevents delays related to writing data from affecting other types of operations.
PI to PI and PI SDK buffering
Before PI SDK buffering became available, PI to PI was one of the recommended options for copying PI SDK data among members of a collective. Starting with PI SDK 2010 R2, OSIsoft recommends using PI SDK buffering, not PI to PI, to distribute data among collective members.
OSIsoft does not recommend implementing PI SDK buffering on an existing system that uses PI to PI. Under the following circumstances, PI SDK buffering and PI to PI will both attempt to write the same data to the non-primary members of a collective:
A PI SDK application writes only to the primary server in the collective
PI to PI is used to write data to the other (non-primary) collective members