An integration flow (iFlow) is an integration artifact that enables the specification of how a message is processed on a tenant. As such, an iFlow can be viewed as a cross-system process that is executed to process messages in a particular way based on an underlying integration scenario. Each executable process step and their parameters are defined in Cloud Integration. You can either create iFlows from scratch or leverage SAP's rich library of pre-configured content.
Components
The makeup of an iFlow depends on the underlying integration scenario. However, different element types can be distinguished, which are then leveraged to suit a particular purpose within an integration process.
Let's look at some of the iFlow components in more detail.
Senders and Receivers
Typically, an iFlow is developed to specify the way messages are processed between sender and receiver systems. These can be any supported source and target systems (for example, SAP S/4HANA Cloud → Ariba). For the connection between source and target system to the tenant, the preferred technical protocols can be designated.
Adapters
The SAP Integration Suite offers a plethora of standard adapters. To give you an idea of the types of remote systems that can be connected to the integration platform, here are some typical examples (this is not a complete list):
- On-premise systems, for example, SAP systems based on SAP NetWeaver
- SFTP servers
- Cloud applications, for example, SAP SuccessFactors
- Other systems such as e-mail servers or SOAP clients
Standard adapters for these systems include but are not limited to:
- Cloud Connector adapter to securely connect your integration flows to your on-premise landscape
- ProcessDirect adapter for flow-to-flow communication
- SOAP
- OData
- JMS
- HTTPS
- Kafka
- ODC
- AS2
- SFTP
- SAP SuccessFactors
- SAP Ariba
- Open Connectors
- And so on
Adapters are available via the Discover tab in your tenant or via the SAP API Business Hub.
Adapter Types
You should also be aware that not all adapters function in the same way:
- Pushing sender adapters provide an endpoint that can be called by external senders
- Parallel executions possible
- Execution schedule not configurable but controlled by incoming messages
- Polling sender adapters run at scheduled times and pick up the data from the source system
- Only one execution at a time
- Configurable execution schedule
Events
The following events are available to work with in Cloud Integration:

Message Processing Elements
You can specify your desired integration pattern by adding a dedicated integration flow step or a combination of various integration flow steps to an integration flow.
Transforming and Converting Messages
Message transformers allow you to convert messages from one format to another. The figure below shows the transformers supported by Cloud Integration.
Mapping
Message mapping defines the logic that maps input message structures with the required format of output message structures.

Operation mapping is used to relate an outbound service interface operation with an inbound service interface operation.

XSLT (Extensible Stylesheet Language Transformations) mapping transforms XML documents into other XML documents, HTML, or text. The transformation capability in the XSLT mapping step leverages the XSLT 3.0 specification.
A value mapping artifact is used to represent multiple values for a single object in different contexts. Value mapping groups can be created or uploaded as a value mapping artifact in an integration package.
Routing and Controlling Messages
Routing messages enables you to link a certain processing path at runtime with a certain XML or non-XML condition. A list of available routing options is shown in the following figure:

Let's take a closer look at each of the routing options.
- Multicast
- Enables you to send copies of the same message at runtime to multiple branches/routes without interfering with each other which can be executed either in parallel (parallel multicast) or in a specific order (sequential multicast).
- Join
- Merges the control of all multicast branches back into one branch.
- Splitter
- This process step helps to break composite messages into individual messages based on certain criteria. The general splitter breaks down XML and non-XML files, can use grouping and parallel processing while keeping the enveloping elements. An iterating splitter is similar but removes the enveloping elements.
- Gather
- Merges the content of the individual multicast/splitter messages. Identical headers and properties are overridden and all branches are merged (including abandoned ones).
- Aggregator
- Merges multiple XML messages into a single message.
External Calls
Besides routing, external calls are an important element to enhance an integration flow with information from external sources. You can send intermediate messages to external targets and continue flow processing normally after the external call. The available options are shown in the figure below.
Pool
In order to limit the complexity of an integration process and increase readability, integration developers can use local integration processes. These represent partial modularized units of the main integration process that are then called in the overarching iFlow by using either a simple process call (local process is called once) or a looping process call (local process is called multiple times based on XPath or non-XML condition). Local process calls can also be nested within each other.

A good application scenario is, for example, an exception subprocess to catch and handle any exceptions that might occur during the execution of an iFlow, including any supplementary processing action.
Consume and Process APIs
Over the next three units, you will be guided step-by-step through the process of integrating an SAP S/4HANA Cloud system through the use of the SAP API Business Hub with non-SAP applications following the eCarHero business needs previously described. For this, you will be using the tools of the SAP Integration Suite, combining the different capabilities.
In this unit, you will start building your first integration artifacts, pulling data of a purchase order (PO) from an SAP S/4HANA Cloud ERP system in preparation for subsequently sending a purchase order notification to the supplier. For this, several steps, such as the configuration of communication arrangements, are required. You will now focus on the creation of integration artifacts and the consumption of third-party APIs.
In case you run into issues during the configuration process, we suggest re-reading the corresponding steps carefully. Please also consider the available assistance documentation SAP provides free of charge and any offered additional resources.
Important resources to consider for this and the following units are as follows:
Summary
The Cloud Integration capability within SAP Integration Suite is an integration service that is used directly in the browser. It works in DevOps mode, that is, development and monitoring can be used in a common area. A variety of predefined scenarios can be used directly out of the box. Adapters in the input and output offer many possibilities for connection to internal and external systems. Scripting, mapping, and many integration features such as routing and splitting are available.
Further Reading
Since Cloud Integration is part of SAP Integration Suite, you can find the relevant information here:
Visit SAP Cloud Integration on SAP Help Portal for a condensed introduction to this topic. provides a condensed introduction to the topic.