Group nodes and aggregation nodes provide alternative ways to collate related requests and responses. Use these nodes to generate several requests in response to one input message, to control and coordinate the responses that are received in response to those requests, and to combine the information that is provided by the responses to continue processing.
The Group nodes provide the ability to create fan-out/fan-in style static and dynamic aggregation scenarios that are stateless without requiring an IBM® MQ queue manager to be available for the integration server. The GroupScatter node is responsible for creating a new group, and enables downstream nodes to send requests that are marked as part of the group. (The list of currently supported downstream nodes for a group is: MQOutput node (the node must have the “Request” attribute set), HTTPAsyncRequest node, CallableFlowAsyncInvoke node, and RESTAsyncRequest node.)
The Aggregation nodes provide a similar capability, but make use of storage queues that are controlled by IBM MQ so you must install IBM MQ on the same computer as your integration server if you want to use the capabilities that are provided by the aggregation nodes. For more information about the queues that are required by aggregation nodes, see Configuring the storage of events for aggregation nodes.
There is no group node that is equivalent to the AggregateRequest node, rather supported output nodes now directly specify whether they are participating in a group or not by their node properties. Custom transports can still be enabled using Environment overrides.
Testing has shown that the group nodes provide better overall performance when compared to the aggregate nodes, with reduced message processing times and CPU costs.