SAP Cloud Integration

Cloud Integration — often called CPI (Cloud Platform Integration) — is the capability inside SAP Integration Suite where you design and run integration flows. It is the engine that moves data between systems. You build a graphical workflow, deploy it to the cloud, and CPI runs it automatically whenever a trigger fires.

Think of CPI as a conveyor belt in a factory. You design the belt — how long it is, what steps happen along the way, where it starts and where it ends. Once you switch it on, products move along it automatically without anyone watching. CPI does the same for data.

Key Concepts in CPI

Integration Flow (iFlow)

An iFlow is the core building block of CPI. It is a graphical diagram that shows the path data takes from a sender system to a receiver system. Each step in the diagram performs a specific action — read a message, transform it, route it, or deliver it. You design iFlows using a drag-and-drop web interface inside SAP Integration Suite.

Message

A message is the data packet that travels through an iFlow. It has two parts:

• Header – Metadata about the message (sender ID, timestamp, content type)
• Body (Payload) – The actual business data (the order details, the employee record, the invoice)

Every step in the iFlow can read or modify both the header and the body.

Integration Package

An integration package is a container that holds one or more related iFlows. For example, all iFlows related to Salesforce integration might sit inside one package called "Salesforce Integration." Packages help organize your work and make it easy to transport related iFlows together across environments.

The Anatomy of an iFlow

[Sender]──→[START EVENT]──→[STEP 1]──→[STEP 2]──→[STEP 3]──→[END EVENT]──→[Receiver]
              (Trigger)     (Read)    (Transform)  (Route)    (Send)

Every iFlow follows this pattern. The sender triggers the flow. One or more processing steps act on the data. The receiver gets the final result. The steps between start and end are where all the business logic lives.

Common iFlow Steps

Content Modifier

Sets or changes values in the message header or body. Use it to add a timestamp, set a correlation ID, or inject a static value into the payload.

Message Mapping

Transforms the structure of the message. If the source sends XML in one format and SAP expects XML in a different format, the message mapping step converts one to the other by defining which source field maps to which target field.

Router

Directs the message to different paths based on conditions. If the order value is above $10,000, send to the approval path. Otherwise, send directly to processing.

Filter

Removes parts of the message that are not needed downstream. Reduces payload size and removes sensitive fields before sending to a third party.

Groovy Script

Runs custom code written in the Groovy programming language. Use this when built-in steps cannot handle the logic you need. Most integration scenarios work without scripting, but complex transformations or custom calculations often require it.

Adapters: How CPI Connects to Systems

An adapter is the connector between CPI and an external system. Each adapter knows how to speak the language of a specific technology. CPI includes adapters for dozens of technologies out of the box:

• HTTP Adapter – Sends and receives data over HTTP/HTTPS
• SFTP Adapter – Reads and writes files on an SFTP server
• IDoc Adapter – Sends and receives SAP IDocs
• SOAP Adapter – Calls SOAP web services
• OData Adapter – Calls OData APIs (common in SAP S/4HANA)
• JDBC Adapter – Connects directly to databases
• Mail Adapter – Sends emails with attachments

Sender and Receiver Adapters

SENDER SIDE                              RECEIVER SIDE
──────────────────────────────────────────────────────
[External System]                        [SAP S/4HANA]
       │                                      ▲
       │  uses Sender Adapter                 │ uses Receiver Adapter
       ↓                                      │
[iFlow Start] ──→ [Processing Steps] ──→ [iFlow End]

The sender adapter defines how CPI receives messages from the source. The receiver adapter defines how CPI sends messages to the target. The same adapter technology (for example, HTTP) can appear on both the sender and receiver side.

The CPI Web Interface

You design iFlows in a browser-based graphical editor. The interface has several sections:

• Design area – Where you drag and drop steps to build iFlows
• Monitor area – Where you see running and completed message instances
• Manage area – Where you handle security artifacts, certificates, and data stores
• Settings area – Where you configure tenant-level properties

The graphical design approach means you can build powerful integrations without writing much code. A well-designed iFlow is readable at a glance — even a non-technical business analyst can understand what data flows where.

Deploying an iFlow

After you build an iFlow, you deploy it. Deployment packages your iFlow and runs it on SAP's cloud servers. Once deployed, the iFlow is live and processes messages according to its trigger.

Deployment in CPI is fast — typically under a minute. Unlike traditional software deployments that require server restarts and maintenance windows, CPI deploys with zero downtime. The old version keeps running until the new version is ready, then traffic switches automatically.

Message Processing Logs

Every message that passes through an iFlow creates a message processing log (MPL). The MPL records:

• When the message arrived
• Which steps it passed through
• Whether it succeeded or failed
• What error occurred if it failed
• How long each step took

Message processing logs are your primary debugging tool. When an integration fails, you open the MPL and trace exactly where the message went wrong. This is far more efficient than reading server log files line by line.

Tenant Structure

In CPI, a tenant is your isolated environment on SAP's cloud servers. Your organization's iFlows, certificates, and configurations all live inside your tenant. Other organizations' tenants are completely separate — there is no risk of data leakage between tenants.

Large organizations often have multiple tenants — one for development, one for QA, and one for production — matching the three-system landscape concept covered in earlier topics.