SAP Integration Suite: the complete guide

What is SAP Integration Suite?

SAP Integration Suite is SAP's integration platform as a service (iPaaS), delivered as a managed service on SAP Business Technology Platform (SAP BTP). In one sentence: it is the single, governed place where you connect SAP and non-SAP applications using three styles of integration, APIs, messaging and events. Around those styles it adds content and tooling, such as prebuilt integration packages, an integration advisor for business-to-business mappings, and trading-partner management.

The reason a single platform matters is governance. In most organisations, integration starts as a scatter of point-to-point connections built by different teams at different times, with no shared way to secure, monitor or change them. A platform replaces that sprawl with a common runtime, a common security model, and one place to see what is running. That is what turns a pile of interfaces into an integration capability you can trust.

What are the core capabilities?

The suite is a set of capabilities you provision on your BTP tenant. The ones most teams use day to day are:

• Cloud Integration (CPI): builds and runs integration flows (iFlows). This is where mappings, routing, content-based decisions, adapters and error handling live. It is the workhorse of the platform.
• API Management: publishes and governs APIs with policies for security, traffic management, threat protection and mediation, plus a developer portal and analytics. See SAP API Management: governance, security and monitoring.
• Event Mesh: a messaging capability for publishing and consuming business events across applications.
• Advanced Event Mesh: a more feature-rich, managed event-streaming service with event brokers, an event portal, hierarchical topics, guaranteed delivery and replay for distributed, real-time landscapes. See event-driven integration with SAP Event Mesh.
• Integration Advisor and trading-partner management: for business-to-business (B2B/EDI) scenarios, where industry message standards and partner-specific variants need to be managed at scale.

Which adapters and connectivity does it offer?

Quick answer: SAP documents more than 80 standard adapters out of the box, plus custom adapters and connectors.

Cloud Integration groups connectivity into standard adapters, custom adapters and connectors. The standard set covers technical protocols such as HTTP and HTTPS, SFTP and FTP, SOAP, OData and RFC, alongside application-specific adapters for SAP and non-SAP systems. When you need something bespoke, you can build or deploy a custom adapter. For reaching systems behind the firewall, outbound calls typically route through SAP Cloud Connector, which lets administrators control exactly which on-premise resources the cloud tenant can see. This is both a connectivity feature and a security control.

When should I use APIs, messaging or events?

Choosing the integration style is the first architecture decision, and it drives everything downstream. A simple rule of thumb:

Most real landscapes use all three. A well-designed estate picks the style per interface rather than forcing everything through one pattern. A common anti-pattern is to make everything synchronous because it is easiest to reason about, which then couples systems so tightly that one slow target stalls a whole business process.

How does it fit SAP BTP?

SAP Integration Suite runs on SAP BTP, so it inherits BTP's identity, connectivity and security services. Outbound calls to on-premise systems go through SAP Cloud Connector; identity is handled through BTP's identity services; and you choose the region where your tenant runs, which matters for data residency.

Because it is a managed service, SAP operates the runtime, patches it and keeps it available. Your responsibility is the content you deploy, the credentials and connectivity you configure, and the controls you put around production changes. This split is important: a managed platform does not make your integrations reliable on its own, it gives you a reliable place to run integrations you have designed well.

Is it replacing SAP Process Orchestration?

Yes. SAP Integration Suite is the strategic successor to SAP Process Orchestration (PI/PO). PI/PO follows the SAP NetWeaver maintenance timeline, so the direction of travel is clear even if your own deadline is a few years out. SAP provides Migration Assessment to analyse existing PI/PO scenarios and estimate effort, and Migration Tooling inside Cloud Integration to convert supported objects.

The mistake to avoid is treating migration as a lift and shift. It is the single best moment to apply modern patterns, because you are touching every interface anyway. For a practical walkthrough, read SAP PI/PO to Integration Suite migration: step by step.

How do I connect SAP S/4HANA?

Quick answer: through released APIs and events, activated with communication arrangements, with Integration Suite in front for mediation and governance.

SAP S/4HANA, especially the public cloud edition, exposes released APIs through the SAP Business Accelerator Hub, mostly as OData and SOAP services, and you activate them with communication arrangements. Integration Suite sits in front of these to add mediation, routing, security and monitoring. Because Public Cloud is a clean-core system, you integrate only through these released interfaces rather than modifying the core, which is what lets your integrations survive upgrades. The detail is in S/4HANA Public Cloud integration: options and architecture.

What makes integrations reliable?

The platform gives you the building blocks, but reliability is a design property. Four practices matter most:

1. Idempotency: design receivers and flows so that processing the same message twice does no harm. This is the prerequisite for safe retry.
2. Exception handling: every integration flow should decide what happens on error, using an exception subprocess rather than failing silently.
3. Retry: use the right mechanism for recoverable errors, which usually means JMS queues or a Data Store.
4. Monitoring and alerting: watch message status and act on failures. See how to monitor SAP Integration Suite.

The reliability pillar, SAP error handling in Integration Suite, ties these together into a single approach you can standardise across teams.

What are the common anti-patterns?

Teams that struggle usually share a few habits:

• No standard error handling: each iFlow invents its own, so operations cannot reason about failures.
• Synchronous everything: tight coupling turns a brief outage in one system into a business incident.
• Credentials and endpoints scattered in flows rather than managed centrally, which makes rotation and audit painful.
• No idempotency, so a retry creates duplicate orders or postings.
• Monitoring only platform uptime, missing the interface-level failures that are the real incidents.

Naming each of these explicitly in your standards is the cheapest reliability win available.

What about AI?

SAP is adding AI across the platform, from AI-assisted generation of integration flows in Cloud Integration to a Joule-based experience on the roadmap. Used well, AI speeds up design and helps triage errors, but the governance rules do not change: an AI-generated change to production is still a change to production. See SAP AI for integration.

