Monitoring basics
Message flows can be configured to emit events. The events can be read and used by other applications for transaction monitoring and auditing, and business process monitoring. They are also used by the built-in business transaction monitoring capability provided by IBM® Integration Bus.
The following sections introduce the concepts of monitoring.
- Monitoring Events
- Event Sources
- Transaction events
- Event output options
- Default monitoring configuration
Monitoring Events
- The source of the event
- The name of the event
- A sequence number and creation time
- A correlation ID for events that are emitted by the same transaction or unit of work
- Application data that is extracted from the message
- Part or all of the message bit stream
Event Sources
- By using the monitoring properties of the message flow
- By using a monitoring profile configurable service
An event source address identifies an event source in a message flow.
Terminal events can be emitted from any node in a message flow. Therefore, these events can be used as an alternative to dedicated event-emitting nodes or subflows, such as the example supplied in SupportPac IA9V.
Event sources emit events only if monitoring is activated for the message flow.
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 IBM Integration Bus completes all processing of the message. |
Transaction rollback | Nodename.transaction.Rollback | The event is emitted instead of transaction end if the message flow issues an exception that is not caught and processed in the flow. |
Events are emitted subject to the evaluation of the eventFilter expression, which is described in the Event output options section of this topic.
If a message flow handles its own exceptions, a transaction end event is issued instead of a transaction rollback event because the flow takes control of the error and terminates normally. In this case, if you need to distinguish errors, you can configure terminal events at appropriate nodes in the 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. This expression is described in the Event output options section of this topic.
Event output options
$Body/StockTrade/Details/Value > 10000
The
use of a filter can reduce the number of events that are emitted,
and reduce the workload on your monitoring application.3 >= $Root/MQMD/BackoutCount
- For events published on the MQ pub/sub broker:
$SYS/Broker/integrationNodeName/Monitoring/integrationServerName/flow_name
- For events published on the MQTT pub/sub broker:
IBM/IntegrationBus/integrationNodeName/Monitoring/integrationServerName/flow_name
The hierarchical structure allows subscribers to filter the events that they receive. One subscriber can receive events from all message flows in the integration node, while another receives only the events from a single integration server. For more information about publishing and subscribing to events, see Publish/subscribe overview.
- 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 an independent unit of work.
- Constructing the monitoring event from the Event Name, Event Filter, or Event Payload.
- Including the bitstream in the payload.