Maintaining the sequence of messages processed by an IBM Integration Bus message flow

In certain business scenarios where IBM® Integration Bus or IBM WebSphere® Message Broker are utilized, it is critically important to process messages in a message flow and route them on to target in the order that they were sent to the flow. This article describes the usage of IBM Integration Bus (or WebSphere Message Broker) Resequence nodes to maintain the sequencing of messages to enable delivery to a target destination in the order they were sent to the message flow. This content is part of the IBM WebSphere Developer Technical Journal.

Karl Gaffney, Software Consultant, IBM

author photoKarl Gaffney is a Software Consultant in the IBM WebSphere Accelerated Value Pro-gram (AVP) Europe, and is based at the IBM Hursley Lab in the U.K. He holds a PhD in Artificial Intelligence andl has extensive experience as a software test engineer testing a wide range of functionality of WebSphere Application Server across a variety of plat-forms including z/OS.



30 October 2013

Introduction

IBM Integration Bus (formerly known as IBM WebSphere Message Broker) provides highly flexible connectivity and universal data transformation and routing in a wide range of business environments. Messages are typically sent from one or more originating applications or sources to one or more message flows hosted by IBM Integration Bus; the messages are processed, transformed, and intelligently routed to one or more target destinations.

It is often a business requirement that messages be routed on to their target destinations in a specific order, usually in the order in which they were sent to the IBM Integration Bus message flow from the originating application. For example, in a purchase order system with a current purchase goods inventory of 10, you might have Purchase Order Message #1, which increases the inventory by 5, then a Purchase Order Message #2, which decreases the inventory by 15. This is fine, as the inventory clearly now has 15 goods in it after message #1 has been processed. However if message #2 was processed before message #1, then the purchase order would have to be rejected due to an insufficient inventory.

Under normal circumstances, there is no guarantee that messages processed by a flow will be routed to the target destination in the order in which they were either sent by the originating application or arrived at the message flow. This problem is exacerbated when multiple instances of the same flow exist on separate brokers to facilitate parallel processing (for performance) and high availability.

This article will explain the use of IBM Integration Bus Resequence nodes to ensure the sequence integrity of messages processed by one or more message flows, in parallel or otherwise. The messages will originate from multiple source applications and will utilize IBM WebSphere MQ as the message transport. A reusable Resequence flow pattern will be presented that will maintain the order of messages delivered to target in the same order in which they are sent from the originating applications.


Example environment

In the example described here, two JMS applications (App1 and App2) send messages independently and concurrently to an arbitrary IBM Integration Bus message flow for processing and then routing to a target WebSphere MQ queue for consumption by a destination application (App3) — although any supported protocol such as SOAP or HTTP can be used. In this hypothetical business environment, it is imperative that the messages are delivered to the target queue in the order in which they were dispatched from each originating application.

Figure 1. Overview of example environment
Overview of example environment

In this typical configuration, it cannot be guaranteed that the messages will be delivered to the target in order. This becomes even less likely if multiple instances of the message flow are employed, for example, with a load balancer.

The Resequence node in IBM Integration Bus enables messages to be forwarded in an order determined by a sequence number associated with the message. This sequence number (SequenceID) is an integer value and, in this environment, is added to the MQRFH2 header in the originating application.

Another integer property on the Resequence node is the sequence group identifier (GroupID). This is defined by the IBM Integration Bus system administrator, for example, with a unique fixed value issued to each originating application. In this example, App1 will have a GroupID of 1 and App2 a GroupID of 2. Messages arriving at the node can be divided into independent sequence groups based on this identifier in the message. Each group has its own sequence number and is handled completely independently, enabling parallel processing of multiple groups.

Within the originating application, the SequenceID and GroupID are set here as shown in Listing 1 (for App1).

Listing 1. Originating JMS application
int grpID=1;	// '1' is the GroupID for this application

for (long seqID=0; seqID<n; ++seqID) {

	// define JMS objects

	...

	msg = session.createTextMessage("...");
	msg.setLongProperty("SequenceID", seqID);		   
	msg.setIntProperty("GroupID", grpID);

	// send the messages to IIB/WMB
	sender.send(msg);
}

For each specific group identifier, it is a requirement to have the message flow forward messages to the target queue MQOutput in the order defined by the SequenceID.


Resequencer flow

The flow is designed to be unobtrusive and not add any points of failure into the existing system, if at all possible. In other words, if a failure occurs somewhere during resequencing, the message involved will simply be routed onto the output queue as it would have been before deploying the Resequencer flow (albeit with trace added). The Resequencer flow is shown in Figure 2.

Figure 2. Resequencer flow
IBMResequencer flow

The Resequencer flow has two MQInput nodes:

  • MQInput1 accepts messages where it is not known in advance whether SequenceID AND GroupID have been set or not. This is helpful in cases where messages need to be placed to a target queue from multiple sources and maintaining sequence order is unnecessary for some of them. Messages are sent on to a Route node, which determines whether these two properties have been set or not. If they have been set then the messages are sent to the Resequence node, if not then they are forwarded directly to the MQOutput node.
  • MQInput2 accepts messages where it is known that the SequenceID and the GroupID have been set. These messages are routed directly to the Resequence node, bypassing the Route node to avoid computational overheads. It is the responsibility of the business message flow to place the messages on the correct queue.

