Skip to content

WebSphere Message Broker (WMB) Tips – Part 1

by on November 21, 2011

Based on feedback, we are going to start a series of blog postings related to WebSphere Message Broker (WMB) tips.  These will focus on broadly across architecture, design, development, testing, infrastructure, and administration.  We will post these as our consultants submit tips based on real client implementations.   We will try to put together postings of 3-5 tips and publish them regularly.

1. Be efficient with your for loops in mapping. 

Specifically with using mapping nodes, by dragging and dropping, it may create 2 for loops for the same high level loop when mapping 2 different fields.

The following is an example of a mapping that was generated from dragging and dropping 2 elements from the same loops:

You will notice that 2 different for loops were created for the same loop.  The following image is a more efficient mapping by only having to iterate through the for loop once to map the 2 fields.

This is a mapping node example, but these types of loops should also be reviewed in your custom ESQL or Java logic within your message flows.

2.  Use XMLNSC over MRM for XML domains

Using XMLNSC typically has better performance over MRM and it is also more compliant with XML Schema 1.0.  However, there are times when you are better off using MRM.  Some of these are:

  •   To validate or process based on specific field types (i.e. dates, integers, etc).  XMLNSC is all string based.
  •   To map XML directly from input MRM structure.  This can be handled in MRM by supporting the XML domain within the same message set.

3.  KISS – with error handling. 

In general, keep error handling simple, otherwise you end up troubleshooting your error handling frame-work as much as your business processes.  There are times advanced, specific, low-level error handling is needed, but in general, the following pattern should be followed:

  • System Exception occurs or error is caught and exception is thrown
  • Original Input node to message flow should catch this (it will have the original message and the exception that happened)
  • Error processing built off of catch terminal to preserve original message, build error message, notify users, and potentially call automated processes (i.e. shut down message flow to keep from repetitive system errors from happening).

There are many examples of ESQL to capture specific errors from the exception list.  This will enable you to build common subflows to replace your input node and build in your common error handling off the catch terminal.

Additional tips will follow in future postings.  Please feel free to provide feedback or submit additional tips that you would like shared with the WMB community.

Thank you,



From → Integration

One Comment
  1. anurag permalink

    this was cool!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: