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

A monitoring event is an XML document that conforms to the monitoring event schema. Each event contains the following information:
  • 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
Additionally, a monitoring event can contain the following items:
  • Application data that is extracted from the message
  • Part or all of the message bit stream

Event Sources

A message flow can emit two kinds of event:
Transaction events
Transaction events are emitted from input nodes only.
Terminal events
Terminal events are emitted from any terminal of any node, including input nodes.
An individual message flow can emit transaction events, terminal events, or both kinds of event. You can configure, enable, and disable both types of event in either of the following ways:
  • By using the monitoring properties of the message flow
  • By using a monitoring profile configurable service
The use of a monitoring profile configurable service overrides the monitoring properties of a message flow.

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

Each input node in a message flow contains three events sources, in addition to terminal 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

When you configure an event source, you can define a filter to control whether the event is emitted. You can tailor event emission to your business requirements by filtering out events that do not match a set of rules. For example, you might decide to emit events only for transactions above a minimum amount:
$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.
You might filter out the "transaction.Start" and "transaction.End" events that are emitted by the MQInput node for WebSphere® MQ Backout transaction events after a backout threshold is reached. An event monitoring application can then collect appropriate data.
3 >= $Root/MQMD/BackoutCount
Events are published to a topic, where they can be read by multiple subscribers. The topic name has the following structure:
  • 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.

You decide whether events participate in transactions when you configure a monitoring event source:
  • 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.
Note:
The monitoring event is not emitted if a parser exception occurs in the following situations:
  • Constructing the monitoring event from the Event Name, Event Filter, or Event Payload.
  • Including the bitstream in the payload.
In these situations, the parser exception is re-thrown and the message is rolled back.

Default monitoring configuration

If monitoring is activated for a message flow, but monitoring properties or a monitoring profile configurable service are not configured, the default behavior is for transaction events to be emitted from each input node of the flow. The events contain the bit stream of the input message.