Event sequencing is a technology that requires processing multiple asynchronous requests. The order of some or all of these requests must be kept in order. A common use case is having multiple requests to update an account, and the account must be opened before deposits or withdrawals. This article demonstrates how to configure event sequencing for WebSphere Process Server (hereafter called Process Server) using its development environment, WebSphere Integration Developer (hereafter called Integration Developer).
A WebSphere MQ queue is used to supply an asynchronous channel to demonstrate event sequencing, although you can use event sequencing for processing other types of inputs, such as flat files and EIS systems. In Figure 1, you can see that we have loaded an MQ queue with fictitious purchase order requests. All the records of the same color must be processed in order, but the purples, blues, and reds can be processed in parallel.
Figure 1. Event sequencing example
Event sequencing guarantees that each color is processed in the sequence they are in the queue, while still allowing the other colors to be processed independently. This allows the server to be more fully utilized without compromising data integrity. Without event sequencing, the records are processed serially to keep their order.
One important note is that event sequencing guarantees that messages with the same configurable key are processed in the order they are put on an asynchronous channel like a queue, but event sequencing does not check or correct the sequence of those messages. For instance, if an update for a particular key is placed on the queue before the insert, event sequencing still allows the update to happen first.
Included in the download are complete instructions for configuring and running the sample application. The step-by-step instructions are included in the download.
- IBM® WebSphere Integration Developer 6.2.0.1, including a WebSphere Process Server test environment
- IBM DB2® 8 or 9
- IBM MQ 6 or 7
- Moderate level understanding of WebSphere Integration Developer and MQ
In the sample application, a sender application places messages on a queue based on a purchase order number. The purchase order number is used as the key for event sequencing. The sender application puts one insert followed by two updates on the queue for every purchase order it receives. The updates may be in any order, but the insert is always put ahead of the updates.
A freeware application called SOAPUI is used to send the PO requests to the sender. SOAPUI gives flexibility in increasing the number of requests and concurrent threads to simulate placing a large amount of requests on the queue.
The major components of the application are shown in Figure 2.
Figure 2. Layout of the event sequencing application
With event sequencing turned on, the program always processes the messages in a FIFO (first in first out) sequence that have the same purchase order number. Without event sequencing, the messages are processed asynchronously. There is a possibility an update occurs ahead of the insert, and a DB2 failure is thrown by trying to update a record for which no record exists because the insert was never processed.
WebSphere Integration Developer (development)
Event sequencing requires both development and runtime configuration steps.
Configuring event sequencing is easy and requires just limited XPath knowledge. You configure event sequencing as a Quality of Service (QoS) on the interface of the component connected to the source that needs to be sequenced. In this example, this is the interface of the process that has an MQ export that needs to process messages in order. See Figure 3 and Figure 4 to view the QoS setting for the event sequence qualifier.
Figure 3. Assembly diagram of the event sequencing application
Figure 4. Event sequencing QoS setting
Inspecting the properties for the operation of this interface shows the event sequencing qualifier that was added for this example. The XPath expression /number references a property in the business object called PO, which represents the purchase order in the example. The PO schema is defined in Figure 5.
Figure 5. PurchaseOrder business object schema
Therefore, any purchase orders that have the same number are guaranteed to be processed in their original order on the queue.
WebSphere Process Server (runtime)
In the example used for this article, an MQ queue is used as the source for sequencing via an MQ export binding set in Integration Developer. When an MQ export is defined in Integration Developer, a listener port is generated upon deployment in Process Server.
The message listener service is provided by the base runtime and manages the runtime configuration of the Message Driven Bean that is listening on the queue. This includes the generated listener port, its runtime state, and the listener service settings. When using the MQ binding and event sequencing, a custom property must be set on the messagelistener service as shown in Figure 6.
Figure 6. Custom properties of the Message Listener Service from Administration Console
NON.ASF.RECEIVE.TIMEOUT with a non-zero value is a required custom property on the listener port since the strict ordering of messages is expected with event sequencing.
For additional information about this setting, see the Message listener service custom properties topic in the WebSphere Application Server Information Center.
In the listener port configuration properties, you need to define a Max Sessions variable as shown in Figure 7.
Figure 7. Max sessions setting for the listener port
By default, the "Maximum sessions" field specifies that there is one Message Driven Bean listening on the queue. For event sequencing to work properly, this value must remain one so that all requests are processed for sequencing by the same singleton. Once the message is sequenced, it puts those sequenced messages on the SCA internal queue provided by the service integration bus. From the internal queue, Process Server can process those messages with multiple threads as long as they do not share the same key value.
Note: In a clustered Process Server environment, there can only be one listener port started in the entire cluster. Listener ports can be started and stopped by either scripting or from the Process Server Administration Console. In a clustered environment, you disable the listener ports to start on server startup on all cluster members, except one.
The messages that need to be processed in a sequence are put into the MQ Ext Queue by the client application. The listener port defined on Process Server is listening on this queue and reads one message at a time from the MQ Ext Queue, sequences it, and then puts it on the SCA Int Event Queue. The messages from the SCA Int Event Queue are being read by Process Server for processing, provided that there is a lock available in the Event Lock table (Figure 8). A lock is applied if there is more than one message with the same sequence ID. If there is a lock on a given sequence ID, then that message is not processed until the lock becomes available. By default, Process Server provides 100 locks to process these sequenced messages. These locks are configurable for the runtime.
Figure 8. Illustration of event sequencing
Let’s say you have an insert record followed by Update #1 record and Update #2 record that need to be processed for a given sequence ID. If Update #1 fails to process due to some issue (for example, bad data in the message), then you can optionally select during design time to continue with the processing of Update #2, or you can wait until Update #1 has been corrected and processed. This feature is called strict ordering of messages. This feature needs to be appropriately selected at design time in WebSphere Integration Developer. Figure 9 shows this feature.
Figure 9. Option for strict ordering of messages
The failed transaction will show up in the Failed Event Manager from where you can modify the data and re-submit it for processing. More information about the Failed Event Manager is described in Managing WebSphere Process Server failed events.
Event sequencing is a common pattern when ordering is required while processing asynchronous requests. Event sequencing can be applied to many inbound sources including flat file records, EIS systems, and queues. It is also commonly applied to the interface directly following an export from an SCA adapter or queue. In this article, we have demonstrated the configuration and runtime characteristics of using event sequencing in WebSphere Process Server. In addition, there are instructions for configuring and running the sample program provided in the download.
| Description | Name | Size | Download method |
|---|---|---|---|
| Code sample | EventSequencingFromMQDownload.zip | 5374 KB | HTTP |
Information about download methods
Learn
Discuss

Greg Wadley is a Senior Consulting IT Specialist in the West Integrated Marketing Team providing technical sales support for WebSphere software products with a focus on business integration and business process management. Greg provides hands on proof of concepts, architecture workshops, classroom instruction, and customized technical sales demonstrations to IBM’s top customers. He has worked in IT for over 20 years in a number of positions.

Satish Mamindla is a Senior Consulting IT Specialist in the West Integrated Marketing Team providing technical sales support for WebSphere software products. Satish also works on proof of concepts and teaches classes to demonstrate the product features in Proof of Technology sessions. Satish has worked with customers around the world as a WebSphere consultant in IBM for Software Services for WebSphere (ISSW). He has helped customers design and develop solutions using WebSphere suite of products and helped tune their systems for production.
Comments (Undergoing maintenance)





