Handling exceptions in aggregation flows

When you use aggregation flows, you might find that exceptions occur. This topic tells you how to deal with them.

Before you start:

To complete this task, you must have completed the following tasks:

Dealing with exceptions

If an error is detected downstream of an AggregateReply node, the broker throws an exception. Another node in the message flow might also throw an exception using the ESQL THROW statement. In either case, when an exception is thrown, it is caught in one of two places:

  • The input node on which the replies arrive
  • The AggregateReply node

The following table lists events and what happens to an exception thrown downstream of the AggregateReply node.

Event Message propagated Output terminal Exception caught at
An expected reply arrives at the input node and is passed to the In terminal of the AggregateReply node. It is the last reply needed to make an aggregation complete. Aggregated reply message containing all the replies Out Input node
An unexpected reply arrives at the input node and is passed to the AggregateReply node. It is not recognized as a valid reply, and the Unknown Message Timeout property is set to 0. Message received Unknown Input node
A timeout occurs because all the replies for an aggregation have not yet arrived. Aggregated reply message containing all the replies that have been received Timeout AggregateReply node
An unknown timeout occurs because a retained message was not identified as a valid reply. Retained message Unknown AggregateReply node
An aggregation is discovered to be complete at some time other than when the last reply arrived. Aggregated reply message containing all the replies Out AggregateReply node

If you want to handle errors that occur in aggregation flows, you must catch these exceptions at all instances of each of these nodes in the message flow. To do this:

  1. Switch to the Broker Application Development perspective.
  2. Open the message flow that you want to work with.
  3. If you want to handle these exceptions yourself, connect the catch terminal of each input and AggregateReply node to a sequence of nodes that handles the error that has occurred.

    If you want a unified approach to error handling, attach the catch terminals of all these nodes to a single sequence of nodes, or create a subflow that handles errors in a single consistent manner and attach that subflow to each catch terminal.

  4. If you want the broker to handle these exceptions using default error handling, do not connect the catch terminals of these nodes.
If you connect the catch terminal of the AggregateReply node, and want to output the message propagated through this terminal to a destination from which it can be retrieved for later processing, you must include a Compute node in the catch flow to provide any transport-specific processing. For example, you must add an MQMD header if you want to put the message to a WebSphere MQ queue from an MQOutput node.

The ESQL example below shows you how you can add an MQMD header and pass on the replies received by the AggregateReply node:

-- Add MQMD
SET OutputRoot.MQMD.Version = 2;
.
-- Include consolidated replies in the output message
SET OutputRoot.XML.Data.Parsed = InputRoot.ComIbmAggregateReplyBody;
.

If you want to propagate the information about the exception in the output message, you must also set the Compute mode property of the Compute node to a value that includes Exception.