Skip to Content
Author's profile photo Timo Gerards

An integrated approach to extend pre-packaged SAP Cloud Platform Integration Flows with custom fields

When working with pre-packaged integration flows one will quickly reach the point where the flow’s standard scope needs to be extended by custom fields. When this happens it is possible to simply edit the flow by uploading extended interface definitions and mapping the custom fields accordingly. However, by changing the flow’s elements you lose the option of executing updates. Furthermore, it can be a real struggle if inside the message mapping element you get lost when trying to draw your custom mapping lines within the mass of standard lines.

Therefore, in this blog I’d like to show you one approach you can follow to extend pre-packaged iFlows with custom fields, whilst maintaining the option to execute updates of the standard flow elements. To give you a better grasp of the steps required I am using a simple standard flow with a small payload as an example.

Copying the standard iFlow

Before we start to alter the integration flow according to our custom requirements, it is recommended to make a copy of the standard flow in order to keep the possibility to receive standard updates. Thus, you should make the following changes only to the copied flow. Whenever there is an update available that you would like to receive, just make another copy of the standard flow and incorporate your custom elements. Here you can find more information on the update rules for iFlow components.

Bypassing the standard message mapping

In the following screenshot you see the pre-packaged flow for replicating business partner data from C4C to Hybris Marketing Cloud. The integration process consists of a content modifier (adding some information to the message header), two message mappings (mapping the data from the source to the target fields), and a groovy script (further enriching the message header). Since we do not want to change the standard elements, but still want to insert and map our custom fields, we insert a bypass for the yellow marked elements.

By inserting a parallel multicast as the first step of the iFlow the incoming message is sent to the connected elements in parallel.  In this way we can introduce a message mapping element for our custom fields (yellow marked) while allowing the standard elements to remain unaffected. By using the Join and Gather elements we recombine the two messages.


Mapping the custom fields

For your custom message mapping you need to download the custom interface definitions of your source and target protocol. In the mapping screen just assign the corresponding custom fields.


Collecting the two messages

After the standard mapping the message’s payload could for example look like this:

When only mapping one custom field, the result of the custom mapping may look as follows:

Within the Gather element, by using an XPath expression, we are able to select the XML node at which the two messages are combined.

After joining and gathering the message now looks as follows:


Completing the new message’s payload

Before the message is finally sent to the target system we need to do some further processing in order to get a valid message. Therefore, we insert three content modifiers (marked yellow).


Add XML Header

Within the element Parsing Payload we just add an XML header in order to be able to work on the message with XPath expressions in the next step.


Create XPath Headers

This modifier creates three new header variables:

The first one (meta) stores all meta information below the ImportHeader node except the Persons node:

The other two variables (person1person2) store the first and second Person node within the Persons node:


Create Target Payload

Finally the message is built according to the target ODATA service. The standard and custom fields are combined within one Person element:

The final message body looks as follows:


How do I test all of this?

After building the integration flow with the above approach you surely want to monitor and test all your manipulations to the message’s payload. This can easily be achieved by changing the log level of the deployed iFlow from Info to Trace. To find this option, within SAP Cloud Platform Integration, you just need to navigate from the menu Monitor to Manage Integration Content. After selecting the iFlow just look for the section Log Configuration at the bottom:

After the iFlow has been executed you can view the log by navigating to the Monitor Message Processing site. There you can examine the message’s payload for each step of the iFlow:


Do I need every update for my integration package?

If you want to find out what has actually changed in your integration package, just navigate to the document section of the integration package. There you will find collective release notes on the new features for each iFlow.



If you have any questions just leave a comment and I will get back to you.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Naresh Dasika
      Naresh Dasika

      Hello Timo- Nice blog!!. This way without touching the standard integration flow components custom fields can be added  in a separate new message mapping and the changes are always clean & separate. One can always refer back to the standard version in case of any updates.

      Author's profile photo Pravesh Shukla
      Pravesh Shukla

      Hi Timo,

      Very well explained, Good Job! 🙂



      Pravesh Shukla

      Author's profile photo Dominic Beckbauer
      Dominic Beckbauer

      Nice post Timo!

      Author's profile photo Rashmi Joshi
      Rashmi Joshi

      Hi Timo,


      Please help me to understand how you insert parallel multicast in standard IFlow as we are not supposed to edit it.