Single Consumer in IBM Sterling B2B Integrator cluster with MQ

Introduction

FIFO processing is a critical requirement in several markets including transportation and logistics.  FIFO or "First In First Out" processing means that messages are processed strictly in the order they were received.  For example a sequence like: PO Create, PO Change, PO Change and PO Cancel must not be executed out of oder where the PO Cancel is seen first, ignored as invalid and then the PO is later Created.  

The simple way to handle FIFO requirements is to single thread but that will not be performant.  B2Bi has a FIFO processing engine but you have to get the messages into the engine in FIFO order.  More info on the B2Bi FIFO engine is avaialble here (https://www.ibm.com/support/knowledgecenter/SS3JSW_5.2.0/com.ibm.help.fifo_msg_processing.doc/SI_FIFO_Overview_.html).

This article relies on the FIFO engine but will talk about how to feed that engine from MQ in a highly available way.  

A solution architecture was requested for FIFO processing of IBM MQ messages across a cluster of IBM Sterling B2B Integrator nodes. For HA, each node would have a listener on the MQ queue.  To maintain FIFO, only one node at a time should pull and load the FIFO engine. 

Solution architecture

Proposed solution includes built in features of IBM MQ, such as clustering and FIFO queues and custom Java code based on IBM’s own AMQSCLM sample program (which is written in C). The idea is to have B2Bi WMQ adapters running on all nodes and listening to their own queue (node specific). A producer would issue an MQ PUT API call to a queue manager part of an MQ cluster which would also encompass all MQ queue managers running on the B2Bi nodes.

Care needs to be taken to ensure all local queues defined have their DEFPSIST(YES) setting to ensure a queue manager restart doesn’t lose the messages. Additionally, we need to set MSGDLVSQ(FIFO) to ensure messages are delivered / retrieved in sequence, which was one of the original requirements.

A modified version of AMQSCLM would run on each queue manager in the cluster and check for messages being consumed. When consumption has stalled (issues with a particular node in the B2Bi cluster), the program:

• chooses another node as the active processing node

• shares the new node’s queue in the cluster, making it a target for new messages, using ALTER QUEUE command with CLUSTER (<name_of_b2bi_mq_cluster>)

• removes the current queue from the MQ cluster, using ALTER QUEUE command with CLUSTER (“”)

•  routes any marooned messages from the current node to this new target, by simply placing them on the cluster queue name (which now belongs to the new active node)

If the requirement wasn’t to have a single node active at a time but rather allow multiple nodes in the cluster to process a message, yet still maintain FIFO order, a simpler solution would have been:

• set up a couple of queues, one CONTROL and one DATA (the actual payload to be processed)
• place a “token” message on the CONTROL queue
• have multiple listeners (MQ adapters in each B2Bi node) attempt to retrieve the token from the CONTROL queue, within a transaction and with an MQ GET timeout option
• whichever listener acquires the token first, forces the other listeners to wait since there’s no message to be retrieved from the CONTROL queue
• the lucky recipient of the token would then process the payload from the DATA queue (taking great care to also enlist the MQ GET within the same transaction – MQ parlay SYNCHPOINT)
• on failure, the DATA and token messages are rolled back together, available to other listeners
• on success, a new token is placed on the CONTROL queue (again, under SYNCHPOINT) and the whole transaction is committed. In effect all 3 messages (original token, payload and new token) are part of the same transaction, ensuring no data loss

Regardless of the option chosen, it is also recommended that MQ queue manager be deployed using Multi-Instance for HA. On the client side, be it custom Java code or configuring B2Bi WMSQ adapter or service, the connection needs to specify a comma separated list of FQDNs or IPs. Each entry in the list corresponds to a queue manager in the Multi-Instance deployment topology.

Products involved

IBM Sterling B2B Integrator

IBM MQ

Custom Java code

Conclusion

Whatever the business need, IBM has the products in our portfolio to create your solution and address those needs.

Special thank you to Vince Tkac, STSM for his B2Bi expertise and overall guidance.