The main purpose of the Split component is to split single messages into multiple messages based on a configured expression. The split messages are sent to the endpoint at the bottom of the component so they can be enriched. If some components are connected to the right endpoint of the split component, then the splitted messages will be aggregated back to one single message after they are enriched via the components connected to the bottom of the split component. This aggregated message will be sent to the components that are connected to the right endpoint of the split component.
The Split component has the following configuration options:
This component has the following configuration options:
- Namespace prefix
- Use Streaming
- Split parallel
- Exchange pattern
The expression that defines how to split messages.
This determines the type of the specified expression.
The prefix of the namespace that is used in the XML.
The namespace that is used in the XML.
The type of messages you want to aggregate. Select
None if you don't want to
aggregate the splitted messages. Also note that the original ingoing message will
also come out of the component via the endpoint on the right.
Split the input message in chunks to reduce memory overhead (used when dealing with large file sizes).
Split each message concurrently. Note that the component will still wait until all messages have been fully processed before it continues. It's only the processing of the splitted messages that happens concurrently.
Parallel splitting may cause a severe increase of system usage, such as CPU, as everything happens concurrently. We do not recommend to enable this option when splitting large files.
This option determines how the messages are sent to the bottom route and the route
on the right.
One way means that the splitter will do the splitting in a asynchronous
way so order is not guaranteed. You want to use this option when:
- The order of the splitted messages doesn't matter.
- When you don't want to wait for all the splitting to be done before the original
input message is sent to the component on the right.
- When aggregation is enabled the splitter will also wait for the complete splitting to finish, because it uses the processed split messages for the aggregation.
- Each split message can go through a lot of logic, for example: an outbound flow link that connects to a big flow which in turn connects to another big flow.
Request reply is the opposite of the
One way option. This is a sequential
way of splitting which will guarantee the order of splitted messages. The splitter
will also wait until the splitting process is done before continuing to the component
on the right even when there is no aggregation.
Request reply the timeout option of the flow may need to be increased when
the splitting process can take some time.
Helpful headers set by the component
The component sets some headers on each splitted message which can be helpful in some cases:
|int||A counter that increases for each message being split. It starts from |
|int||The total number of messages that are splitted. During stream based splitting (Use Streaming set to |
|boolean||Whether or not the splitted message is the last.|
Input message: collection of Java objects
Output messages: one message for each Java Object
Splitting messages using the given Simple expression can be useful if you've constructed a message containing a collection of Java objects using the Script component.
<bookstore> <book title="one"/> <book title="two"/> </bookstore>
<book title="one"/> and
Split component without aggregation
The message will be splitted into multiple messages following the expression and every message will be sent to the HTTP component.
Split component with aggregation.
Just like the example above the splitted messages will be sent to the endpoint at the bottom of the splitter. In this example the splitter has a connection on its right endpoint, so it wil aggregate the enriched splitted messages into one message and sent it to the remaining components in the flow that are connected to the right endpoint.
Filter component in the bottom route
It is possible that side effects occur in the case that a filter component is
used in the bottom route of the split component when the aggregation setting is
true. If the conditions of the filter component are not met, the original
message will be returned by the filter component to the split component.
The message body that is processed by the split component:
<orders> <order> <ordernr>1</ordernr> </order> <order> <ordernr>2</ordernr> </order> </orders>
This message will be split by this xpath expression:
The filter component contains the following xpath expression:
/order/ordernr/text() != '1'
The velcocity component after the split component contains this message body:
<orderNew> <ordernr>New</ordernr> </orderNew>
The aggregated message that comes out of the split component:
<Aggregated> <order> <ordernr>1</ordernr> </order> <orderNew> <ordernr>New</ordernr> </orderNew> </Aggregated>
This output could be unexpected because it contains a part of the original message
body, but there is an alternative solution. Instead of the
filter component you can use a
content router component with the same xpath
expression and a velocity component in the
otherwise route with this content:
The input is similar to the first case, the response of the flow is as follows:
<Aggregated> <orderNew/> <orderNew> <ordernr>New</ordernr> </orderNew> </Aggregated>