Use the Fan Out mediation primitive to create different messages from a repeating element in the input message. Also, use the Fan Out mediation primitive, together with the Fan In mediation primitive, to aggregate (combine) service responses.
You can use the Fan Out mediation primitive to iterate through an input message that contains a repeating element, and store each instance of the repeating element in the service message object (SMO) context. The Fan Out mediation primitive does not change the body of the input message.
The Fan Out mediation primitive has one input terminal (in), two output terminals (out and noOccurrences), and a fail terminal (fail). The in terminal is wired to accept a message and the other terminals are wired to propagate a message.
If an exception occurs during the processing of the input message, the fail terminal propagates the input message, together with any exception information.
In default mode, the out terminal is used to propagate the input message and the terminal is fired only once. In iterate mode, the out terminal is also used to propagate the input message, but the terminal is fired once for each occurrence of the repeating element. Each time the terminal is fired the value of the current element is placed in the FanOutContext. The noOccurrences terminal is only used in iterate mode, and is used if the input message does not contain any occurrences in the repeating element.
When in iterate mode the out terminal is fired once for each occurrence of the repeating element that you specify, using an XPath expression. Each occurrence of the repeating element is stored in a FanOutContext field.
If you use a Fan Out mediation primitive followed by a Fan In mediation primitive, you can aggregate the responses from two or more service invocations; the group of mediation primitives that occur between a Fan Out and a Fan In is called an aggregation block. If an aggregation block contains Service Invoke mediation primitives on multiple branches, and the Service Invoke primitives are configured for asynchronous invocation, the service calls are processed in parallel. The parallel processing occurs in the following way: there is only one thread, but that thread makes all the service calls and then checks for the responses. You can configure when the responses are checked, using the Batch Count property.
You can use the Fan Out and Fan In mediation primitives to aggregate the responses from two service invocations into one output message. For example, you could retrieve a customer credit score from two credit agencies, then average the two scores.
The shared context area of the SMO is for storing aggregation data between a Fan Out primitive and a Fan In primitive. The shared context is a thread-based storage area that is shared in the same thread. The content of the shared context business object does not persist across a request flow and a response flow, through callout invocation. Whatever data is in the shared context of the request flow cannot be reused during the response flow. Therefore, you can only aggregate in a particular flow: a Fan In mediation primitive in a response flow cannot be used to aggregate messages from a Fan Out mediation primitive in a request flow.
Like the transient and correlation context, the shared context is defined as a user-provided business object on the input node of the mediation flow. After you have defined the shared context you can use it to store data during aggregation operations. You need to design the shared context business object carefully, to ensure it is suitable for all aggregation scenarios in a specific flow.
The Fan In primitive allows for the aggregation of data that results from the use of a Fan Out primitive. You can aggregate data by processing the shared context, using transformations or mappings in other mediation primitives.
An integer of 0 equates to: Check for asynchronous responses after all messages have been fired. Therefore, the Fan Out mediation primitive fires all aggregation iterations before checking for any asynchronous service responses.
An integer of greater than 0 equates to: Check for asynchronous responses after {n} messages have been fired, where you can specify the value of {n}. This allows you to specify how many messages should be fired before asynchronous responses are handled. For example, a count of 1 would fire a single aggregation iteration and all resulting service responses would be received and processed before starting the next aggregation iteration (this is the default). The service responses would all be received before starting the next iteration. A count of 2 means there would be a maximum of two firings of the Fan Out output terminal before all service responses were collected. If the number of output terminal firings was not an exact multiple of 2 then any service responses resulting from the final firing would still be collected and processed as normal.
Property | Valid Values | Default |
---|---|---|
once | Boolean: true or false | true |
for each element in XPath expression | XPath | |
Batch Count | Integer value of 0 Check for asynchronous responses after all messages have been fired |
|
Integer value greater than 0 Check for asynchronous responses after {n} messages have been fired |
Consider the following when using the Fan Out mediation primitive: