Error Handling in WebSphere Message Broker

Error Handling in WebSphere Message Broker

When designing a message flow in MB, we often stress on main flows rather than on error handling. Well AFAIK Error Handling techniques & design principles are more crucial than designing the best path.

Design Consideration

• Connect the Failure terminal of any node to a sequence of nodes that processes the node's internal exception (the Failure flow).
• Connect the Catch terminal of the input node or a Try Catch node to a sequence of nodes that processes exceptions that are generated beyond it (the Catch flow).
• Insert one or more Try Catch nodes at specific points in the message flow to catch and process exceptions that are generated by the flow that is connected to the Try terminal.
• Ensure that all messages that are received by an MQInput node are processed within a transaction or are not processed within a transaction.

Understanding the Flow Sequence

• When an exception is detected within a node, the message and the exception information are propagated to the node's Failure terminal ( Diagnostic information is available in the Exception List). 
• If the node does not have a Failure terminal or if it is not connected, the broker throws an exception and returns control to the closest previous node that can process the exception. This node can be a Try Catch node  (Root & Local Environment are reset to the values they had before) or the MQInput node .
• If the catch terminal of the MQInput node is connected, the message is propagated there (Exception List entries are available; Root & Local Environment are reset to the values they had before).Otherwise if is not connected, the transactionality of the message is considered.
• If the message is not transactional, the message is discarded. Otherwise , if it is transactional, the message is returned to the input queue, and it is read again, whereupon the back out count is checked.
• If the back out count has not exceeded its threshold, the message is propagated to the output terminal of the MQInput node for reprocessing. Otherwise if it is exceeded & if the failure terminal of the MQInput node is connected then the message is propagated to that path. (Root is available but Exception List is empty)
• If the failure terminal of the MQInput node is not connected, the message is put on an available queue, in order of preference; message is put in back out queue, if one is defined; otherwise in dead-letter queue, if one is defined. If the message cannot be put on either of these queues, it remains on the input queue in a retry loop until the target queue clears.(It also records the error situation by writing errors to the local error log)

Conclusion:- If the flow has an error in Compute node,then it will be routed back to the MQInput node.Here it checks for whether the Catch Terminal is connected or not.

1. If it is connected it will be routed towards that terminal & falls in that queue.
2. If it is not connected it will  check for Failure Terminal.
3.  If it is connected it will be routed towards that terminal & falls in that queue.
4. If it is not connected it will  check for Transactionality Property.

• If the message is not transactional, the message is discarded. 
•  if the message is transactional, the message is returned to the input queue, and it is read again, whereupon the back out count is checked.