IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

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

Additionally, a monitoring event can contain the following items:

Application data extracted from the message
Part or all of the message bit stream

See The monitoring event for more details

Event Sources

A message flow can emit two kinds of events:

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.

An individual message flow can choose to emit transaction events, terminal events, or both kinds of event. You can configure, enable, and disable, both types of events in either of the following ways:

Using the monitoring properties of the message flow.
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.

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

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 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

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

This 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 so that appropriate data can be collected by an event monitoring application.

3 >= $Root/MQMD/BackoutCount

Events are published to a topic, where they can be read by multiple subscribers. The topic name is of the form:

$SYS/Broker/brokerName/Monitoring/integrationServerName/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 integration server.

You decide whether events participate in transactions when you configure a monitoring event source. In general:

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.

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, and neither monitoring properties nor a monitoring profile configurable service have been configured for the flow, the default behavior is for transaction events to be emitted from each input node of the message flow. The events contain the bit stream of the input message.

ac37860_.htm |

Last updated Friday, 21 July 2017