Exception/Error Flow in IIB (IBM Integration Bus)

Any developer or designer should give the highest priority to error handling for quality delivery.

Let's understand how the error flow happens in IIB with reference to the below flow.

Say the failure occurred at the compute node in the above flow.

How Transactionality of Message Is Affected by Transaction Property of Input Node

If transaction property is set to “automatic/yes” and the input message is persistence, the message broker receives the message under the sync point and treats this as a transactional message. If transaction property is set to No and the message is persistence, this creates no effect (treated as non-transactional message).

A Few Things to Consider for Effective Error Handling

Always connect the Failure terminal and the Catch terminal of the input node to the exception handling process.

Ensure that all messages that are received by an MQInput node are either transactional or non-transactional for the length of entire flow, and avoid ambiguous configurations.

It's good practice to have a try-catch node in the middle of complex flows, thus the exception is handled with less time and CPU usage because if only the input node has to handle exception of big flows (having too many nodes and complexity), the failed message control has to travel all the way back to the input node, causing heavy usage of memory, CPU, and time.