Introduction and Motivation

The General Splitter is besides the Iterating Splitter one of the most used Flow steps in an IFlow. It helps to reduce the memory footprint of an IFlow by splitting huge incoming Xml payloads into smaller parts of nodes for further processing. In the streaming mode the splitter doesn’t create an internal DOM and already starts to produce chunks before having reached the end of the payload. So the splitter itself has a very small memory footprint.

Please remember: The General Splitter preserves all nodes on the way to the first split point whereas the Iterating Splitter only extracts the nodes at the split point.

In this blog I am going to explain the option “Stop on Exception” for Iterating/General Splitter.

The Option “Stop on Exception”

The following scenario shows a Content Modifier in the Integration Process, which holds a Xml payload in the message body. The payload is sent to the Subprocess “GS_Router”.

Here is an example for the payload to be split

<root> <x> <y> <z id="1">1z> <z id="2">2z> <z id="3">3z> y> <y> <z id="4">4z> <z id="5">5z> <z id="6">6z> y> x> root>

The General Splitter in the Subprocess “GS_Router” splits this payload with the XPath Expression “//z” into 6 chunks which are sent by the “Send”-Step to Receiver2. After splitting the whole payload without any exception the IFlow ends with status COMPLETED.

To simulate an Exception, the “Router” in the Subprocess gets the condition expression  //z[@id=”3″]. In this case the 3. split leads to the “Error End Event”. The behavior now depends on the splitter option “Stop on Exception”.

  • With this option set, the splitter stops after the third split and the IFlow ends in status FAILED. On Receiver2 there are 3 files created.
  • Without “Stop on Exception” the splitter continues splitting and Receiver2 gets all 6 chunks. Also here the IFlow ends in status FAILED.

 

In the next scenario I have moved all steps into a Main Integration Process.

Receiver1 gets the same number of chunks as Receiver2 if the router stays on the default path. Then both Receiver1 and Receiver2 create 6 files with our example payload.

If the “Router” has a condition expression which leads to the “Error End Event” at the 3. split, than the behavior also here depends on the splitter option “Stop on Exception”.

  • With this option set, the splitter stops after the third split and the IFlow ends in status FAILED. On Receiver2 there are 3 files created. Receiver1 only creates 2 files.
  • Without “Stop on Exception” the splitter continues splitting and Receiver2 gets all 6 chunks. The IFlow ends in status FAILED and Receiver1 only creates 5 files.

We notice that Receiver1 always creates 1 file less than Receiver2. What file is missing and why?

To answer this question we extend the Integration Process by an Exception Subprocess.

If we run this scenario Receiver3 always gets the following chunk

 <root> <x> <y> <z id="3">3z> y> x> root>

That is the missing file of Receiver1! It is the 3. chunk where the exception has raised.

 

At the bottom of the blog I’ll tell you how to create unique file names when using splitter with SFTP-Receiver.

On the following screen we see the Target of an SFTP-Receiver

If you select “Append Timestamp” you can add a timestamp to each file name but the chunks are produced so fast by the splitter, that the time resolution of this feature is not sufficient.

For really unique file names you can use the Variable ${exchangeId} as part of the file name.

Also ${property.CamelSplitIndex} can be used to number serially the chunks.