SAP CPI

CPI executes integration flows (iFlows) that receive, transform, enrich and route messages between systems over many protocols and pre-built connectors, especially for cloud and hybrid scenarios (e.g. SuccessFactors, Ariba, S/4HANA Cloud). SAP provides many pre-packaged integration content packages.

• Integration flows (iFlows): the cloud integration logic.
• Adapters/connectors for SAP and non-SAP endpoints.
• Pre-packaged content for common integrations.
• Cloud-based monitoring.

An iFlow reads left to right: a sender adapter, a sequence of steps, a receiver adapter. What varies is the middle.

Mapping converts one structure to another, and message mapping is where most of the build effort goes. Content modifiers set headers and properties, which is how values are carried between steps. Routers send a message down a branch depending on its content. Splitters break a collection into individual messages and gathers put them back. Request reply calls another system mid-flow to fetch data the message needs. Groovy scripts do what the graphical steps cannot.

Two concepts underpin all of it. The message carries a body, headers and properties, and knowing which of the three a value is in explains most mapping confusion. Exchange properties survive across steps where headers may not, which is why a value disappears halfway down a flow somebody else built.

Everything is in the browser. Design holds integration packages, each grouping iFlows, message mappings, value mappings and scripts for one scenario. Monitor shows what is deployed and what messages did. Settings holds security material, the credentials and keys the adapters use.

The unit of deployment is the artefact, so redeploying one iFlow does not disturb the others in its package. Promotion between tenants is by exporting and importing the package, and keeping the package under version control is the discipline that replaces the transport queue.

Prepackaged content on the API Business Hub covers many standard scenarios. Copying it into your workspace and adapting it is normal, and it is usually a better starting point than a blank canvas. See API Management for the layer that fronts APIs rather than moving messages.

Twenty minutes in a trial tenant, and it is the daily work.

1. Open Monitor and find a recent message. Note its status and the artefact that processed it.
2. Open the message processing log and read the steps in order. Each shows what it did and how long it took.
3. Find a failed one. Read where it stopped: at the sender adapter is connectivity, at a mapping is data, at the receiver adapter is the far end rejecting it.
4. If tracing is on, read the payload before and after the mapping step. The field that went wrong is visible.
5. Fix the artefact, redeploy, and reprocess if the scenario supports it.

Use CPI/Integration Suite for new, cloud-oriented and hybrid integrations, and when connecting SAP cloud products. It is the strategic direction, so it is a high-value integration skill.

The honest counterweight: a high volume SAP to SAP document flow that already works over IDoc is not automatically improved by moving it here, and a stable PI or PO landscape does not need replacing on principle. See SAP PI and PO.

• Graphical mapping or script. Graphical is readable by the next person and covered by the platform. Every Groovy script is code you own and retest each release.
• One flow or several. Small flows are easier to monitor and redeploy. One flow doing everything is quicker to build and harder to live with.
• Where errors go. A failed message needs a destination a person will look at, whether that is an alert, a queue or a ticket.
• Synchronous or asynchronous. Putting a queue in the middle protects both ends from each other's downtime, at the cost of an immediate answer.

The adapter is where a flow meets the outside world, and choosing it is usually decided by the partner rather than by preference.

HTTPS and SOAP for synchronous calls in and out. OData for SAP cloud products and anything exposing an OData service, and it is the one that most often carries standard content. IDoc for talking to an ERP system in its own document format, which is common in hybrid landscapes where the core has not changed. SFTP for files, still the answer for banks and for many established partners. JMS for queueing inside the tenant, which is how you decouple a fast sender from a slow receiver. JDBC for direct database access, which works and should be a last resort.

Two properties decide most designs. Synchronous or asynchronous: whether the sender waits. And whether the adapter guarantees delivery, because an HTTP call that fails is gone unless something retries it, while a message on a queue is still there.

The pattern worth knowing is putting a queue between two halves of a scenario. The first flow receives and parks the message, the second processes it. If the receiving system is down, messages accumulate rather than fail, and the sender never knows. That single decision prevents a large class of incident, and it costs one extra artefact.

Authentication is configured on the adapter and the credentials belong in the security material store, not in the flow. See REST integration for the synchronous case in more detail.

Testing an integration is different from testing a program, because there are two systems and neither is fully under your control.

Start with the payload. Get a real message from the sender rather than one you composed, because the difference between the specification and what a system actually emits is where most defects live.

Simulate before deploying. The mapping can be tested against a payload without a live sender, which catches structural problems early and cheaply.

Then the unhappy paths. A missing mandatory field, an unexpected character set, a field longer than the target allows, a receiver that returns an error. Each should produce a diagnosable failure rather than a silent one.

Then volume. A flow that works on one message may behave differently on a thousand, particularly where a splitter or a request reply step is involved.

Finally, test what happens on a retry. Sending the same message twice should not create two orders, and finding that out in production is the expensive way.

• Wrong tool for the integration style.
• Ignoring monitoring/error handling.
• Point-to-point instead of governed integration.

• Tracing left on in production. It stores payloads, and those payloads often contain personal data.
• Credentials in the flow rather than the security store. They belong in one place per tenant so a package can be promoted without carrying a secret.
• No retry policy. Whether resending is safe is a design decision, and deciding it after a duplicate reaches a customer is too late. See SFTP integration for the file-based case where this bites hardest.

Reading a failed message is the start, and building the flow with its mapping, error handling and monitoring is the part you do in the course.

The working habit is to read the message processing log before changing anything. It shows which step the message reached, which separates a mapping problem from a connectivity problem in about ten seconds, and it saves the reflex of redeploying to see what happens.