See information about the latest product version
Monitoring basics
Message flows can be configured to emit events. The events can be read and used by other applications for transaction monitoring, transaction auditing, and business process monitoring.
Monitoring Events
A monitoring event is an XML document that conforms to the monitoring event schema. Each event contains the following information:
- Source of the event
- Name of the event
- Sequence number and creation time
- Correlation ID for events emitted by the same transaction or unit of work
- Application data extracted from the message
- Part or all of the message bit stream
See The monitoring event for more details
Event Sources
- Transaction events
- Transaction events are emitted only from input nodes.
- Terminal events
- Terminal events are emitted from any terminal of any node, including input nodes.
- Using the monitoring properties of the message flow.
- Using a monitoring profile configurable service.
An event source address identifies an event source in a message flow.
Because terminal events can be emitted from any node in a message flow, they can be used as an alternative to dedicated event-emitting nodes or subflows such as that supplied in SupportPac IA9V.
Event sources emit events only if monitoring is activated for the message flow.
Terminal events
Any terminal in a message flow can be an event source. If the event source is active, it emits an event each time a message passes through the terminal, subject to the evaluation of the eventFilter expression; see Event output options.
Transaction events
Event source | Event source address | Description |
---|---|---|
Transaction start | Nodename.transaction.Start | The event is emitted when the message is read from the transport. |
Transaction end | Nodename.transaction.End | The event is emitted when WebSphere Message Broker has completed all processing of the message. |
Transaction rollback | Nodename.transaction.Rollback | The event is emitted instead of transaction end if the message flow throws an exception which is not caught and processed within the message flow. |
Events are emitted subject to the evaluation of the eventFilter expression; see Event output options.
If a message flow handles its own exceptions, a transaction end event, rather than a transaction rollback event, is issued, because the flow has taken control of the error and terminated normally. In this case, if you need to distinguish errors, you can configure terminal events at appropriate nodes in the flow.
Event output options
$Body/StockTrade/Details/Value > 10000
This
can reduce the number of events that are emitted, and reduce the workload
on your monitoring application.3 >= $Root/MQMD/BackoutCount
$SYS/Broker/brokerName/Monitoring/executionGroupName/flowName
The hierarchical structure allows subscribers to filter the events which they receive. One subscriber can receive events from all message flows in the broker, while another receives only the events from a single execution group.
- If you want an event to be emitted only if the message flow transaction commits, configure the event source to coordinate the events with the message flow transaction.
- If you want an event to be emitted regardless of whether the message flow transaction commits or rolls back, configure the event source to emit events out of sync point. Such events are available immediately.
- If you want a group of events to be emitted together regardless of whether the message flow transaction commits or rolls back, configure the event source to emit events in a second, independent, unit of work.