Split component

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.

Configuration

The Split component has the following configuration options:

This component has the following configuration options:

• Expression
• Type
• Namespace prefix
• Namespace
• Aggregation
• Use Streaming
• Split parallel
• Exchange pattern

Expression

Description

The expression that defines how to split messages.

Type

Options

• Simple
• XPath
• Tokenizer
• JsonPath

Description

This determines the type of the specified expression.

Namespace prefix

Description

The prefix of the namespace that is used in the XML.

Namespace

Description

The namespace that is used in the XML.

Aggregation

Options

• None
• XML
• JSON

Description

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.

Use streaming

Options

• Yes
• No

Description

Split the input message in chunks to reduce memory overhead (used when dealing with large file sizes).

Split parallel

Options

• Yes
• No

Description

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.

Remark

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.

Exchange pattern

Options

• One way
• Request reply (default)

Description

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.

Remarks

• For Request reply the timeout option of the flow may need to be increased when the splitting process can take some time.
• The response to the caller will be the existing Exchange body before reaching the first One way component in the flow.

Helpful headers set by the component

The component sets some headers on each splitted message which can be helpful in some cases:

Header	Type	Description
CamelSplitIndex	int	A counter that increases for each message being split. It starts from 0.
CamelSplitSize	int	The total number of messages that are splitted. During stream based splitting (Use Streaming set to Yes) this header only has a value on the last splitted message.
CamelSplitComplete	boolean	Whether or not the splitted message is the last.

Examples

Expression types

Simple

Input message: collection of Java objects

Expression: ${bodyAs(String)}

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.

XPath

Input message:

<bookstore>
	<book title="one"/>
	<book title="two"/>
</bookstore>

Expression: //book

Output messages: <book title="one"/> and <book title="two"/>

Tokenizer

Input message: one@two@three

Expression: @

Output messages: one, two, and three

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:

<?xml version="1.0" encoding="utf-8"?>
<orders>
	<order>
		<ordernr>1</ordernr>
	</order>
	<order>
		<ordernr>2</ordernr>
	</order>
</orders>

This message will be split by this xpath expression: //order

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: <orderNew/>.

The input is similar to the first case, the response of the flow is as follows:

<Aggregated>
	<orderNew/>
	<orderNew>
		<ordernr>New</ordernr>
	</orderNew>
</Aggregated>