How the transaction_id Works

As you have already learned:

• Each instance of a business process is a transaction and is assigned a transaction_ID.
• All audit events within a transaction are assigned an event_id.

The transaction_ID allows any audit event tied to the ID, to be linked to the next audit event within the process, resulting in a chronological chain of all audit events.

Chaining complex or branched transactions however, requires both event_id and parent_id data. It is used when a set of events branch off the main flow.

As an example, this could happen where 1 item in an order is available in one distribution warehouse, and the other 2 items are available in a different warehouse. This means that 2 delivery orders are created. The items are then shipped separately from the different centers.

To connect these branched workflows, the event_id of the previous event in a chain is used as a parent_id to identify the hierarchy and succession. Using this relationship allows a user to view the parent-child relationships for the audit trail of the entire business transaction. If a parent ID was not configured, timestamps are used to chain the audit events into a chronological audit trail.

As before, the transaction_id connects these events so that you can see what is occuring along both branches. This allows you to track and analyze any points along the branched path. See the following example.

For information about how to set transaction_id, event-id, parent_id, and other parameters see TIBCO Cloud AuditSafe PostAuditEvent