If you do not know what you are trying to accomplish, the task is even harder to do. If you do not know how to do the task, it is even more difficult. How many times have you started to develop a solution before understanding the requirements — input data formats, the arrival rates, processing needs, and the expected output? How much do you really know about the tools that you are using and the full power that those tools can bring to the solution? To make the best choices when designing and implementing message flows, you need a clear understanding of the requirements and the power of the tools that you are using.

Message flows should be bullet proof, meaning that the design should provide the required functions and should also prevent errors from disrupting normal operations. For example, a message flow is bullet proof when:

- A problem is recognized early and its impact is minimized.

- A problem is diagnosed on the fly and corrective action taken.

- Information about what was happening at the point of failure is collected and recorded.

- The message flow takes proactive steps to notify someone about the problem with details about the problem.

This paper examines some of the capabilities of WebSphere Message Broker and shows how to include these capabilities in your message flows. We use variations on a sample message flow using an MQInput node, several Compute nodes, and MQOutput nodes to show error path options, how the broker handles errors in various nodes, and the information available for analysis. We do not discuss all possibilities and options in this paper. Many of the discussion points rely heavily on, and have borrowed information that is provided in, the WebSphere Message Broker documentation and help files. When you need more detail or when questions arise, refer to this material.

Error handling principles

What happens when exceptions occur

First failure data capture

Error recovery considerations

Error notification considerations

Putting it into practice