Dynamic Message Aggregation

Dynamic Message Aggregation is an extension of the request/reply application model. It combines a group of and concurrent fan-out of a number of similar requests with the fan-in of the corresponding replies and compiles those replies in a single aggregated message.


Business Case:

We are interested to send one bulk main request to IBM Integration Bus (IIB) and IIB will distribute/break-down the request into multiple ‘N’ sub-requests and will send synchronously every sub-request to backend system and then will receive sub-response of each sub-requests and then combine into one main response.

The above business case is designed in below diagram.

In the Below Aggregation Sample you can see how to use the AggregateControl, AggregateRequest, and AggregateReply nodes to perform a basic one-way Synchronous aggregation operation, with simple fan-out and fan-in flows.

FAN OUT

Fan-Out portion is used to break down one main message into sub-messages synchronously.

In the above example we are getting the main Request in REQUEST.IN node and pushing that to “Aggregation Control” node to endorse that the request is in aggregation and then breaking the request up to n requests and pushing/storing into MQ queue. This is done in the Compute node using an ESQL loop.


Backend External Process:

In the below process we are getting each message from queue and then pushing to another queue

Processing Each Message

We are receiving each request from queue and then processing to create external HTTP request and then receive each response to store in the MQ.

FAN IN

And in Fan-In section we put together all the messages by means of the correlation ID of each message on aggregation reply node, in case any message fails or doesn’t hold the correlation id then the Aggregation will throw an exception. After summing up all the messages into one message it will push into RESPONSE.OUT MQ node.

Note: Please consider below points
  • 1) Aggregate Control and Aggregate Reply Name should be same

  • 2) Timeout should not be zero, put some positive value.

  • 3) The Correlation ID is to be included in the MQMD of a message when put on a queue. Also this Correlation ID will be matched against while getting a message from a queue.

  • 4) Keep the Header intact.

This Dynamic Message Aggregation service allows you to split a large message into N sub-requests and process them in parallel. You can trigger backend service over MQ or as a webservice. For more information email us at [email protected] or visit www.royalcyber.com

Leave a Reply