Catching a real-life WebSphere MQ exception
- You can easily extend the previous example to show a more complex and realistic exception tree being caught and navigated. Up to this point, you have only considered artificial exceptions produced by a Throw node. Substitute an MQ Output node in the place of the Throw node, but do not configure its Queue name property. Rename the MQ Output node
NO QUEUE. Resave the message flow, and you should see a yellow warning triangle on the corner of the node indicating that the Queue name has not been configured:
- As you have done a few times now, return to the open test client, right-click the Invoke Message Flow level in the hierarchy on the panel on the left, and select Re-run.
The flow should be redeployed and the message sent to the input queue again. This time a new exception should be recorded in the output message written to the queue named
DOTNET.EXCEPTIONS.CATCH. The red box below shows the beginning of the new exception. The full message is displayed in the listing that follows the image:
Listing 11. Output message describing the WebSphere MQ exception, caught after rollback to .NETCompute1
<Message> <Field>( MB8BROKER.default ) An error occurred in node 'DotNetExceptions.NO QUEUE' when opening queue '' on queue manager ''. State = '-1' 'MQW101' '2085' '' An error occurred when a message flow node attempted to open a queue. The reason code from the MQOPEN is displayed as the 3rd (native error) state. Check the WebSphere MQ completion and reason codes in the WebSphere MQ Application Programming Reference to establish the cause of the error, taking any appropriate action. You may have to restart the message broker after you have performed this recovery action.</Field> </Message>
- The exception generated in this example has more levels of nesting, and more inserts than the earlier simple Throw example. The broker exception list from this
example, which the .NETCompute node navigates and then inflates to produce the above output message, is shown below:
This image shows that the .NETCompute node's use of the method
GetBaseExceptionto walk down to the lowest exception in the tree hierarchy has navigated to the exception that contains the root cause of the problem. Typically for Message Broker, this will always be at the most nested part of the exception list. In this example, this root cause is Message Broker exception BIP2666. This example also demonstrates the real power of the
FormattedMessagemethod that the Broker provides, as it reconstructs a human-readable message containing all required inserts.