Cloud Integration (CPI): Architecture and Use

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 10, 2026 · 14 min read

Where This Article Sits#

References#

1) The Cloud Integration Landscape#

Cloud Integration — historically called CPI — is the process integration capability of SAP Integration Suite. It runs on SAP BTP Cloud Foundry with regions on AWS, Microsoft Azure, and Alibaba Cloud (the Feature Scope Description for SAP Integration Suite confirms Cloud Foundry as the only standard environment, and notes EU-Access contracts cannot use Cloud Foundry outside EU operators). Underneath, CPI runs an Apache Camel routing engine: every iFlow you draw compiles down to Camel routes that the runtime nodes execute (the architecture is summarized in third-party walkthroughs such as Vikas Sharma’s core architecture series).

They are not substitutes.

2) How It Connects to S/4HANA#

                    SAP Integration Suite — Cloud Integration tenant (BTP CF)
   ┌──────────────────────────────────────────────────────────────────────┐
   │  Tenant Management Node (TMN)                                        │
   │  ─ design-time, deployment, monitoring, keystore                     │
   │                                                                      │
   │  Worker nodes (JVM × N, Apache Camel)                                │
   │   ─ iFlow execution: adapter ↔ steps ↔ adapter                       │
   │   ─ JMS queues, Data Store, Variables (per-tenant)                   │
   └──────┬─────────────────────────┬──────────────────────────┬──────────┘
          │ IDoc / RFC / OData      │ OData / REST             │ XI / SOAP / file
          ▼                         ▼                          ▼
   ┌──────────────┐         ┌────────────────┐         ┌──────────────┐
   │ S/4HANA      │         │ S/4HANA        │         │ Trading      │
   │ on-premise   │         │ Cloud (public/ │         │ partners     │
   │ via SAP      │         │ private)       │         │ (AS2/AS4)    │
   │ Cloud        │         └────────────────┘         └──────────────┘
   │ Connector    │
   └──────────────┘

For on-premise S/4HANA, the RFC and IDoc adapters require SAP Cloud Connector as the secure tunnel back to the customer landscape; the FSD documents NetWeaver 7.31 as the supported floor. For S/4HANA Cloud, OAuth 2.0 against a published OData service is the standard pattern, and the OAuth2 Client Credentials flow is supported on the AMQP/WebSocket, OData V2, OData V4, and HTTP receiver adapters per SAP Help on secure authentication methods. Where data residency or low-latency local-system access is required, the same iFlows can be deployed instead to Edge Integration Cell — the customer-managed Kubernetes runtime described in Hybrid Deployment Using Edge Integration Cell.

Key point: Cloud Integration is the routing-and-transformation layer on top of BTP. The reachability of your S/4HANA endpoint depends on Cloud Connector, the adapter, and (for hybrid) Edge Integration Cell — not on the Cloud Integration tenant itself.

3) Maturity Map#

4) Requirements Checklist#

One sub-table per design domain. Every row must be decidable at requirements stage — implementation detail comes later.

Adapters and connectivity#

Persistence and reliability#

Security and credentials#

Operations and transport#

5) Decision Criteria#

The three questions to ask first#

Q1. Is there a measurable, recurring volume of message-based integration work between distinct systems that current point-to-point or batch jobs can’t keep up with?

If the answer is “we have two interfaces, one runs nightly, both work” — Cloud Integration is overkill. Cloud Integration earns its license cost when there are at least a handful of interfaces, ongoing change, and operational SLAs that exceed what cron-job batch processing can deliver.

Q2. Where does the data live, and is it allowed to traverse a public-cloud iPaaS?

Data residency drives Cloud Foundry region choice — and, if regulatory rules forbid cloud transit at all, it pushes the runtime to Edge Integration Cell. EIC is not a cheaper CPI; it is a different operational model where the customer owns the Kubernetes platform.

Q3. Who owns the integration interface in the org chart, and do they have the budget to fund both build and runtime?

Cloud Integration runtime cost is dominated by message volume in 250 KB increments per outbound message. Without a budget owner who tracks year-two volume, projects under-size and re-negotiate mid-fiscal-year.

Domain selection by project context#

Licensing and cost#

The single most-missed billing rule: outbound messages are counted, per 250 KB, with splitter outputs and retries each charged. Standard, unmodified SAP Integration Content (SAP-to-SAP) and the internal ProcessDirect and JMS adapters are exceptions — but ProcessDirect extensions of standard content are not (per the message traffic licensing analysis at integration-excellence.com).

6) Common Failures#

Failure 1: Sized for go-live, not year-two

The first 60 days after go-live are not representative. New interfaces get added, splitter-heavy iFlows multiply outbound message counts, and retry storms during incident periods consume the included message bucket. Capture year-two projected volume in the requirements phase and budget for it explicitly.

Failure 2: ProcessDirect billing exception inverted

The internal ProcessDirect adapter is not billed — except when it calls a customer extension of standard SAP Integration Content. Teams reading the rule too quickly assume “all ProcessDirect is free” and discover the bill after extending shipped iFlows. Read the licensing terms before extending standard content.

