The Browsing Session

In order to access the tag information at runtime, the client computer initiates a connection to the servers specifying the browsing session parameters such as required fields and filters. It is possible to open and maintain multiple browsing sessions simultaneously. 

Each server in a session prepares a snapshot of its data and sends records in batches to the client. As the server records arrive, the client reconciles them against each other in the event that duplicate or conflicting data arrives from different servers.

The records reconciliation is based on records with the "best device status" which are selected, and the others are discarded.

"Best device status" is calculated as follows:

• Data Source online state (ONLINE is picked over OFFLINE), then
• Data Source active state (ACTIVE is picked over INACTIVE), then
• Data Source priority (higher priority is picked over a lower one, with highest being 1 – for primary I/O device)

If records from different I/O servers fully match on “best device status” the browsing records are taken on the first-come basis. Be aware that there may be project inconsistencies (on different machines) which can affect tag browsing functionality. This can occur if a project is being updated across a number of servers, but only gradually, so there may exist several versions of the project across the network. Tag Browsing will try to reconcile the conflicting data the best way possible, but in such cases check that the returned data is correct.

For each server session the client keeps track of how many records are expected, and what the last record received was. The TagBrowseNext Cicode function will either cause the client to look at the next cached record which was received earlier and fully reconciled, or request the next batch of records from the I/O servers.

If a communication disruption occurs during the browsing process, or when the client explicitly closes the browsing session, the session will be terminated.

See Also

Published June 2018