Aliasing

A transaction ID is a unique identifier for a transaction. For message-based transactions, the transaction ID can be one field in the transaction, or you might wish to concatenate two or more fields to create the identifier. For non-message-based transactions, the transaction ID is specified in the BTM API. The transaction ID is defined by you and cannot change. If it does, you must use aliases and enable Use Aliases for a transaction pathway, in which case the BMC MTM Topic Service generates a transaction ID for you (identified by MQS_Number).

An alias ID is used in addition to the transaction ID and is associated with the transaction ID. For message-based transactions, the alias ID can be one field in the transaction, or you might want to concatenate two or more fields to create an alias ID. For non-message-based transactions, alias IDs can be specified in the BTM API.

Use aliases to identify a transaction at different points in a transaction pathway. At each point in the pathway where the alias ID changes a new fragment is created. For message-based transactions, the transaction at an activity monitoring point is identified by the alias ID from the message content. For non-message-based transactions, the transaction at an activity monitoring point is identified by the alias ID passed by the BTM API.

You can also use aliases as a way to identify the transaction using additional methods, such as a more meaningful identifier. For message-based transactions, you can identify additional aliases by configuring payload data taken from the message content. For non-message-based transactions, you can identify additional aliases by configuring payload data using the BTM API.

Two transactions can use the same alias so long as they are not concurrent transactions for the life of the transaction plus the Remove Transaction Delay.

When retrieving transactions from history, an alias identifier retrieves all transactions that were associated with that alias.

For instance, if you use WebSphere MQ, you might use the default message ID generated by WebSphere MQ as an alias ID. It is used to identify the transaction at the putting and getting applications. You can retrieve the transaction from history using the message ID (as the alias). However, as that identifier is not very human-friendly, you might define additional aliases that do have more meaning for you depending on the content of your message. Some ideas might be:

  • Policy number
  • Purchase number
  • Customer name and date of request

A fragment is a portion of your transaction pathway identified by an alias ID and other aliases associated with it. Different technologies (WebSphere MQ, WebSphere Message Broker, APIs) use different mechanisms for associating the alias identifiers to each other, and ultimately to a single transaction ID. Refer to Installing and running application transaction tracing (transaction monitoring) extensions for additional aliasing mechanisms supported by each extension.

Whenever possible you should attempt to find a unique identifier for your transaction pathway that remains the same at every activity. Using the same identifier performs the best and avoids this fragmentation issue. If you need to identify the transaction using other values, consider using payload. However, you cannot use payload to retrieve the transactions from history. You retrieve transactions based on time and then filter the display using payload values.

Note

If your application does not serialize the transactions and you are using the extended version of the API, it does not matter in what order the API is called because the API uses a timestamp. The timestamp reflects the correct order for monitoring the transactions.

Note

WebSphere MQ message prioritization does not affect how transactions are monitored.
Set Create Fragment Transaction Delay to the expected maximum elapsed time for your transaction and just slightly greater than your SLA timeouts (if use them).
Was this page helpful? Yes No Submitting... Thank you

Comments