3 Ways to Solve App Performance Problems with Transaction Tracking - Part 2In part 1, I discussed the important of tracking applications and how that is similar to tracking packages.   However, there is one significant difference between the two, applications don’t have bar codes.  The collecting of the tracking events as the data moves through the application requires additional processing.   There are many techniques for doing this.   The application can generate the events itself, in the form of a log or audit trail.   But in cases where it doesn’t, instrumenting the underlying system is an option, depending on what facilities it provides.   Given an application that executes through DataPower, IIB (Broker) and MQ, Nastel leverages several techniques to create the tracking events.


DataPower can act as a front end or an intermediary node.  These flows are one of the key ones that require visibility.  Unfortunately, there is simple no place to do that centrally.  We have found that the best way is to make slight modifications to the flows to collect the required data and send this as tracking events. Using this method, we can track very granular detail of flows that go through as well as failures or performance problems in the flow.  Many application flows already have some form of built in tracking that can be easily leveraged as well.

IBM Integration Bus / IIB (Broker)

The Broker supports a very rich mechanism for tracking the Message Flows.  Without changing the internal structure of the flows as required in DataPower, you can still get to that level of detail, including

  • Transaction Start / Stop (default)
  • When a given node was processed
  • Message content being processed by the flow
  • Track message flows in and across brokers

You have controls within the broker to determine what type of data is sent.  With the Broker, you have the ability to configure more detail about the information you want to send.  Data collected is published to broker topics, which are then forwarded as tracking events.


IBM MQ provides 2 options to collect the data depending on versions of MQ.

Using MQ API Exits

Available in all versions of distributed MQ, MQ API Exits can be used to capture information as it flows through the MQ environment.  When an application is invoked, the queue manager will pass information about the application to the exit program.  The exit program will look at the application call and data to decide what to do with this information. This procedure allows us to track information as it flows through the application environment and across the sending and receiving channels to multiple queue managers (distributed and mainframe)

Tracking Using Application Activity Trace

With MQ 7.1 and above, the queue manager can be configured to generate the tracking events.  The MQ appliance uses this method exclusively.  The data collected is the same as when using MQ Exits.  The activity trace method has some advantages over the MQ Exit approach including no need to install code into the queue manager, easier to enable and disable and easy to setup for remote access.  But it currently supports limited filtering on the host MQ server which can mean potential for increased network traffic.

Independent of which method is used, the tracking events provide the information need to see inside of the MQ processing.

Managed File Transfer (MFT/FTE)

Many customer are currently leveraging managed file transfer into their applications to integrate files with MQ flows and broker (IIB).  The MFT coordinator publishes tracking events to record this activity. This allows you to see the transfer and any failures.


As noted in the introduction, the goal is a combined flow across the environment.  You need visibility into one or more of the technologies such as browsers, mobile, DataPower, Broker, Message File Transfer, MQ, Java applications and many more.

Nastel AutoPilot TransactionWorks analyzes this tracking information, interprets the data and produces the global transaction mapping.  When the events track across all of these technologies, we can provide a complete picture of the application flow.  through multiple environments.

Read Part 1 in this 2 part series: “3 Ways to Solve App Performance Problems with Transaction Tracking”.

To learn more, watch the TechTalk here