WebSphere Message Brokers
File: ac18880_
Writer: Karen Cameron

Task topic

This build: July 31, 2007 21:19:03

Catching exceptions in a TryCatch node

You can design a message flow to catch exceptions before they are returned to the input node. Within a single flow, you can include one or more TryCatch nodes to provide a single point of failure for a sequence of nodes. With this technique, you can provide very specific error processing and recovery.

A TryCatch node does not process a message in any way, it represents only a decision point in a message flow. When the TryCatch node receives a message, it propagates it to the try terminal. The broker passes control to the sequence of nodes connected to that terminal (the try flow).

If an exception is thrown in the try flow, the broker returns control to the TryCatch node. The node writes the current contents of the ExceptionList to the local error log, then writes the information for the current exception to ExceptionList, overwriting the information stored there.

The node now propagates the message to the sequence of nodes connected to the catch terminal (the catch flow). The content of the message tree that is propagated is identical to the content that was propagated to the try terminal, which is the content of the tree when the TryCatch node first received it. It enhances this tree with the new exception information which it has written to ExceptionList. Any modifications or additions the nodes in try flow made to the message tree are not present in the message tree that is propagated to the catch flow.

However, if the try flow has completed processing that involves updates to external databases, these are not lost. The updates persist while the message is processed by the catch flow, and the decision about whether the updates are committed or rolled back is made on the configuration of your message flow and the individual nodes that interact with the databases. If the updates are committed because of the configuration you have set, you must include logic in your catch flow that rolls back the changes that were made.

To review the options for configuration, see Configuring globally coordinated message flows.

The broker returns control to the next catch point in the message flow (which might be another TryCatch node, but is always, in the last case, the input node) if one of the following conditions is true:

The following example shows how you can configure the flow to catch exceptions in the input node. The MQInput node's catch terminal is connected to a Trace node to record the error.

This message flow has an MQInput node, a Compute node and an MQOutput node. The catch terminal of the MQInput node is connected to a Trace node.

In the following example, the message flow has two separate processing flows connected to the Filter node's true and false terminals. Here a TryCatch node is included on each of the two routes that the message can take. The catch terminal of both TryCatch terminals is connected to a common error processing subflow.

This message flow has an MQInput node followed by a Filter node which has been coded to test a value in the message. A TryCatch node is connected to the Filter node's true terminal, and its try terminal is connected to a Compute node followed by an MQOutput terminal. It's catch terminal is connected to a subflow called error1 which provides a common error processing routine. A second TryCatch terminal is connected to the Filter node's false terminal. It's try and catch terminals are connected to sequences of nodes identical to the first TryCatch terminal.

If the input node in your message flow does not have a catch terminal (for example, Real-timeInput), and you want to process errors in the flow, you must include a TryCatch node. The following example shows how you could connect a flow to provide this error processing. In this example, you could configure the ESQL in the Compute node on the catch flow to examine the exception that has been caught and set the output queue name dynamically.

This message flow has a Real-timeInput node followed by a TryCatch node. The try terminal of the TryCatch node is connected to the normal out flow (Compute followed by Publication), the catch terminal is connected to the catch flow (Trace followed by Compute followed by MQOutput.
Related concepts
Message flows overview
Deployment overview
Related tasks
Using subflows
Creating a message flow
Defining message flow content
Editing configurable properties
Configuring globally coordinated message flows
Handling exceptions in aggregation flows
Related reference
Built-in nodes
WebSphere MQ Enterprise Transport
WebSphere MQ Mobile Transport
WebSphere MQ Multicast Transport
WebSphere MQ Real-time Transport
WebSphere MQ Telemetry Transport
WebSphere MQ Web Services Transport
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:19:03

ac18880_ This topic's URL is: