Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
This blog shows how to use the splitter flow step in a local integration process. It provides sample scenarios and describes the existing limitations and restrictions.

Usage of Splitter Flow Steps in Local Process

There are various splitter flow steps available in Cloud Integration, that can be used in integration flow processes and in local integration processes. Using a splitters in an integration flow process is fairly straight forward, but it may behave unexpectedly in a local integration process. There are also several exceptions and limitations you should be aware of when configuring the scenario. Because of this, the integration flow designer gives an error/warning when you configure a splitter in a local integration process.

Splitter in Local Process

You can configure the different splitters in integration processes or in a local integration process. If you use the splitter in a local process special rules and restrictions apply, which are described in this blog using some sample scenarios.

Check Error for IDoc and PKCS7 Splitter

The new version (after 18-Februar-2018) of the IDoc and PKCS7 Splitter cannot be used anymore in local integration processes. You will get a check error if you try to use it. You need to configure the scenario with the IDoc or PKCS7 Splitter in the main process.

Warning for Iterating and General Splitter

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. This is to make you aware that the splitter may not work as expected in this scenario and that certain restrictions apply.

Important Restrictions for Iterating and General Splitter in Local Process

You need to take the following important constraints into account when configuring a splitter in a local integration process:

  • 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

    • Splitter -> Gather

    • Splitter -> Splitter …-> Gather -> Gather…

    • Splitter -> Gather -> Splitter -> Gather…

    • Splitter -> Splitter -> Gather

  • You cannot use a splitter without a child element in a local process. This will raise an error during deployment

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

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

    • 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

    • 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

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


Sample Scenario 1: Splitter with Send Step in Local Process

As stated above, you can use the Iterating or General Splitter in a local processes together with a child element. In this scenario, we use the Send step together with General Splitter in a local process.

To showcase the runtime behavior, we build an easy sample:

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

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


<z id="1">1</z>

<z id="2">2</z>

<z id="3">3</z>

<z id="4">4</z>


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

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

  • 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.

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

  • In the Content Modifier in the local process, the filename to be used by the SFTP adapter, is set to a unique name containing a value from the payload, to make sure that the messages are not overwritten in the SFTP directory.

When you deploy the integration flow, you can see how the message is processed at runtime.

  • Receiver1 gets the message as configured in the content modifier.

  • Receiver3 gets the split messages; two messages, with two entries each (as configured for the grouping).

  • Receiver2 gets the same message as Receiver1, because the message returned to the main process is the message as it was before it was processed by the splitter.

To clarify: in the below scenario below, another Content Modifier is added before the splitter, which changes the payload. Now, Receiver2 gets the payload as it is set in this Content Modifier. So, if the splitter is used in a local process, it is always the payload that is forwarded to the splitter that is given back to the main process. The only exception to this is when the splitter is combined with Gather, which is described in the next sample scenario.


Sample Scenario 2: Splitter with Gather in Local Process

As stated already, you can use the Iterating or General Splitter together with a Gather step in local processes. In the scenario, we use one Gather step together with General Splitter in a local process.

To showcase the runtime behavior for the Splitter - Gather combination, we adjust the above scenario as follows:

  • Add a Gather step after the Send step.

  • Add another Send step to write the payload to SFTP after the Gather step.

When you run this scenario, the runtime behavior differs from our previous example as follows:

  • Receiver1 gets the original message as configured in the content modifier.

  • Receiver3 gets the split messages; two messages, with two 2 entries each (as configured for the grouping).

  • Receiver4 gets the message aggregated by the Gather step.

  • Receiver2 now gets the same message as Receiver4, because the processing is returned to the main process after the end of the local integration process.


Further Readings

For more configuration recommendations in respect to Splitter also check out the following blogs: