Error Handling in WebSphere Message Broker
Lets discuss Exception handling in message broker, this post will concentrate on Architectural details of Error Handling in Message flows.Our scenario is, we have a flow which has three stages of processing
First lets look at the General Error Handling process, we will have a sub flow do this process just to eliminate redundancy.Most errors in flows occur due to incorrect input data, these kind of problems sometimes can be dealt entirely in the flow itself but in most cases the input message needs reprocessing by the source side[Sender side], such type of messages are meant to be logged for reference of which messages failed and which got successfully processed, and this is the main aim of error handling, it doesn't mean that there wont be other failures, but the main aim of error handling is to either log the error causing message or to notify a team which is responsible for sending the message.
Error handling flow's architecture mainly depends on the client's way of handling errors, what i mean to say is the client decides the processing of an erroneous message in a way that would fit to his requirement, he may demand that every error has to be logged in a log file, or to insert them into a database table or even send a email to a specific group with the failed message as an attachment.
Coming to the flow which handles general errors and fits into most of the requirement scenarios....
this flow handles errors in two different stages.First it logs them to a default error database which is visible to entire corporation, the idea behind default logging is when interfaces are developed and deployed into production errors caused by the flows are exclusively monitored by a separate production support team, generally MB developers, but developers alone cant solve data issues so we take one step further...parse the message and categorize it into a specific group and email a specific group that there has been an error.
where do we use this sub-flow in the main flow?? that's pretty obvious, at the catch terminal of the Input Node.
when a failure occurs the input message is propagated to the catch terminal of input node, and the sequence of nodes connected to the catch terminal receive this failed message, hear the trace node is used to take a flow specific trace of the error
lets capture the local environment, exception list and add a time stamp while updating the trace file.
To handle errors in a more specific way and to stop the message flow from failure even after an Exception, we will have to use Try-Catch node, the Try catch node works just like try catch in java it catches any exception caused down the stream and propagates it to the catch terminal. The message propagated to the catch terminal is identical to the message received by it, an additional exception information tree is attached to the actual message and propagated.
As shown in the above flow we can use subflows to handle errors and process the erroneous message and take a decision based on client spec..whether to fail the transaction or to just log the failure and proceed, in the above flow you can see that each catch terminal is connected to a sub flow and a throw Node, this setup indicates that the error is never handled in the subflow as the throw node raises an exception at the end.
you can use a compute node in place of the subflow and decide weather to propagate to the next terminal or to keep quite...
the entire concept of error processing concentrates mainly on the client's spec and to keep a log of unprocessed transactions because each message lost is business lost for the client.
- Computing the Order
- Checking the Warehouse
- Dispatching the order
First lets look at the General Error Handling process, we will have a sub flow do this process just to eliminate redundancy.Most errors in flows occur due to incorrect input data, these kind of problems sometimes can be dealt entirely in the flow itself but in most cases the input message needs reprocessing by the source side[Sender side], such type of messages are meant to be logged for reference of which messages failed and which got successfully processed, and this is the main aim of error handling, it doesn't mean that there wont be other failures, but the main aim of error handling is to either log the error causing message or to notify a team which is responsible for sending the message.
Error handling flow's architecture mainly depends on the client's way of handling errors, what i mean to say is the client decides the processing of an erroneous message in a way that would fit to his requirement, he may demand that every error has to be logged in a log file, or to insert them into a database table or even send a email to a specific group with the failed message as an attachment.
Coming to the flow which handles general errors and fits into most of the requirement scenarios....
where do we use this sub-flow in the main flow?? that's pretty obvious, at the catch terminal of the Input Node.
lets capture the local environment, exception list and add a time stamp while updating the trace file.
${CURRENT_TIMESTAMP} ${ExceptionList} ${Root.MQMD} ${Environment}this type of error handling has a draw back, you cant handle errors specifically, if you want to perform any operation after the second compute node after a failure occurred and then decide whether to fail the transaction or not... you simply cant... this kind of exception handling has no capability to do it.
To handle errors in a more specific way and to stop the message flow from failure even after an Exception, we will have to use Try-Catch node, the Try catch node works just like try catch in java it catches any exception caused down the stream and propagates it to the catch terminal. The message propagated to the catch terminal is identical to the message received by it, an additional exception information tree is attached to the actual message and propagated.
As shown in the above flow we can use subflows to handle errors and process the erroneous message and take a decision based on client spec..whether to fail the transaction or to just log the failure and proceed, in the above flow you can see that each catch terminal is connected to a sub flow and a throw Node, this setup indicates that the error is never handled in the subflow as the throw node raises an exception at the end.
you can use a compute node in place of the subflow and decide weather to propagate to the next terminal or to keep quite...
the entire concept of error processing concentrates mainly on the client's spec and to keep a log of unprocessed transactions because each message lost is business lost for the client.
No comments:
Post a Comment