Context information

A typical environment monitored by Transaction Tracking produces large amounts of tracking data. For this reason, Transaction Tracking aggregates the tracking data. Timings and other statistics are aggregated by their common contextual information.

Contextual information is also used for labeling nodes in the visualization of a transaction, and for linking to domain-specific IBM Tivoli Monitoring applications.

Contextual information is information related to the circumstances in which the transaction event occurred. For example, the name or address of the host on which the event occurred, or the host that caused the event to occur. Similarly, the name of the application from which the transaction originated or the application that is presently processing the transaction are also contextual information. Such information allows users to aggregate response times between hosts, between applications, and so on. It is not, however, instance data, that is, it is not specific to one event, but typically specific to a flow of events.

Contextual information is stored in two fields: the vertical context, and horizontal context. Vertical context is intended to contain information about the transaction, application or host where the event occurred. Horizontal context is intended to contain information about the message or interaction between two applications or hosts. For example, the vertical context might contain the host name of the machine on which an event occurred, and the horizontal context might contain the type of HTTP request that caused the event to occur.

For a transaction moving through a physical topology, an event's vertical context (for example, the hostname, physical location, application name) is used to label the individual nodes (that is, the hosts) in the graph. An event's horizontal context (for example, the query type, message queue name) is used to label the edges between those nodes.

Figure 1. Contextual information in a transaction
Contextual information in a transaction

Similarly to creating stitching IDs, providing contextual information requires cooperation between the programmers instrumenting the various applications. In particular, the names of the items of information should match where transactions should be grouped by that information. Names are case-sensitive, and aggregation performs a binary equality comparison on them.

Transaction Tracking workspaces also depend on names to provide a further hierarchy of information. The following four Vertical Contexts must be set at least once for every linked set of events. For example, set the Vertical Contexts in the STARTED event.
The server name or address of the machine on which the event occurred. For example, win001.
For z/OS® users, this must be the Sysplex name and the z/OS host name (SMF id), separated by a forward slash (/). For example, SYSPLEXQ/MVS1.
The name of the component in which the event occurred, For example CICS®, Websphere Application Server, MQ: MQ.
The name of the application in which the event occurred. For example, the CICS region name or the MQ Queue Manager name: CICS001.
A common identifier for a group of transactions. If this is known by all participants in the transaction, you can easily view aggregate information for all events occurring within transactions of that group. For example, TXN1.
Note: Values for Vertical Contexts can be updated by subsequent vertically linked events. For example, a value for TransactionName could be set in the STARTED event and then be overwritten in an INBOUND event.

The horizontal context distinguishes between interactions at an aggregate level, which is of particular benefit when a mesh of interactions occurs. Transaction Tracking workspaces do not currently display this information, but the interaction data presented is more accurate when provided. Some suggestions for common contextual information to include in events are:

For applications that query some resource in an external application, such as a message queue or database table, the name of that resource. For example, the queue name or database table name.
The host name of the source of the interaction.
The host name of the destination of the interaction.

The contexts that the Transaction Collector should aggregate are specified in the Context Mask file. See Transaction Collector Context Mask for more information on this file.