The General Splitter is configured with XPath //z and with Grouping set to 2.

In the second branch the message is sent to a Local Process, where it is split, and each split message is sent out using SFTP by a Send step.

In the first branch the message is sent out as it is using SFTP.

Parallel Multicast is used to route the message to two receivers to show the difference in runtime processing.

The message is created using a Content Modifier, which sets the body to a simple sample XML:.

In the main process, a message is triggered by a Timer step.

To showcase the runtime behavior, we build an easy sample: In this scenario, we use the Send step together with General Splitter in a local process. Sample Scenario 1: Splitter with Send Step in Local ProcessĪs stated above, you can use the Iterating or General Splitter in a local processes together with a child element.

Combinations with different flow steps in the local process need extra testing, because they may behave differently than in the main process.

If Splitter is used in local process in combination with any other steps except Gather (for example Send, Request-Reply ) the message returned into main process is the message before splitter.

If splitter is used in local process in combination with Gather, the message returned to main process is the message at the end of local process.

There is always one message going into the local process and one message returning from the local process to the main process.

Some steps that would be useful are Send, Request-Reply and Gather. You can use any flow step for this, but most do not make sense in the context of the scenario.

Splitters in local processes need a child element.

This will raise an error during deployment

You cannot use a splitter without a child element in a local process.

Splitter -> Gather -> Splitter -> Gather….

Splitter -> Splitter …-> Gather -> Gather….

Combining a splitter and a gather step works in the same way as in main process, but you must close each splitter step with a gather step.

You need to take the following important constraints into account when configuring a splitter in a local integration process: Important Restrictions for Iterating and General Splitter in Local Process This is to make you aware that the splitter may not work as expected in this scenario and that certain restrictions apply. The new version of the Iterating and General Splitter produces a warning (after 18-Februar-2018) if you use it in a local integration process. Warning for Iterating and General Splitter You need to configure the scenario with the IDoc or PKCS7 Splitter in the main process. You will get a check error if you try to use it. The new version (after 18-Februar-2018) of the IDoc and PKCS7 Splitter cannot be used anymore in local integration processes. If you use the splitter in a local process special rules and restrictions apply, which are described in this blog using some sample scenarios.

You can configure the different splitters in integration processes or in a local integration process. Because of this, the integration flow designer gives an error/warning when you configure a splitter in a local integration process. There are also several exceptions and limitations you should be aware of when configuring the scenario. Using a splitters in an integration flow process is fairly straight forward, but it may behave unexpectedly in a local integration process. There are various splitter flow steps available in Cloud Integration, that can be used in integration flow processes and in local integration processes. Usage of Splitter Flow Steps in Local Process It provides sample scenarios and describes the existing limitations and restrictions.

This blog shows how to use the splitter flow step in a local integration process.

Cue splitter general exception occurred