Skip to main content

WebSphere Message Broker V6, Best Practices Guide: Bullet Proofing Message Flows

An IBM Redpaper publication

Note: This is publication is now archived. For reference only.

thumbnail 

Published on 11 April 2006

  1. .PDF (0.5 MB)

Share this page:   

IBM Form #: REDP-4043-00


Authors: Geert Van de Putte and Keister Dean

    menu icon

    Abstract

    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.

    Table of Contents

    Error handling principles

    What happens when exceptions occur

    First failure data capture

    Error recovery considerations

    Error notification considerations

    Putting it into practice

     

    Others who read this also read