The Route node has a basic filter set to test whether the two properties have been set as shown in Figure 3.

Figure 3. Setting properties on the Route node
Setting properties on the Route node

The Match output terminal connects to the Resequence node. The Default output terminal connects to the MQOutput node. The Failure output terminal connects to a Trace node (Route_Failure_Trace).

The Resequence node has basic properties set as shown in Figure 4.

Figure 4. Setting properties on the Resequence node
Setting properties on the Resequence node

Notice the Path to sequence number and Path to sequence group identifier have been set to the location of the MQRFH2 header values. The Missing message timeout indicates the length of time in seconds the Resequence node will wait for a missing message to turn up before continuing processing and moving on to the following message.

The timeout timer is started as soon as a message arrives ahead of its required position in the sequence. Once the timeout has been exceeded, messages for this sequence group are then propagated in sequential order to the Expire terminal. Subsequent messages for this sequence group will always be propagated through the Expire terminal. If a message arrives that is not next in sequential order, but whose sequence number is less than the one that triggered the timer, then the timer is reset.

If the “missing” message subsequently arrives at the node after the timeout then it is routed via the Missing output terminal to the MQOutput node via the Missing_message_arrives_Trace node.

A literal start of sequence definition and end of sequence definition have also been defined. These can be anything up to an eighteen digit integer.


Scenarios

The above scenario tolerates some out-of-sequence messages; that is, messages are always propagated to the MQOutput node (main logic path) even if they are routed through the Missing or Expire terminals.

Other scenarios that may be appropriate in a business environment include:

  • Messages must never go out of sequence. In this case, any messages propagated through the Missing or Expire terminals must be handled separately; for example, via a separate queue. The Missing and Expire terminals must be wired accordingly.
  • Missing messages can be tolerated, but all other messages must remain in sequence. In this case, any messages propagated through the Missing terminal must be handled separately, either discarded or processed on a separate logic path. The Missing terminal must be wired accordingly. The Expire terminal can be wired to the main logic path.

Application failure

If the originating application fails, it must maintain the integrity of the sequence and not automatically reset it. If this resetting occurs, the Resequence node will fail to process the messages in sequence order, as it believes these messages have already been processed and propagated. If this happens, the messages will simply be routed on to the MQOutput node without resequencing.

It is therefore the responsibility of the originating application (if an application restart occurs) to either:

  1. Continue with the sequence intact,
  2. OR send an end-of-sequence message using the end-of-sequence SequenceID value (if the literal value has been set on the Resequence node),
  3. OR enable a timeout that results in an automatic reset (if the Automatic option has been selected on the Resequence node).

The same sequence cannot be sent to the Resequence node more than once without the Resequence node receiving an end-of-sequence message for that sequence.

If the Route node fails, messages will be propagated to the MQOutput node without resequencing, either directly via the Default terminal or the Route_Failure_trace node.

If the Resequence node fails, messages will be propagated to the MQOutput node without resequencing via the Resequence_Failure_trace node.

For a full list of Resequence node properties, see the IBM Integration Bus Information Center.

The Resequencer flow is deployed downstream from the business flow(s) as shown in Figure 5.

Figure 5. Deployment of Resequencer flow
Deployment of Resequencer flow

It can also be deployed in the same way if multiple instances of the same business flow are utilized along with a load balancer, for example, as shown in Figure 6. This scenario makes it even less likely that messages will be processed in sequence order in the absence of the Resequencer flow.

Figure 6. Multiple instances of business message flow
Multiple instances of business message flow

Test run

Out-of-sequence events are simulated by sending messages with randomly ordered SequenceIDs from the two originating applications. The results are shown in Figures 7 and 8.

Figure 7. Test results: Message sent
Test results: Message sent
Figure 8. Test results: Message received
Test results: Message received

High availability

To maintain high availability of the Resequencer flow, it can be deployed into a multi-instance environment, strictly in Active-Passive mode. This ensures that message processing is single threaded, which is essential for resequencing. For more details on multi-instance environments, see the Information Center.


Sequence nodes

IBM Integration Bus provides the facility to allocate sequence identifiers to messages as they arrive at a message flow using Sequence nodes. This is useful when sequence ordering needs to be maintained for messages in the order in which they arrive at a flow, rather than the order in which they were sent from an originating application. However, if multiple instances of the same flow are deployed for parallel processing, with a sequence node within each one, then the sequence can only be maintained for each specific flow instance, not globally. For more information on Sequence nodes, see the Information Center.


Conclusion

A Resequencer flow has been developed to ensure messages processed by one or more message flow instance either sequentially or in parallel are routed on to target applications in the same sequentuial order in which they were sent by the originating applications to the message flows. The Resequencer flow is deployed downstream from the main business flows with little re-factoring needed within these business flows to accommodate the new deployed function.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=950307
ArticleTitle=Maintaining the sequence of messages processed by an IBM Integration Bus message flow
publish-date=10302013