With the brand new IIB Fixpack 3, the Business Transaction Monitoring feature (BTM) becomes generally available.
This article will introduce the feature, its key concepts and value proposition. Further articles will include tutorials, best practices, performance tuning and other related topics.
Value
The purpose of the feature is to monitor a transaction end-to-end through various IIB flows deployed on an integration node, to track and report the lifecycle of a payload message as it is processed by IIB.
A business transaction is a unit of function that can be seen as a unit from a business point of view, like a purchase, a booking, an auction. It is not a transaction in technical sense, neither a one nor a two-phase transaction, more like a till transaction. A business transaction instance is a specific order or booking, usually identified by a reference number or ID, such as “order123456”.
BTM is based on existing flow monitoring capabilities and monitoring events. It enables you to see which aspects of your business transaction are working correctly and which aspects are failing. As monitoring and correlating events may affect the servers’ performance, the recommendation is to focus on flagging events that occur in error conditions, so that you can monitor when and why a business transaction might have failed.
BTM allows correlation and summarising of events. You can define your business transaction, say PurchaseOrder, and then see at a glance what has happened to your orders, what state the orders are in, where they completed, failed or are still in progress.
You can inspect individual events that contributed to a single business transaction determined by your definition, to help identify where a transaction may have failed and why. This is a key use case for BTM.
Figure 1. Business Transaction Results
BTM Concepts
Monitoring Event
An event is a processing step that occurs during an IIB integration. Events are published, as they happen, and can be captured in a data store .
The events contain information about the source of the event such as which message flow and node triggered them and which action was performed e.g. transaction start/transaction end or which node terminal has been fired. The event may include the message payload and exception list. Giving monitoring events good, descriptive names corresponding to the business transaction stages (e.g. “Order Received”, “Delivery Attempted”) will make it easier to use BTM.
Business Transaction Definition
A business transaction definition is an integration node asset. You choose to include in the definition flows deployed on that node and, from the monitoring events on those flows, you choose which events to monitor under the transaction.
When including the events, you can choose the role for that event. The event can mark the start, the successful or the failure end for the transaction. You can also mark an event as a Progress event. With progress events you can track the business transaction to its critical steps.
Monitoring events that are not included in the business transaction will be ignored by BTM runtime and will not change the state of a business transaction.
Figure 2. Business Transaction Definition – Conceptual Diagram
The diagram shows the key elements of a business transaction definition: flows that have monitoring events, a subset of those are included in the business transaction with one of those selected roles.
Figure 3. Business Transaction Definition
Event Correlation
Monitoring events are correlated in BTM to report the state of a business transaction.
There are two essential pieces to the correlation :
business transaction definitions. These contain the list of events and their roles (start, end, failure, progress events) and allow the runtime to identify what business transactions an individual monitoring event contributes to.
global transaction Ids. Once an event has been identified as part of a business transaction, its Global Id value makes the event part of the business transaction instance associated with that value.
The diagram below illustrates how the flows emit events, the events are received and correlated by the BTM runtime based on the global Ids and are associated with the corresponding business transaction and update the business transaction states accordingly. Two global transaction instances for Ids “123” and “234” are shown.
Figure 4. Event Correlation for BTM
Business transactions configuration
BTM prereqs a MQ queue manager associated with the BTM enabled integration node.
The monitoring events are published to a MQ Topic. BTM subscribes to those topics and then processes the monitoring events that have been flagged as business events. Events not flagged are being ignored.
BTM also prereqs a DB2 or Oracle database to be used as an event store.The database needs to have the required tables and to have been configured to be used by the integration node.
BTM uses a default DataCapture policy for its configuration, to specify information such as the database location where the business data is stored. You set the database location by specifying the data source name in the Configure tab of the business transaction monitor when you create the business transaction definition.
Viewing business transactions: states, instances and events
Once a business transaction has been defined and configured and messages have been processed, you can view its results. You must ensure that flow monitoring has been enabled and a global id is specified for each business event.
For each business transaction, you can see in a tabular form, the global ID used to correlate the events, the timestamps of the first and last events for this global transaction and the transaction status. “Ended” and “Failed” are business transactions that have completed successfully and, respectively, with failure. “In progress” transactions are those that had a Start event, zero or more Progress events, but neither successful or unsuccessful end. If a transaction instance has a status of “Inconsistent”, it means that a problem occurred during the transaction that prevented it from being resolved. For example, if a transaction went through your flows twice, then 2 start events and 2 end events would be received which would cause the transaction to be marked inconsistent.
For any business transaction you can drill-down, see the events that have been received. In particular, if the status of the business transaction is “In progress” or “Inconsistent” this can help to identify what went wrong.
With the next article under the BTM series you can see how to set up and monitor your first business transaction. That will be the “How” part of the title.
Stay tuned.