Table of Contents generated with DocToc
- Timeout Notification is controlled by Timeout Control
- Failure and Catch terminals
- MQ Failure and Catch
- Try Catch node
In the same way that cron jobs operate to a set interval. IIB does this with the Timeout Notification and Timeout Control nodes. You have a Timeout Notification connected to say an MQ Output node and set it's interval property to 20 seconds. Once this flow is deployed it triggers every 20 seconds. You can have a Timeout Notification on it's own but you cannot have a Timeout Control without a Timeout Notification. Timeout Notification is controlled by Timeout Control so long as they both have the same unique identifier. You also need to set the operation mode of the Timeout Notification to Controlled, not Automatic. The Timeout Control node has a Request location property InputRoot.XMLNSC.EmpDetails.TimeoutRequest. Within the Timeout you will have an Action, Identifier, StartDate etc. DEC292020-IIB Timeout_LabelRouting_MultiQueues
An Exception will roll back to first node (The exception will always be in the last child of the ExceptionList) then it will check if the catch exception is handled or not DEC212020-IIB FixHTTPProdCon_ESQLThrow 36 minutes. If it is then the Message and ExceptionList trees are passed to the node at the end of the catch terminal. The ExceptionList will contain the exception that will give you a better idea of what & where in the flow the problem happened. If there is an exception raised while processing downflow of the Catch then the exception will feedback then traverse the Failure node path only if Transaction Mode is Yes. If catch is not connected it will check if Failure is connected. Then the default exception and NOT the exception we threw go to the node at the end of the Failure terminal only if Transaction Mode is Yes. The default exception will say you did not handle the Catch. The advantage of the Catch terminal is that you will get an exception which will give you a better idea of what & where in the flow the problem happened.
If the format of the input message is not correct, then the flow will traverse the Failure terminal only.
When the message that is not handled goes back to the IN queue the message is considered a poison message as it will not allow new messages to be 'MQGET' by the flow until the poison message is removed since it is LIFO. The poison message can be handled by designating another queue as the backout queue to the IN via MQ Explorer or giving the backout queue name in the flow or setting a DLQ. DEC212020-IIB FixHTTPProdCon_ESQLThrow 36 minutes
DEC302020-IIB RoutingTryCatchTrace 28 minutes
This allows us to handle the exception further up the flow. The catch terminal will send the message and the ExceptionList. Your terminal goes to a Compute node to handle the exception.