How should a team operate it?

Start read-only and earn write access to production through approvals. Standardise three things across every integration: naming, error handling and alerting. Keep developer, approver and deployer roles separate, and reconcile what is deployed against what was approved so there are no undocumented changes. Promote the same artefact through environments rather than rebuilding per stage, and keep a regression pack you run before every production change.

Governance is what turns a collection of iFlows into a dependable integration platform. The gated playbooks on integration change control and the integration governance playbook go deeper into the operating model.

How does it compare to other iPaaS platforms?

Quick answer: SAP Integration Suite's differentiator is native, prebuilt SAP content and events, not just generic connectivity.

Every major iPaaS can move data between systems. What sets SAP Integration Suite apart for an SAP-centric landscape is depth with SAP: released APIs and business events for S/4HANA, prebuilt integration packages for SAP applications, and an integration advisor for B2B. Generic platforms can connect to SAP, but you rebuild much of that context yourself. The practical decision usually comes down to where your centre of gravity is. If most of your critical processes run through SAP, a platform that understands SAP natively reduces both build and maintenance effort. If SAP is a minor part of a mostly non-SAP estate, a neutral iPaaS may fit better. Many large organisations run more than one integration platform and use SAP Integration Suite specifically for the SAP-connected flows.

How is it provisioned and consumed?

SAP Integration Suite is a managed BTP service. You provision a tenant, enable the capabilities you need (Cloud Integration, API Management, eventing), and configure identity, connectivity and destinations. Outbound access to on-premise systems is controlled through SAP Cloud Connector, and you choose the region for data residency. Because packaging and commercial models evolve, confirm the current entitlement and consumption model with SAP rather than relying on older figures. Treat provisioning as an architecture activity: the tenant layout, environment separation and identity design you choose early are hard to change later.

What does a sensible first 90 days look like?

A common failure mode is to start by building dozens of interfaces with no standards, then spend years cleaning up. A better sequence:

1. Weeks 1-3: set up environments, identity and connectivity; agree naming, error-handling and alerting standards; stand up a reusable exception-subprocess template.
2. Weeks 4-8: migrate or build a handful of low-risk interfaces to prove the patterns end to end, including retry and monitoring.
3. Weeks 9-12: introduce change control, a regression pack, and dashboards; only then scale to higher-value interfaces.

The order matters: standards first, volume second. Teams that invert this accumulate integration debt, the subject of the gated guide on the cost of integration debt.

Who owns integration, and how is it governed?

Integration sits between teams, which is exactly why it needs clear ownership. Separate the roles of developer, approver and deployer so no single person can push an unreviewed change to production, and reconcile what is deployed against what was approved. Keep a catalogue of interfaces with their owners, the business processes they serve, and their error-handling and alerting status. This is the operating model described in the gated integration governance guide and the integration change control guide. Governance is not bureaucracy for its own sake; it is what lets you change a live estate safely.

What is the difference between Cloud Integration and API Management?

Quick answer: Cloud Integration moves and transforms data between systems; API Management governs how consumers access APIs. Most landscapes need both, and they are designed to sit together.

A common, healthy pattern is an iFlow doing the heavy lifting behind an API proxy that handles authentication and traffic policy. Our API Management governance and security guide covers the proxy side in depth.

How do I structure packages, naming and transports?

Quick answer: group integration packages by business domain, agree a naming convention before the first iFlow ships, externalise every environment-specific parameter, and move content between tenants with a transport mechanism rather than manual copies.

Integration Suite supports transporting content through SAP Cloud Transport Management, through CTS+, or by manual export and import. Pick one route and use it consistently, because a mix of transported and hand-edited content is how environments drift apart. A good naming convention encodes domain, source, target and direction, so that anyone reading the monitor at 2 a.m. can tell what a failing flow does without opening it. Externalised parameters for URLs, credentials aliases and schedules mean the same artefact runs unchanged in development, test and production, which is the foundation of disciplined integration change control.

When should I not use Integration Suite?

Quick answer: do not force it into jobs other SAP tools do better: bulk data replication for analytics, end-user workflow automation, and logic that belongs inside the application itself.

• Large-scale data replication for analytics: data-replication and data-platform tools are usually a better fit than message-by-message integration.
• Human workflow and approvals: SAP Build Process Automation is designed for this; Integration Suite can call it, but should not imitate it.
• Business logic inside S/4HANA: extend in-app or side-by-side with ABAP Cloud or BTP, then integrate the result. See the S/4HANA Public Cloud integration pillar.
• A single, stable point-to-point link with a supported native connector: it can be pragmatic to use that connector, as long as it is still monitored and documented.

A short scenario: onboarding a new SaaS application

Quick answer: classify the interfaces, choose API, message or event per interface, reuse a standard error-handling and monitoring template, and go live under change control.

Imagine finance adopts a new expense SaaS that needs employee master data and must post approved expenses to S/4HANA. Employee data is a scheduled, asynchronous sync, so it becomes an iFlow with JMS-backed retry. Expense posting is near real time and must be reliable, so it calls a released S/4HANA API through an iFlow with idempotency keyed on the expense ID. The SaaS vendor's webhook is fronted by an API proxy for authentication and spike arrest. Every flow inherits the team's exception subprocess template, every critical failure routes to an owned alert, and the whole package is transported, not rebuilt, into production. None of this is exotic; it is simply the standards in this guide applied consistently.

Where to go next

This guide is the hub for the Spanovix resources on SAP integration. From here, follow the reliability track (error handling, exception subprocess, retry, monitoring) or the scenario track (S/4HANA, API Management, events, migration, AI). Each article links back here and across the cluster so you can navigate by the question you actually have.