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