ac00410_.htm |
Last updated Friday, 21 July 2017The broker provides basic error handling for all your message flows. If basic processing is not sufficient, and you want to take specific action in response to certain error conditions and situations, you can enhance your message flows to provide your own error handling.
For example, you might design a message flow that expects certain errors that you want to process in a particular way. Or perhaps your flow updates a database, and must roll back those updates if other processing does not complete successfully.
The options that you can use to do this are quite complex in some cases. The options that are provided for MQInput and TimeoutNotification nodes are extensive because these nodes deal with persistent messages and transactions. The MQInput node is also affected by configuration options for WebSphere® MQ.
Because you can decide to handle different errors in different ways, there are no fixed procedures to describe. This section provides information about the principles of error handling, and the options that are available, and you must decide what combination of choices that you need in each situation based on the details that are provided in this section.
Wire the Failure terminal of a node to explicitly check for any errors that occur within that node. If errors occur, an exception list is propagated to the Failure terminal. The inflight message remains the same as it was before the node was invoked.
You can introduce more specialized error checking in nodes that can be customized by using ESQL. For example, you can create exit handlers within these nodes. For more information about using ESQL to create exit handlers, see DECLARE HANDLER statement.
If you do not wire a Failure terminal, a failure in the node is converted into an exception which is thrown from the node. Any changes that were made to the inflight message before the exception was thrown are reversed. The exception might cause the current transaction to be rolled back which means that any updates to transactional resources are reversed.
You can prevent the transaction from being rolled back, and control the extent to which message changes are reversed, by including a TryCatch node in your message flow. If an exception is thrown beyond the Try terminal of the TryCatch node, then an exception list is propagated to the node’s Catch terminal. The inflight message reverts to the state it was in before it reached the TryCatch node.
Other nodes apart from the TryCatch node have a Catch terminal. These nodes are typically at the start of a transaction, where an uncaught exception would cause a rollback. In these nodes, the Catch terminal behaves as though a TryCatch node was wired directly to the Out terminal. Use the Catch terminal to handle any exceptions that are thrown beyond the node in the message flow. Wire the Failure terminal to handle errors within the node itself.
You can choose one or more of these options in your message flows:
If you include user-defined nodes in your message flow, you must see the information provided with the node to understand how you might handle errors with these nodes. The descriptions in this section cover only the built-in nodes.
When you design your error handling approach, consider the following factors:
When an exception is detected in a node, the message and the exception information are propagated to the node's Failure terminal. If the node does not have a Failure terminal, or it is not connected, the broker throws an exception and returns control to the closest upstream node that can process it. This node might be a TryCatch node, an AggregateReply node, or the input node.
If an MQInput node detects an internal error, its behavior is slightly different; if the Failure terminal is not connected, it attempts to put the message to the input queue's backout requeue queue, or (if that is not defined) to the dead letter queue of the broker's queue manager.
For more information, see Handling MQInput errors.
A message is propagated to a Catch terminal only if it has first been propagated beyond the node (for example, to the nodes connected to the Out terminal).
For more information, see Handling MQInput errors and Handling timeout notification errors.
The fail flow is also started if an exception is generated beyond the MQInput node (in either out or catch flows), the message is transactional, and the reinstatement of the message on the input queue causes the backout count to reach the backout threshold.
The HTTPInput node does not propagate the message to the Failure terminal if an exception is generated beyond the node and you have not connected the Catch terminal.
For more information, see Connecting failure terminals, Managing errors in the input node, and Catching exceptions in a TryCatch node.
If your message flows include database updates, the way in which you configure the nodes that interact with those databases can also affect the way that errors are handled:
For more information about coordinated database updates, see Configuring transactionality for message flows.
Message flows for aggregation involve additional factors that are not discussed in this topic. For information about message flows for aggregation, see Handling exceptions in aggregation flows.
You can view information about samples only when you use the product documentation that is integrated with the IBM® Integration Toolkit or the online product documentation. You can run samples only when you use the product documentation that is integrated with the IBM Integration Toolkit.
Last updated Friday, 21 July 2017