Error subflow for the Message Splitter for WebSphere MQ: one-way
(for XML) pattern
If an error occurs, use the Error subflow to route the error message.
To route the error message, use one of the following actions:
- Save any message elements that cannot be routed onto a separate bad message queue and continue
processing further elements
- Cancel the transaction and roll back the input message
Any failure in the Routing flow directs the propagated message, containing one message element, to the
Failure terminal of the Route subflow. The error status is recorded in
Environment.PatternVariables.FailureStatus and the number of bad elements
is incremented.
Choose a Bad message action to determine the action to take following a
failure:
- Save
- The Failure node is connected to an MQOutput node and the message element is written to the bad
message queue. Control is returned to the processing loop in the Message Splitter Compute node and
processing continues.
- When all records are processed, the Message Splitter Compute node passes control to the Error subflow,
where a check is made to determine if any bad message elements are saved. If bad message elements are saved,
and error messages are required, an error message is produced that indicates the number of elements in
error.
- Cancel
- The Failure node of the Route subflow is not connected and routing errors are passed back to the
Message Splitter Compute node, which detects the failure status and generates an exception. Any exceptions,
other than routing failures, cause the Cancel action to occur. It is
assumed that all these exceptions are irrecoverable and it is not safe to continue processing.
- If error messages are required, an error message is prepared and written to the error queue.
Details of the exception are written as an XML message. The details include:
- Broker name
- Flow name
- Time stamp
- Summary of the exception data
- A user error is produced to roll back the input message and any message elements that have already been
processed. In this case, backout handling must be in place within the WebSphere MQ infrastructure; for example,
by using a backout queue.
Backout does not occur on exceptions that occur after all of the message elements have been successfully
written. This type of exception might occur in error messages or log messages.