IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > Create monitor models > Generate monitor models > Generate from applications outside the workspace > WebSphere Message Broker message flows
Common monitoring templates for WebSphere Message Broker message flows
When you are generating or working with a monitor model based on a WebSphere Message Broker message flow, you can choose to apply one or more predefined common monitoring templates. These templates are collections of predefined monitoring constructs. After you select a template, the generated monitor model is automatically set up with the constructs that are required to capture the information.
Average transaction duration
The average transaction duration template generates a key performance indicator (KPI) that captures the average value of the transaction durations, based on the start and end events. This template can only be applied to input nodes that have transaction start and transaction end events.
When applied, the template generates:
- An inbound event for each node that has a transaction start and transaction end event.
- A single stopwatch that references all the inbound events. The stopwatch starts when it receives a transaction start event and stops when it receives a transaction end or transaction rollback event.
- A KPI that uses the stopwatch and the average function to calculate the average of these times for all monitoring context instances.
The KPI does not include targets, ranges, or metric filters, but you can add those later in the Monitor Model editor. You might want to apply a filter so that only relevant WebSphere Message Broker events are displayed on your Business Monitor dashboard.
For example, consider a scenario where you are monitoring purchase order requests sent through WebSphere Message Broker. If a purchase order request fails, you might want to know that a rollback event has been emitted but you do not need any more details (such as when the rolled-back message is sent down the Input node failure terminal.)
Number of failed transactions
The number of failed transactions template generates a measure that captures the total number of failed transactions and a dimension level that captures the time when each transaction failed. This template can only be applied to input nodes that have transaction rollback events.
When applied, the template generates:
- A trigger that fires on each transaction rollback event.
- A failed transaction time metric that records the time that the transaction failed.
This metric requires a default value. If you do not provide one, it will be given the default value of 9999-01-01-T000:00:00Z.
- A metric that is set to 1 to indicate that the current transaction has failed.
- A measure that calculates the total number of failed transactions across all message flow instances.
- A dimension and dimension level based on the transaction failure time.
In the dashboard, you can create a dimension or report widget based on the measure. You can add a graph to see the number of failed transactions as time progresses.
Message flow correlation
By default, message flow events are correlated (matched to the correct monitoring context instance) based on the local transaction ID. Choose this template to have the events correlated based on the local transaction ID, broker, execution group, parent transaction ID, and global transaction ID.
You should only select the message flow correlation template if the events you are receiving in a given monitoring context are from the same execution group.
When applied, the template generates correlation expressions for all inbound events based on:
- local transaction ID
- broker name
- execution group name
- parent transaction ID
- global transaction ID
You can display these metrics on the dashboard along with other metrics and KPIs.
Generate monitor models from WebSphere Message Broker message flows
Related tasks:
Generate monitor models based on application monitoring information from WebSphere Message Broker
Related reference:
Results of generating monitor models from WebSphere Message Broker applications