Ticker

6/recent/ticker-posts

Error and Exception handling in IIB / App Connect Enterprise & MQ



Error and Exception handling in IIB & MQ

Before going into how to handle the error and exception in IIB let’s first understand the actual meaning of error & exception in IIB/MQ.

Basically, there are two types of Error & Exception in IIB :- 1. Internal Errors within the node , 2. Downstream errors with respect to the input node.

Default behavior of nodes in IIB –  ‘in case of any internal error ( ie validation failure in MQ input node or Exception inside compute node ) the broker checks for the failure handling of that particular node  ie it tries to pass the message to failure terminal if connected it will generate the exception and pass the original message which was input to that node to the failure terminal flow , If failure terminal not connected then:-


If the node where exception occurred is not an Input Node , then Broker will look for the catch terminal of previous node ie if try catch node is used before compute node broker will pass the control and exception to the catch terminal of try catch node to process , if try catch is not there then it will look for the other node where the catch terminal is connected and that can go generally to the Input node of the message flow ie MQ Input Node catch terminal from there catch flow has to process the message as broker assumes that you are handling the error by yourself now.

If the node where the internal exception occurred is one of the Input Node ie File Input node , MQ input node  then also if it’s internal error the broker tries to pass the error to failure terminal path if connected, if not connected
And input node is MQ Input node then broker places the message into the back out Queue of input queue if available if failed to put message then places into Dead letter queue. And the message is not passed to the catch terminal even if it’s connected.

Next is if there is an exception beyond the input node the broker looks for the failure terminal of the node of exception and if it’s not connected broker passes the exception to the catch terminal of either Input Node or the try catch node if any connected before of the node of exception.

So in general the error handling in IIB is – “ If there is any internal error in the node , node will try to place message in failure terminal of the node if available else it will generate exception and throw it back to the previous upstream node’s catch terminal ie tryCatch node or the input node itself if its connected. “ if not connected and if it’s MQ input node then it will follow the below path

If Message is Transactional  Message (Received under a sync point on MQ) – then broker will put the message back into local Queue and try to process again if Back out threshold limit of the local queue is set 2 or more, if so broker will process message again via out terminal of MQ input node to the out flow.  If transaction property is set to automatic and the input message is persistence message broker receives the message under the sync point and treat this as a transactional message and follow the same pattern as in case of a transactional message if set to No and message is persistence this creates no effect. The message will placed in the blackout queue only if message is transnational. And if the failure terminal of the MQ Input node is connected - Message will not be placed in the backout Queue instead it will be passed on the failure flow.

If message is non Transactional   Message – It will be handled as per the other nodes ie. File Input Node. It will first look for the failure terminal if not connected it will come back to previous node where catch is terminal is connected and exception will be processed via Catch then and broker will not take any further action. If in case of MQ input node if catch not connected message will be lost.

Common for transnational and non transactional messages - If there is any further exception in catch flow , Broker treat the scenario as if there is Catch terminal connected to the MQ Input node to avoid the loop. and it will be processed accordingly ie If It's MQ input node ---


Extending the handing further - If there is further exception in Failure flow of the connected node :-

In this case also broker treats this as a normal exception and try to process it via Catch terminal of previous node or same node if any connected.

If there is exception in the Catch flow :- in this case broker throws the exception back to the previous or input node broker treats this as there are no catch terminal connected ie. if it's mq input node broker put the message back into input queue and check for back out threshold limit if its more then 1 broker places the message into the out flow of the mq input node for reprocessing as a New message if there again same exception in the further nodes or the failure flow of any node , broker pass the message to the catch terminal of the mqinput node if there is no exception this time in catch terminal then processing gets completed but however if you need the failed message to be available in the back out queue then you need to explicitly throw the exception from catch flow so that broker will again places the message into inputqueue and check for BO count if its exceeds the limit then broker places the message into the back out queue of the input queue. 




Update 20-12-2019 - I See this post has been viewed by many readers !! One advise to you all don't memories these rules but implement these only then you will understand these actually. :)

Post a Comment

0 Comments