IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Services and service-related functions > Building mediation flows > Aggregating and broadcasting messages

Combining results from different services

You can send one request to multiple services by using the Fan Out primitive, receive responses from those services and then use a Fan in primitive and a Mapping primitive to combine the responses into a new message.

You use the Fan Out primitive to either fire a single input message once or to iterate through the input message and fire each occurrence of a given element, producing multiple output messages.

The Fan In primitive is used as a decision point for continuing flow execution. The primitive will receive messages until the decision point is reached and will fire the output terminal at that point. The Fan In primitive makes decisions in one of three ways:


Important: For every Fan In primitive you use, you must have a related Fan Out primitive.

To stop the Fan In operation you can wire the Stop Input terminal. You can also specify a time period in which the operation must complete. If the decision point has not been met by this time, the Incomplete terminal will fire and the Fan Out and Fan In operation will stop.

The following figure shows a mediation flow that has a Fan Out and Fan In aggregation. The shared context temporarily stores service responses.

  1. The shared context business object is set in the input node. The Message Element Setter primitives, StoreReponse_A and StoreResponse_B will place responses from InvokeService_A and InvokeService_B in the shared context. The Fan In primitive will aggregate the contents of the shared context and will fire the output terminal.

  2. A Fan Out primitive is placed on the canvas and is configured to fire its output only once.

  3. When the Fan Out primitive fires, the message body and the transient and correlation contexts are copied into a new message that is created for each path coming from the output terminal. These messages still point to the same shared context.

  4. The message goes through the path to InvokeService_A first. A a Mapping primitive, CreateInput_A, creates the input message in the form that service A requires and propagates it to the Service Invoke primitive.

  5. The Message Element Setter primitive named StoreResponse_A adds the response from the service to the shared context after which the response is propagated to the Fan in primitive.
  6. Fan In has been configured to fire after it receives two messages and has only received one. The flow backtracks to where the message was split and then follows the path to InvokeService_B.
  7. Just like for InvokeService_A, a Mapping primitive creates the message for the service and a Message Element Setter primitive adds the response from the service to the shared context.

  8. When the path through service B completes and the Fan In primitive receives the second message, the Fan In primitive fires its output terminal. The shared context now contains the responses from service A and B.

  9. The last a Mapping primitive, CreateNewMessage, maps the contents of the shared context to the body of the message as needed.
Because paths run one at a time, no matter how many there are, only one primitive at a time accesses the shared context.

Aggregating and broadcasting messages