SAP CPI iFlow Tutorial: Building Your First Integration Flow in 2026
The Ticket That Starts This
Finance wants vendor invoice data pushed from S/4HANA to a banking partner's SFTP server every night, formatted the way that bank's clearing system expects, with a confirmation email if the file fails to land. That request, or something close to it, is what most SAP CPI work actually looks like day to day. Nobody hands a new integration developer a whiteboard and asks for an architecture diagram. They hand over a ticket like that one and expect a working iFlow by Friday.
This walkthrough covers what building that iFlow actually involves, not the theory of enterprise integration patterns, but the sequence of decisions a developer makes inside SAP Integration Suite's Cloud Integration capability to get a message from one system to another correctly.
What's Actually Inside an iFlow
An integration flow is a pipeline with a defined start, a series of processing steps, and an end. The building blocks that do the real work are a handful of repeating shapes: a Content Modifier that adds, removes, or rewrites headers and properties on a message as it passes through; a Router that inspects the message and sends it down one of several paths based on a condition; a Splitter that breaks one incoming message into several outgoing ones (useful when S/4HANA sends a batch of ten invoices as a single IDoc and the target system wants one file per invoice); and an Aggregator that does the reverse, collecting related messages back into one.
None of that runs in a vacuum. Every flow starts and ends at an adapter, the piece that actually talks to something outside CPI. That's where the real complexity of a given project usually lives, more than in the processing logic itself.
Building It, Step by Step
- 1
Design the Interface
Confirm source and target message formats before opening the canvas
- 2
Add the Sender Adapter
IDoc from S/4HANA, or a REST call, depending on the trigger
- 3
Insert a Content Modifier
Strip SAP-internal headers, set the properties downstream steps need
- 4
Map the Payload
Translate source fields to the target schema, one field at a time
- 5
Add the Receiver Adapter
SFTP, REST, or mail, matching what the destination system expects
- 6
Deploy and Monitor
Push to runtime, then watch the Message Processing Log for the first real run
The order matters more than it looks like it should. Skipping straight to the receiver adapter before the mapping is solid is the single most common way a beginner burns an afternoon debugging a "connection failed" error that's actually a malformed payload the target system is quietly rejecting.
When the Flow Needs to Branch
Not every iFlow is a straight line. The invoice example above already isn't: a message that fails validation shouldn't hit the SFTP adapter at all, it should trigger an error notification instead. That's what the Router is for, and it's worth seeing as a decision tree rather than a pipe.
Once a flow has more than one router, it stops being something you can hold in your head and becomes something you need to actually look at. That's the case for sketching it before touching the CPI canvas, not after.
Picking the Right Adapter
The adapter choice is usually dictated by the system on the other end, not by preference, but it's worth knowing the shape of the decision before a client asks why REST wasn't used everywhere.
IDoc
Talking directly to another SAP system, including S/4HANA itself
REST/SOAP
Modern APIs, cloud platforms, most non-SAP web services
SFTP
Batch files with banks, vendors, or legacy systems that don't do APIs
Notifications and the integrations nobody formally documented
Where Beginners Actually Get Stuck
It's rarely the adapters. It's the Groovy Script step. CPI lets you drop into custom Groovy code for anything the graphical steps can't handle, and it's tempting to reach for it constantly, since it can technically do almost anything. The problem shows up later: six months in, a flow with four Groovy scripts is the one nobody on the team wants to touch during an incident, because Content Modifier and standard Message Mapping would have handled the same logic in a way the next developer could actually read. The course's own Integration Flows module deliberately sequences Content Modifier, Router, and Splitter/Aggregator before anything code-based, for exactly this reason: the graphical steps solve most real problems, and Groovy should be the exception, not the default.
Value mapping trips people up too, but for a different reason. It looks trivial in a demo (map "US" to "USA") and becomes genuinely painful in production when the source system adds a new country code nobody told the integration team about, silently breaking a flow that had been running fine for months.
Getting Hands-On
Reading about iFlow steps and building one against a live SAP demo system are different skills, and the second one is what actually matters when a real ticket lands. SkyTrainings' SAP CPI course runs on an actual SAP demo environment rather than screenshots, which is where the adapter and mapping quirks above stop being abstract.
Start with the fundamentals if this is new territory. Explore the SAP CPI course.