Geo SCADA Expert uses a Pending Transaction Count to determine whether a Group Template or Group Instance has updates pending.
Whenever a change is made to an item in a Group Template, the pending transaction count for the Group Template increases by 1. The pending transaction count for every Group Instance that is associated with the Group Template also increases by 1 (as the change to the item in the Group Template will need to be propagated to the Group Instances). If any further changes are made to items in the Group Template before the first changes have been propagated, the pending transaction count increases from 1 to 2. When the changes have been propagated, the pending transaction counts return to 0.
The rules of the Configuration Transaction feature are enforced only on those Group Templates and Group Instances that have pending transaction counts above 0. (The Transactions section of Geo SCADA Expert’s Server Status Tool provides information about transactions that are pending or in progress—see Transactions in the Geo SCADA Expert Guide to the Server Status Tool.)
Example:
A Group Template named 'AT1' is associated with three Group Instances, ‘MXE10’, ‘MXE11’ and ‘MXE12’. There are no pending changes and so the pending transaction counts for the Group Template and the three Group Instances are 0.
A user changes the configuration of an item in the ‘AT1’ Group Template and saves the Form. This causes the pending transaction counts to rise as follows:
- AT1 - 1
- MXE10 - 1
- MXE11 - 1
- MXE12 - 1
As the pending transaction counts are above 0, the rules for the Configuration Transaction feature are applied (to the Group Templates, Group Instances and items nested within them).
Geo SCADA Expert propagates the configuration change to MXE10. This causes the pending transaction count to change to:
- AT1 - 1
- MXE10 - 0
- MXE11 - 1
- MXE12 - 1
The MXE10 count goes back down to 0 as its pending changes have been applied. The count of the AT1 Group Template remains at 1 because the change to the item in the Group Template has not been propagated to the relevant Group Instances.
Geo SCADA Expert propagates the configuration change to MXE11. This causes the pending transaction count to change to:
- AT1 - 1
- MXE10 - 0
- MXE11 - 0
- MXE12 - 1
Another configuration change is made to an item in the 'AT1' Group Template. This causes the pending transfer count for the Group Template and its associated Group Instances to increase by 1:
- AT1 - 2
- MXE10 - 1
- MXE11 - 1
- MXE12 - 2
The first configuration change is propagated to the ‘MXE12’ Group Instance. This causes the pending transfer count of the ‘MXE12’ Group Instance to decrease by 1, and also the pending transfer count of the ‘AT1’ Group Template to decrease by 1 (as the first change has been propagated to the dependent Group Instances):
- AT1 - 1
- MXE10 - 1
- MXE11 - 1
- MXE12 - 1
The transaction for the first configuration change is now complete. Next, Geo SCADA Expert propagates the second configuration change to the MXE10 Group Instance which results in these pending transfer counts:
- AT1 - 1
- MXE10 - 0
- MXE11 - 1
- MXE12 - 1
Geo SCADA Expert then propagates the second configuration change to the MXE11 Group Instance, which causes the pending transaction count to change to:
- AT1 - 1
- MXE10 - 0
- MXE11 - 0
- MXE12 - 1
Finally, Geo SCADA Expert propagates the second configuration change to the MXE12 Group Instance and the pending transaction counts for the Group Template and the three Group Instances return to 0:
- AT1 - 0
- MXE10 - 0
- MXE11 - 0
- MXE12 - 0
With the pending transaction counts are back to 0, the Configuration Transaction rules are no longer applied and you can work freely with the items in the Group Template and Group Instances (depending on your security permissions). The Configuration Transaction rules will be re-applied to the Group Template, Group Instances and nested items as soon as the pending transfer counts for the Group Template or Group Instances rise above 0.