Failure 3: No idempotency designed in

Cloud Integration’s default delivery is at-least-once. Without an Idempotent Process Call (or target-side dedup), duplicates land in the receiver during retry storms — and the duplicate creates a downstream incident weeks later, far from the original cause. Idempotency is a requirements-stage decision, not a fix.

Failure 4: JMS retry and Data Store retry mixed in the same flow

JMS does retry natively via SAPJMSRetries. Data Store retry is explicit, controlled by the designer via SAP_DataStoreRetries. Mixing them in one iFlow — typically because two team members designed parts of it — produces flows that retry twice, lose messages, or block on poison pills. Pick one persistence-and-retry model per interface and document it.

Failure 5: Cloud Connector dependency overlooked

On-premise S/4HANA via RFC/IDoc requires SAP Cloud Connector. Architecture diagrams that draw a line directly from CPI to on-prem ECC produce go-live cutover delays as the customer scrambles to install Cloud Connector with the right NetWeaver patch level. Treat Cloud Connector as a separate dependency, not an implementation detail.

Failure 6: Naming convention chosen after deployment

Without a naming standard from day one, monitoring filters break, transport packages mix unrelated artifacts, and the runbook lists 200 iFlows by random names. SAP publishes a Naming Conventions page; pick a scheme on day one and enforce it via package-level review. Retrofitting names across a live system is genuinely painful.

FAQ#

Q: Does Cloud Integration replace SAP PI/PO?

For new projects, yes — SAP positions Cloud Integration as the forward platform, and even publishes a Migration Assessment capability for moving SAP Process Orchestration 7.5 content into Integration Suite. For existing PI/PO landscapes, the replacement is a project, not a switch: adapters, mapping styles, and operational habits differ enough that “lift and shift” is rarely accurate.

Q: When should I use Edge Integration Cell instead of standard Cloud Foundry deployment?

When data residency, compliance, or latency requirements forbid the data leaving the customer’s network. EIC is the on-prem / private-cloud runtime and runs the same iFlow artifacts; design and monitoring still happen in the BTP cloud tenant. EIC requires customer-owned enterprise-grade Kubernetes (SUSE Rancher, OpenShift, AKS, EKS, GKE per the SAP Architecture Center reference), so its operational model is fundamentally different from cloud-only CPI.

Q: How are messages billed exactly?

Per outbound message, in 250 KB increments. A 100 KB message = 1 charge. A 2 MB message = 9 charges. A splitter producing 50 outputs = 50 charges. Retries count each time. Standard SAP-to-SAP content and internal ProcessDirect / JMS adapter calls are exceptions; ProcessDirect extensions of standard content are not exceptions.

Q: How do I choose between JMS, Data Store, and Variables?

JMS for asynchronous queue-based interfaces with native retry — use when you need backpressure and the platform itself should retry. Data Store for explicit lifecycle: scheduled consumers, manual reprocessing UIs, batch handoffs. Variables for small per-tenant state only — last successful timestamp, last successful primary key — never for payload bodies. The official SAP Help decision page is the canonical reference.

Q: When should I descope Cloud Integration from a project?

When the integration footprint is one or two interfaces and there is no roadmap to grow it. The fixed cost of a Cloud Integration tenant — Subscription baseline plus three environments (DEV/QAS/PROD), all of which are billed — is hard to justify for a single nightly OData call. In that case, a direct Communication Arrangement or a small custom service is more honest.

Q: How do I document an interface requirement properly so an integration developer can build it?

For each interface, capture: source system + endpoint, target system + endpoint, action verb (create/update/delete/replicate), business object (sales order, business partner, etc.), trigger (schedule / event / synchronous call), expected volume per day and per peak hour, average and 95th-percentile payload size, delivery semantics (fire-and-forget / at-least-once / exactly-once), and idempotency rule on the target. That is enough to estimate message billing, persistence choice, and adapter selection.

Q: Are non-production tenants free?

No. All tenants — DEV, QAS, PROD — are billed for messages independently. Some teams forget this and discover that load tests against QAS consumed half of their monthly message bucket. Plan test data volume accordingly.

Q: How do I move iFlows between tenants?

Use SAP Cloud Transport Management Service (CTMS), with the Content Agent Service as the bridge. CTMS supports package-level and individual artifact-level transport. Set it up before the first promotion; doing it after artifacts are scattered across tenants is painful and risks lost configuration.

Summary#

Cloud Integration is mature, well-documented, and will not surprise you architecturally — Apache Camel on a multi-tenant runtime, with seventy-plus adapters and three persistence models per the Feature Scope Description — but it will surprise you commercially if you treat year-two volume as an afterthought. The consultant’s job is to ask the three questions before drawing the first iFlow, pick one persistence-and-retry pattern per interface, decide whether the workload belongs on standard Cloud Foundry or on Edge Integration Cell, and capture a naming convention before any artifact is deployed. Everything else — adapters, mappings, OAuth flows — is implementation detail that the integration developer can handle if those four decisions are clean.

What to Read Next#