We had a requirement for a single incoming MQ message to be sent to multiple destinations, the list of destinations to be determined by a look-up to a database table.

For example if we have 3 incoming messages and the look-up on the database shows that:

Message1 destinations: Queue1, Queue2, Queue3
Message2 destinations: Queue2, Queue3
Message3 destinations: Queue1.

The requirement was to output the messages for each destination at the same time. In our example Queue1 would receive Message 1 and 3, Queue2 Message1 and 2 and Queue3 Message1 only.

Our first thought was to use a IIB Destination List but these did not fit the customer requirement, mostly due to need to group together a batch of messages arriving in a given time frame. This led us to look at the IIB Collector Node.

The IIB Collector node makes use of message collections as described in the IIB Knowledge centre here:

http://www.ibm.com/support/knowledgecenter/en/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ac37690_.htm

The collector node is usually used to group multiple incoming messages - from multiple sources - together into one message collection for output to a destination. Our requirement was subtly different in that we needed to output each incoming message to multiple destinations and group the incoming messages to a collection.

At first we used an ESQL compute node to d look up the required destinations list from a database table and then use the ESQL propagate statement to send the message onto to the collector node once for each destination in the database result set. Something like this:





When we tested this message flow we encountered unexpected behaviour in that messages we expected to be in a given collection weren't and we experienced timeout on some collections. When we used IIB user trace to debug the problem we noticed that the BIP4172I messages recording that a message had been added to a collection showed a significant time gap in adding some of the messages to the collections so that these messages were put into a new collection rather than an existing one as we expected.

After opening a PMR with IBM support we established that the Collector Node behaviour we were experiencing was caused by the messages that were propagating all being under the same unit of work. As the IIB documentation wasn't very clear on this point IIB Support opened APAR IT16264 to update the IIB Knowledge Centre.

To achieve what we needed IIB Support suggested splitting the message flow shown above into two message flows. The first message flow would get the incoming message from the MQ Input queue use an ESQL compute node to look up the destination list from the DB2 table and PROPAGATE to send the required number of messages out via an MQ Output node like this:



The second message flow would get the messages from the queue using an MQ Input Node and then pass them onto the Collector Node as before. This solution gave us the required grouping of messages. This second message flow would look like this:



Note: this solution does use a destination list for the output queue so that the destination can be derived from the IIB collection name in the environment tree.