BTM Aliasing using the BTM WebSphere MQ Exit

Aliasing is a feature that allows a transaction to be monitored from end-to-end using multiple identifiers at the various monitored touchpoints that implement your Business Transaction Pathway model. For details on how to configure a model see Defining-transaction-pathways-to-monitor-your-infrastructure.

When aliasing is enabled for a model there is one basic requirement which is that at some point in the processing of the transaction an alias identifier can be associated with another alias identifier in such a manner that all aliases used can be correlated together. Much of this work is accomplished by the server set and the entire transaction reported using a product generated unique identifier starting with "MQS_".

The MQS_ transaction identifier is generally created when the first touchpoint of the model is received. In the case where there are multiple beginning activities or multiple inputs to an activity the creation of the MQS_ identifier is delayed by the create fragment delay allowing time for the information from those other touchpoints to be received.

As a transaction is processed by each touchpoint a set of aliases are received from configured transaction identifiers or payload values. If any of the aliases within that set exists in another group the sets can be combined. When the MQS_ identifier was created, there was an initial set of aliases. When that initial set is combined with the set of aliases from additional touchpoint the aliases from all those sets are now associated with the MQS_ identifier. If a set of aliases is never combined after a period of time it is considered a "fragment" and gets its own MQS_ identifier and the information published.

The BTM WebSphere MQ exit can be used to publish an additional alias id for a given output touchpoint (put or put1) when the input touchpoint (get or callback) is done by the same WebSphere MQ user application (not a channel). The additional alias id is actually the alias configured as the transaction id for the input touchpoint. This allows the output's set of aliases to be correlated with the sets of aliases that the input touchpoint's set could be correlated with.

The following are the ways that the BTM WebSphere MQ exit determines that the input touchpoint's transaction id should be published as an additional alias of the output touchpoint's transaction id. These are listed in order of precedence when enabled on the Activity Implementation:

1. When the application opens its input queue with MQOO_SAVE_ALL_CONTEXT and its output queue with MQPMO_PASS_ALL_CONTEXT or MQPMO_PASS_IDENTITY_CONTEXT then the exit knows the transaction id from the get/callback can be associated with the put/put1. It is also necessary that the input queues object handle is passed in the put options.
2. When the MsgId or CorrelId fields of the MQMD on any get/callback matches either the MsgId or CorrelId fields of the MQMD on any put/put1 then the exit knows the transaction id from the gets/callbacks can be associated with the put/put1.
3. When the application gets a message and then makes additional get and puts in the same thread id then the transaction ids for each message processed by that group of calls is associated with the transaction id from the first get. Specifically, a group is defined by a get, followed by any number of additional gets, followed by one or more puts. The fewest calls for this pattern would be a get followed by a put. Some examples would be get, get, put or get put put with the first implementing a fan-in or receipt of multiple segments of a batch and the second a fan-out or breaking a batch into segments.

Note that association occurs per activity implementation (ie. for a particular queue manager and application).

In addition you can configure a payload value (either technology provided or user defined) as additional aliases. Of particular usefulness for WebSphere MQ is the UOW (unit of work), UOW count, and Message UUID technology payload values.

This UOW payload allows the messages from all monitored MQ API calls made under the same unit of work by a single application to be aliased together. Refer to the IBM documentation for WebSphere MQ on how you use syncpointing and determine a unit of work. The UOW technology payload value is provided by WebSphere MQ on z/OS and a product generated identifier on other platforms. On z/OS this feature can be used with CICS applications using the WebSphere MQ Adapter as well as batch WebSphere MQ applications.

The UOW count payload is the same as the UOW payload with a suffix that corresponds to the nth message from the get or put. This can be used to associate the nth get with the nth put within a unit of work.