# SAP CPI Explained: What Cloud Integration Does and How iFlows Work

SAP CPI, short for Cloud Platform Integration and now officially called Cloud Integration, is the capability inside SAP Integration Suite that runs integration flows, known as iFlows. An iFlow moves and converts messages between a sender and a receiver using adapters, mapping steps, and content modifiers. It is SAP's managed middleware for cloud and hybrid scenarios, and it is the cloud successor to the older on-premise SAP PI/PO.

CPI is the piece of SAP Integration Suite people actually spend their day in. The API management and connector catalog get the marketing, but when a project says "we built the integration in SAP," they almost always mean an iFlow running in Cloud Integration. If you have worked with SAP Process Integration, the mental model carries over even though the tooling looks nothing like the old Enterprise Services Repository.

Cloud Integration is a service you provision on SAP Business Technology Platform as part of SAP Integration Suite. You build integration flows in a web-based editor, deploy them to a runtime SAP hosts, and monitor the messages that pass through. SAP documents the service in the SAP Help Portal Cloud Integration guide.

The naming has caused years of confusion, so it is worth settling once. The service started as HANA Cloud Integration, became Cloud Platform Integration (CPI), and is now Cloud Integration inside the Integration Suite umbrella. People still say CPI in conversation. They all point at the same thing: the iFlow engine. We cover where it sits in the wider platform in our SAP Integration Suite guide.

An iFlow is a pipeline. A message comes in from a sender, passes through a series of processing steps, and goes out to a receiver. Three kinds of building blocks do the work.

1. Adapters connect the iFlow to the outside world. The sender adapter decides how a message arrives (an HTTPS call, a file on SFTP, an OData request), and the receiver adapter decides where it goes.

2. Mapping steps convert the source structure into the target structure. This is usually a graphical message mapping, though you can drop into Groovy or XSLT when the logic gets past what the mapping UI can express.

3. Content modifiers and routers set headers and properties, enrich the payload, and branch the flow based on message content.

Pro Tip

An iFlow is middleware you can read top to bottom. The value is that the routing, mapping, and error handling live in one deployable artifact instead of scattered across callouts nobody owns.

That single-artifact property is why teams migrating off hand-built integrations like it. Compare that to the point-to-point sprawl we describe in our native integration vs. iPaaS comparison, where every new flow is another script with its own private error handling.

The adapter list is long, but a handful cover most real work.

Source: SAP Help Portal, Cloud Integration adapter documentation, 2026.

The choice of adapter is mostly dictated by the systems on each end. A modern S/4HANA receiver wants OData. An older ECC system on the other end often means IDoc. A trading partner dropping EDI files means SFTP. You match the adapter to what the system exposes, not the other way around.

SAP Process Integration, later Process Orchestration (PI/PO), was the on-premise integration platform for a generation of SAP landscapes. It ran on your own servers, kept its design objects in the Enterprise Services Repository, and configured runtime in the Integration Directory.

CPI is the cloud replacement. The concepts rhyme: a message mapping in PI/PO is a message mapping in CPI, and a communication channel becomes an adapter. What changes is the operating model. SAP hosts the runtime, you build in a browser, and the whole thing lives on BTP instead of your data center.

Source: SAP Help Portal, Integration Suite and Process Orchestration documentation, 2026.

SAP has set an end date for PI/PO mainstream maintenance later this decade, with extended maintenance available beyond it. That timeline is the main reason teams are moving iFlows to CPI now rather than waiting.

Here is a common one: a trading partner drops a sales order file on SFTP, and it needs to become a sales order in S/4HANA.

1. Sender. An SFTP adapter polls the partner folder and picks up the order file on a schedule.

2. Content modifier. Set properties the rest of the flow needs, such as the partner ID and a timestamp, so downstream steps and logs can reference them.

3. Message mapping. Map the partner's file structure onto the S/4HANA sales order structure. Fields like customer number, material, and quantity line up to their target counterparts.

4. Receiver. An OData adapter calls the S/4HANA sales order service and creates the order.

5. Error handling. An exception subprocess catches failures, writes the original payload to a dead-letter folder, and raises an alert so a person can look at it.

The mapping step is where most first iFlows break, and the cause is almost always namespaces. If the source XSD declares a namespace and your test payload leaves it off, the message mapping matches nothing and quietly produces an empty target. Before you blame the mapping logic, confirm the namespace in the payload matches the schema exactly. That one check saves hours. For the wider set of patterns these flows fall into, our Salesforce integration patterns and best practices covers the same design decisions from the CRM side.

What is SAP CPI? SAP CPI (Cloud Platform Integration), now called Cloud Integration, is the capability inside SAP Integration Suite that runs integration flows called iFlows. It moves and converts messages between systems using adapters, mapping steps, and content modifiers, and SAP hosts the runtime on Business Technology Platform.

Is SAP CPI the same as Cloud Integration? Yes. The service was renamed. It began as HANA Cloud Integration, became Cloud Platform Integration (CPI), and is now Cloud Integration within the Integration Suite. People still say CPI in day-to-day conversation, but it refers to the same iFlow engine.

What is an iFlow in SAP CPI? An iFlow, or integration flow, is a pipeline that takes a message from a sender adapter, runs it through processing steps like mapping and content modifiers, and delivers it to a receiver adapter. It is the single deployable artifact that holds the routing, conversion, and error handling for one integration.

What is the difference between CPI and SAP PI/PO? SAP PI/PO is the older on-premise integration platform you host and manage yourself. CPI (Cloud Integration) is the cloud successor: SAP hosts the runtime on BTP, you build iFlows in a browser, and the design objects live in the Integration Suite rather than the on-premise Enterprise Services Repository.

What adapters does SAP CPI support? CPI supports a wide range, but the common ones are HTTPS, SOAP, OData, IDoc, SFTP, and ProcessDirect. OData suits modern S/4HANA APIs, IDoc suits older ECC systems, and SFTP suits batch and EDI file exchange. You pick the adapter based on what each connected system exposes.

About the author. Sunny Chauhan is the founder of appnigma.ai, where we build native Salesforce apps and integrations without glue code. He's a Salesforce-certified Platform Developer II who spent the better part of a decade building integrations and managed packages, including work at Zennify and Salesforce, before founding appnigma. Most of our hands-on work sits on the Salesforce side, which is why we care about the same thing on any platform: integration logic you can read and monitor in one place, not scattered across scripts.

If you're weighing CPI against a lighter point-to-point build, what's pushing you toward middleware: the message volume, or the need to actually see why a sync failed?