Running Global Projects
Transaction Audit Trail
: Following the Audit Trail
Following the Audit Trail
The following section refers to elements within the Transaction Database. For more detail about Transaction Database Elements refer to the Administrator Command Reference Manual.
As seen from the TRINCO
A TRINCO is created when an input command is received. It has a creation date (DATECR) an initial state (INCSTA) of ‘Received’, and a command type TRCNUM.
If the command came from the user, (or from TIMEDUPDATES) then the command UID (COMUID) is set to a null reference. Otherwise it will be the reference of the output command (TROUCO) that sent the command. If this is from another location it is an unknown reference as it is in another transaction database that is not in the current MDB and so cannot be navigated to.
The originating location of the command (where a user first issued it) is ORILOC. The location that sent the command to this location is PRVLOC. And the destination location to which it is eventually heading is DESLOC. Normally, commands are passed from location to location until the destination is reached where operations take place. For some commands, the operations take place at the ORILOC and DESLOC is used as a location to which to pass on some other commands. It is not obvious which commands are exceptions to the normal rule.
If INCSTA = ‘Acknowledged” then an acknowledgement has gone to the sender of the command. This is only relevant if the sender was a TROUCO and not a base product user.
If the state INCSTA = ‘Ready’ then the input command has created its operations successfully and TROPERs and/or TROUCOs will exist.
If there was a failure in the create processes the INCSTA may be ‘Stalled’ and no operations will exist. After waiting for the standard time the command will try again. Alternatively this failure can terminate the TRINCO. Its TRPASS will be set to FALSE, its state will be “Complete” or a later state, and it may own a TRMLST/TRMESS and perhaps a TRFAIL but no TROPERs or TROUCOs. Input commands can be given a delayed start time (EXTIME) after which operations will be generated. It will wait in the “Waiting” state until this time has passed. This stay of execution will persist until EXTIME has expired, even if this is a longer period than the Time out.
The TRINCO stays in ‘Ready’ state for as long as all its operation and output commands take to complete. Once the TRINCO has been set to ready the command cannot time out until all operations have also timed out.
When all member operations and output commands have completed INCSTA is set to “Complete”. All failures and successes generated by them are collected together and handed on to the sending TROUCO (which stores them). The success state of the command (TRPASS) is set to true if all operations have succeeded. INCSTA is now at “Replied”.
Once a reply acknowledgement has been received back from the previous location, INCSTA is set to ”Processed” and no more actions will take place.
There are other terminating conditions of a TRINCO; “Timed Out” means that the command did not manage to start before either its end time was reached, or the number of retries allowed was exceeded. It will not own any TROUCOs or TROPERs.
The state is set to “Cancelled” if the command is cancelled before any significant action took place. Owned TROUCOs and TROPERs may be set to cancelled if they have not yet started work: subsequent operations that depend on them will be set to “Redundant”.
As seen from the TROUCO
Output commands may be created when input commands create their operations and possibly again when post operations are generated. These TROUCOs have ORILOC set to the current site, DESLOC the ultimate processing destination of the command and are sent to NXTARL, the next destination en route. The command type is the TRCNUM attribute.
If the current location is not the destination of the incoming TRINCO then a TROUCO is created to manage the progression of the command to its destination when all other (if any) operations and output commands on which it is dependent have completed. This TROUCO is a duplicate of the owning TRINCO and when it is passed on its ORILOC is that of its owning TRINCO.
TROUCOs store the progress of the communication of the command with the location to which it is sent (NXTARL) and the reply.
OUTSTA is the state of processing of a TROUCO. Its value is “Waiting” until the command is ready for processing. This may be delayed because of dependency on other operations or output commands. These dependencies are stored in DEPCOU, DEPEND and DEPTYP attributes ‑ the number of dependencies, the elements depended on, and whether it is on success or failure.
When all previous commands and operations on which the TROUCO is dependent have completed, and when the condition of the dependencies are met the TROUCO’s state changes to “Ready”. After this point the command is sent to its target location and its state is set to “Sent”. If the sending fails the TROUCO is “Stalled” and remains so until the time between retries (WAITIM) for that location is passed when it goes back to “Ready” again.
The receiving location must acknowledge the command (OUTSTA = “Acknowledged”. The acknowledgement is sent with the dbReference of the TRINCO at the receiving location that has been created to store the command. This is stored in the TROUCO’s CMREF attribute. For remote locations this will usually be an unknown reference since the specific transaction database is not visible. It can be used to track the command down the chain of locations if the administrator can see all the databases.
When a reply is received OUTSTA becomes “Replied”. Any reply data is stored under TRFLST and TRSLST elements and the TRPASS attribute and OUTSTA goes to “Processed”.
TROUCOs can terminate by timing out if they fail to send in the lifetime prescribed (“Timed Out”. They may never be sent if dependencies are not met, in which case they terminate as “Redundant”.
As seen from the TROPER
Operations are created during the create operations process and possibly again when post operations are generated. Operation information is stored in TROPER elements. This is used to execute an operation at a location, to progress the operation and store any results, errors, messages it may generate.
It is only operations that actually do anything in the daemon, input and output commands (TRINCOs and TROUCOs) are just the means of marshalling instructions between users and locations, and between locations. Extra commands may be generated, but in the end it is the operations that are created at locations that do the work.
The operation type is the TRONUM attribute.
Operations start in state OPSTAT “Waiting” until it is no longer dependent on any prior operation or command and can be executed. It then goes to “Ready” and put into a list ready for execution. Execution takes place in a separate thread and the state is then “Running”.
During the running state Failures and Successes may be generated as well as messages. But these are not stored in the database immediately.
When the operation finishes (TRPASS set to true or false) the OPSTAT is set to “Complete” and successes and failures stored in the database under the TROPER (and not before this). The finishing may also set a string in MSTEXT, but this is not passed on.
The execution of an operation can stall due to inability to access data for example. In this case the OPSTAT is set to “Stalled” and will be reset back to Ready after time WAITIM. The number of retries after stalling is stored in NRETRY. Operations will time out if still stalled at date ENDTIM or the number of retries exceeds MAXTRY. In this case OPSTAT goes to “Complete” and finally “TimedOut”.
When an operation is complete it may need to generate extra operations and commands the form of which are dependent on the results of the operation. If this create operation is stalled then the operation goes to OPSTAT “Stalled Post Operation” and will go back to “Complete” after WAITIM. When post operations are successfully created, or none are needed, then the operation goes to a final state that is “Processed” or “Timed Out”.
TROPERs may never be needed if dependencies are not met in which case they terminate in state “Redundant”. This may happen if a command is cancelled.
1974 to current year.
AVEVA Solutions Limited and its subsidiaries. All rights reserved.
