This blog article is a 2 part series on how to us WMB 8 Patterns, The content was derived from my latest training course WebSphere Message Broker 8 Developer Essentials available from The Middleware Shop

Part 1





Part 2





Time to market a product depends very much on the productivity of the development team. Overall productivity of a project depends on lot of factors including time spent on coding/configuring software, time spent on testing the product and fixing issues etc.

WebSphere Message Broker provides something called Patterns or “application templates” that can be used to build an application rapidly. A pattern is a reusable solution to a commonly occurring problem. Refer to Appendix A to know the list of built-in patterns available in WebSphere Message Broker 8.0. A pattern instance can be generated rapidly from a pattern using the toolkit by providing the pattern parameters.

In the toolkit, a pattern instance is organized as a combination of a pattern instance project and message broker application. The message broker application is referenced by the Pattern instance project. The generated message broker application can be tested and deployed just like any other message broker application.

The built-in patterns are production ready and follow best practices. This helps reduce the cost of quality involved in the project. It is important to understand that patterns are not available for all scenarios and are only available for certain requirements that occur frequently.

Using Patterns

In this HowTo, We are going to use a simple built-in pattern called “MQ one-way (XML)” found under “Message Splitter” group in Pattern Explorer. This pattern helps in building a message broker application that receives an XML message from a MQ Queue, splits the message based on a criterion and routes the messages to different MQ Queues.

In Vega Water purifiers, the status of Annual Maintenance Contracts (AMC) of all the customers is reviewed everyday and a report is generated. The report provides a list of customers whose AMC is going to expire within a month’s time.

The Notification department accepts a message per customer. So the report pulled from Customer Information component needs to be split and the customer records are to be sent as independent messages to the Notification department. The Notification department sends out emails to the customers requesting them to renew their AMCs.

Select a pattern

Let us first select the required pattern from the list of built-in patterns.

  • In WebSphere Message Broker toolkit, Click Window menu | Show View menu-item | Patterns Explorer menu-item

In the Patterns Explorer we can see the list of built-in patterns. The Message Splitter pattern is ideal for our requirement.

  • Click on “MQ one-way (XML)” pattern found under “Message Splitter” folder

A view titled “Pattern Specification” is displayed as shown below. In this particular case, the toolkit is not able to locate and use a web browser available in the machine and has opened the pattern specification outside the toolkit application. Read the pattern specification and confirm that the pattern is suitable for the requirement at hand.

  • Click “Create New Instance” button in the view titled Pattern Specification

A pop-up dialog prompts for a name for the Pattern instance. The Pattern instance is going to be just like any other Message Broker application. So follow the application naming conventions that you have in your organization.

  • Give a name to the Pattern instance, say “AmcExpiryRptSplitter”
  • Click OK button

Now the pattern parameters that are to be configured are displayed in the toolkit. The mandatory parameters are marked with an asterisk character.

Provide pattern parameters and generate pattern instance

  • In the Configure Pattern Parameters screen, Select “No routing” from Routing drop down

At this point, let us check the AMC expiry report that we are going to get from Customer Information component. This is also going to be the sample XML that we are going use to test the application (i.e. the Pattern instance).

<?xml version=”1.0″ encoding=”UTF-8″?>
<p:amcExpiryReport xmlns:p=”” xmlns:xsi=”” xsi:schemaLocation=” vega_custinfo.xsd “>
<p:customer id=”3828″>





<p:customer id=”3829″>






We want to create a separate message for every customer element in the report. Note that the customer elements are contained within the root element called “amcExpiryReport“.

  • Expand Input Information section
  • Enter the name of the MQ Queue that the application needs to check for input messages, say “”
  • Enter the XML element that is the container for the elements that are to be split in the Container name field

If the element in the XML is namespace qualified, then the namespace can be given in full.

For example

But if the XML uses just one namespace, then a wildcard character (asterisk) can be used to represent any namespace.

For example


  • Enter the child element name (element found within the container element) in the Message element name field

Do not prefix an asterisk in “Message element name” field (i.e. *:customer in our example) to denote “any namespace” if you have provided it in “Container name” field. The “ExtractRecords” method in the ESQL file MessageSplitter.esql fails to identify the child elements with the name mentioned in Message element name field if you do so.

Since we have selected “No routing” option for “Routing” property in Input Information section, the Specify routes and Lookup routes controls are disabled. Also by default “Logging” is disabled, if required we can enable Logging feature.

  • Expand the section “No routing”
  • Type the output queue name in the “Output queue” text field, say “notification.amcexpiry.out”
  • Provide the Output queue manager name in Output queue manager field

The application that we are going to generate will route the messages to this queue.

  • Expand the “Error handling” section
  • Enter the name of a queue that we are going to use as the error queue for the application, say “notification.amcexpiry.error”, in the Error queue field
  • Enter the Queue Manager name in the “Error queue manager” field

  • Expand General section
  • Enter the broker schema that is to be used for the message flows, say “notification”
  • Enter the prefix that is to be used for the message flow names in the Flow prefix text field, say “amcExpiry”
  • Provide a description to document the purpose of the message flow in the Long description field

Use a Flow prefix whenever you generate a Pattern instance from a pattern. Later on, when you create another pattern instance from the same pattern, it will be easy for you to distinguish the message flows.

Use a broker schema that does not contain any period characters. If you use periods, the Pattern instance generation reports errors.

  • Click the Generate button found at the bottom of “Configure Pattern Parameter” screen

Note the following.

  1. A new Pattern instance with the name “AmcExpiryRptSplitter” appears under “Pattern Instances” in Broker Development view.
  2. A Summary file is generated within the Pattern instance project.
  3. The message flows are generated within the folder “notification” as we used the broker schema “notification”
  4. The message flow names are prefixed with the flow prefix that we used, i.e. “amcExpiry”

The pattern instance is generated and ready. Now we can create and configure the required resources.

The remaining part of this article is found in Part 1


Leave a Reply