SAP Integration Flow (iFlow)
An Integration Flow — called an iFlow — is the core unit of work in SAP Cloud Integration (CPI). It is a graphical representation of how data moves from a sender system, through processing steps, to a receiver system. You build iFlows using a drag-and-drop designer in your browser. Once deployed, an iFlow runs automatically whenever its trigger fires.
Think of an iFlow like a recipe card. The recipe lists every step in order: preheat the oven, mix the ingredients, pour into a pan, bake for 30 minutes, serve. The chef (CPI) follows the recipe every time, without deviation. Your iFlow is the recipe; CPI is the chef that executes it.
iFlow Building Blocks
Every iFlow is assembled from building blocks called flow steps. These steps fall into categories:
Events (Start and End)
Every iFlow begins with a Start Event and ends with an End Event. The Start Event defines what triggers the iFlow — an incoming HTTP call, a scheduled timer, a file arriving on an SFTP server. The End Event marks where processing completes.
Message Transformers
Steps that change the content or format of the message. Examples: Content Modifier, Message Mapping, XSLT Mapping, Groovy Script, JSON-to-XML Converter.
Call Steps
Steps that reach out to external systems during processing. Examples: Request Reply (call an external service and get a response), Send (fire and forget to an external system).
Routing Steps
Steps that direct the message to different paths based on conditions. Examples: Router (conditional branching), Multicast (send to multiple receivers simultaneously).
Persistence Steps
Steps that store data temporarily inside CPI. Examples: Write Variables, Data Store Write (persist a message for later retrieval).
Security Steps
Steps that encrypt, decrypt, or sign messages. Examples: Encryptor, Decryptor, PGP Encryptor, XML Signature.
A Simple iFlow: HTTP to SAP
[SENDER: External App]
│
│ HTTP POST (JSON payload)
▼
┌──────────────┐
│ START EVENT │ (HTTP Trigger)
│ HTTPS │
└──────┬───────┘
│
▼
┌──────────────────┐
│ JSON to XML │ (Converter Step)
│ Converter │ Turns JSON body into XML
└──────┬───────────┘
│
▼
┌──────────────────┐
│ Content Modifier│ (Transformer Step)
│ │ Adds timestamp to header
└──────┬───────────┘
│
▼
┌──────────────────┐
│ Message Mapping │ (Transformer Step)
│ │ Maps JSON fields to SAP IDoc structure
└──────┬───────────┘
│
▼
┌──────────────────┐
│ IDoc Receiver │ (Receiver Channel)
│ Adapter │ Sends IDoc to SAP system
└──────┬───────────┘
│
▼
┌──────────────┐
│ END EVENT │
└──────────────┘
│
▼
[RECEIVER: SAP S/4HANA]
Message Headers vs Message Body
Every message flowing through an iFlow has two parts that you can read and modify:
- Message Body (Payload) – The actual business data in XML, JSON, or text format. This is what gets transformed and ultimately delivered to the receiver.
- Message Headers – Key-value pairs that carry metadata about the message. Headers are not delivered to the receiver by default. Common headers: Content-Type, SAP_Sender, SAP_Receiver, CamelFileName.
Additionally, CPI provides Exchange Properties — variables scoped to the current iFlow execution. Use properties to store intermediate values that you need to reference later in the same iFlow, such as a counter, a lookup result, or a decision flag.
Integration Process vs Message Flow
Most simple iFlows use a single Integration Process pool — one straight path from sender to receiver. Complex iFlows can contain multiple pools:
- Exception Sub-Process – Runs automatically when an error occurs in the main process. Use it to send error notifications or write failed messages to a data store.
- Local Integration Process – A reusable sub-routine inside the iFlow. Call it multiple times from different points in the main flow. Useful for logic you would otherwise copy-paste.
Deployment and Versioning
After designing an iFlow, you deploy it. CPI compiles the iFlow and runs it on its cloud servers. The iFlow gets a version number automatically. Every saved change creates a new version. You can roll back to a previous version if a new deployment causes problems.
During development, you can undeploy an iFlow at any time to stop it from processing messages. When ready for production, deploy to the production tenant following your organization's change management process.
Externalized Parameters
Hard-coding values like system URLs, port numbers, or usernames directly inside an iFlow is a bad practice. If the URL changes, you must edit and redeploy the iFlow. Instead, use Externalized Parameters — named placeholders that hold values outside the iFlow.
INSIDE iFlow: EXTERNALIZED PARAMETER VALUE:
Receiver URL: SAP_HOST = https://my-s4hana.example.com
{{SAP_HOST}} (stored separately per environment)
The iFlow reads {{SAP_HOST}} at runtime and substitutes the actual value. Changing environments (from QA to production) only requires changing the externalized parameter value — not the iFlow itself. This is how professional teams manage iFlows across multiple environments without maintaining separate versions per environment.
iFlow Simulation
CPI includes a simulation mode where you can test an iFlow without deploying it and without connecting to real systems. You provide a sample input message, and CPI runs the iFlow logic step by step, showing you the message content after each step. This is the fastest way to test a mapping or routing logic during development without risking any real data.
Best Practices for iFlow Design
- Keep each iFlow focused on one integration scenario — one source, one target, one business purpose
- Use meaningful names for iFlows, channels, and steps — "Map_Shopify_Order_to_SAP_IDoc" is better than "Mapping1"
- Always include an Exception Sub-Process that at minimum logs the error and sends an alert
- Use Externalized Parameters for all environment-specific values
- Test with simulation before deploying
- Keep iFlows short enough that you can see the entire flow on one screen without scrolling