Integration Suite: Use Cases and Decision Patterns

JinJin48

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

May 10, 2026 · 15 min read

Where This Article Sits#

References#

1) The Integration Landscape#

SAP Integration Suite covers a small number of recurring use case shapes. Whatever the customer’s words — “connect Salesforce”, “expose APIs to partners”, “real-time inventory”, “EDI for the new 3PL” — the underlying scenario almost always falls into one of the five rows below. Picking the right capability starts here, not at the price list.

They are not substitutes. Every real project has a primary category and usually one secondary category — naming both early is half the decision.

2) How It Connects to S/4HANA#

                     SAP Integration Suite (BTP)
   ┌──────────────────────────────────────────────────────────────┐
   │                                                              │
   │   A2A / Hybrid           API exposure          Event-driven  │
   │   ┌─────────────┐       ┌──────────────┐      ┌───────────┐  │
   │   │   Cloud     │──────▶│     API      │      │  Event    │  │
   │   │ Integration │       │  Management  │      │   Mesh    │  │
   │   └──────┬──────┘       └──────┬───────┘      └─────┬─────┘  │
   │          │                     │                    │        │
   │          │  Open Connectors    │                    │ AEM    │
   │          │  (non-SAP SaaS)     │                    │ (high  │
   │          │                     │                    │ volume)│
   │          │  TPM + Integration Advisor (B2B)         │        │
   │          │                                          │        │
   └──────────┼──────────────────────────────────────────┼────────┘
              │                                          │
              ▼  via Cloud Connector (on-prem)           ▼
        ┌──────────────┐                          ┌──────────────┐
        │  S/4HANA     │  ◀────  events  ────────▶│  S/4HANA     │
        │  on-premise  │                          │  Cloud       │
        └──────────────┘                          └──────────────┘
              ▲                                          ▲
              │                                          │
        ┌──────┴────────┐                          ┌─────┴────────┐
        │ Edge          │                          │ Non-SAP SaaS │
        │ Integration   │                          │ / IoT / B2B  │
        │ Cell (private)│                          │ partners     │
        └───────────────┘                          └──────────────┘

Read the diagram top-down: Integration Suite is the orchestration layer, S/4HANA (on-prem or Cloud) is the system of record, and the lower row is where the integration’s “other side” lives — partners, SaaS, IoT, or a private-network constrained sister system. The Edge Integration Cell sits below the BTP boundary because it runs in the customer’s network even though it is modeled and governed in BTP.

Key point: the choice of capability is decided by where the endpoints sit and how they want to talk — not by which capability the customer already provisioned.

3) Maturity Map#

4) Requirements Checklist#

Each table below covers one use case category. Items here are decidable at requirements stage — if any line cannot be answered, that gap is the project risk, not the implementation work that follows it.

A2A integration#

API exposure and management#

Event-driven integration#

B2B with external trading partners#

Hybrid / data-residency-bound#

5) Decision Criteria#

The three questions to ask first#

Q1. What is the measurable integration pain we are solving, in business terms?

If the answer is “we want an iPaaS” or “we already bought Integration Suite”, stop. Go back until the answer is shaped like “our SuccessFactors-to-S/4HANA payroll replication is failing 3% of records and it costs us four FTE-days per month to reconcile”, or “we cannot onboard our 12th 3PL because EDI mapping takes six weeks per partner”. Without a measurable pain, capability selection is arbitrary and the project will drift.

Q2. Where do the endpoints sit, and what data is crossing the boundary?

This is the ISA-M domain question. Cloud-to-cloud, on-prem-to-cloud, on-prem-to-on-prem, plus B2B / B2G overlays — each combination changes the answer. If the data is regulated (PII, health, financial), if it is bound by residency law, or if security policy prohibits inbound-from-cloud, the candidate set narrows fast — usually toward Edge Integration Cell.

Q3. Who owns the integration after go-live, and what is their operating budget?

A decision that delivers on day 30 and bankrupts the team on day 400 is a bad decision. Cloud Integration message-based billing grows as fast as adoption; API Management runs on a different commercial track; Advanced Event Mesh broker tiers are a separate negotiation. A capability without a named owner with budget authority is a future incident.

Domain selection by project context#

Licensing and cost#

6) Common Failures#

Failure 1: Cloud Integration as the universal hammer

Projects buy Cloud Integration first because it is the most-named capability, then use it for pure API exposure (where API Management is the right answer) and pure event publishing (where Event Mesh is the right answer). The result is iFlow sprawl that masquerades as integration code, with monitoring and lifecycle problems that surface at year two.

Failure 2: Year-one volume budgeting

Sizing the consumption budget against go-live message volume rather than steady-state adoption volume is the most common cost surprise in this space. Customers commonly hit consumption overruns 12–18 months post go-live, and top-up rates are typically less favorable than the original CPEA rate. Build the year-3 number into the year-1 contract.

Failure 3: Data residency ignored until UAT

Compliance and legal teams enter most projects in the test phase and routinely block go-live when data residency was not confirmed at requirements stage. This is the failure that triggers Edge Integration Cell retrofits — a multi-month replan that could have been a one-week conversation in week one.

Failure 4: Standalone middleware, dual-HA business systems

Two business-critical systems are run 24/7 with HA/DR while the integration tenant between them is a single instance. At failover, alignment fails and integrations stop. Integration Suite supports cross-region DR, but it is a separate decision — not a default.

Failure 5: Insufficient error logging in B2B-class flows

In B2B and B2G scenarios, error volume routinely exceeds success volume during partner onboarding and in seasonal load spikes. Generic logs (“processing failed”) make root cause analysis impossible and turn every partner ticket into a multi-hour engineering investigation. The error-handling contract belongs in the requirements document, not the implementation backlog.

Failure 6: Event Mesh chosen by name, AEM needed by shape

The two products share the words “Event Mesh” but are different commercial tracks and different infrastructure. Teams pick Standard Event Mesh because it is cheaper and bundled, then hit the 1 MB ceiling or the throughput practical limit at the worst possible moment. A 30-minute conversation about message size and event rate at requirements stage prevents a six-month product migration.

FAQ#

Q: We already use SAP PI/PO on-premise. Is Integration Suite the only path forward?

It is the SAP-published strategic path forward, supported by the Migration Assessment capability and the Edge Integration Cell deployment option for customers who cannot fully move to cloud-only. SAP Process Orchestration remains supported, but new investment is on the iPaaS side; clean core integration is one of SAP’s five clean core principles, and it points at Integration Suite. If your timeline is multi-year, plan the migration; if there is an immediate compliance constraint, EIC bridges the gap.

Q: When is Open Connectors the right choice over a Cloud Integration custom adapter?

When the target SaaS is on the supported connector list and the integration is mostly straight-through with light mapping. Open Connectors gives you the connection in days; Cloud Integration with a custom adapter is weeks of build and lifelong maintenance. The decision flips when the mapping is non-trivial — chain Cloud Integration after Open Connectors rather than building either alone.

Q: How do we know whether Standard Event Mesh is enough?

Three numbers decide it: maximum message size (must be < 1 MB), event rate (must comfortably fit ~250 KB/s practical per subaccount), and topology (must stay inside SAP BTP). If any of the three is uncertain, scope the next-volume tier or design for Advanced Event Mesh from the start. Mid-project product swaps in the event layer are expensive.

Q: When should we descope Trading Partner Management and stick with raw Cloud Integration B2B adapters?

When the trading partner population is small (typically ≤5 partners), document standards are minimal, and onboarding cadence is annual rather than quarterly. TPM’s value is its reusable artifacts (Company Profile, Trading Partner Profiles, agreements) and partner directory — at low volumes that overhead is not amortized. Above the threshold, TPM + Integration Advisor pays for itself in onboarding time saved.

Q: How do we document the integration requirement properly so the build team does not redesign it?

Three artifacts: (1) the use case category (one of the five from §1) with measurable pain, (2) the ISA-M classification (style + domain) with the chosen capability, and (3) the operating-model decision (owner, budget, monitoring stack, error workflow). All three live in the requirements document and survive into production. A diagram alone is not enough.

Q: Where does Cloud ALM fit in this picture?

SAP Cloud ALM and SAP Application Interface Framework are the recommended observability stack across Integration Suite. They are a separate decision from capability selection — every capability above can be operated without Cloud ALM, but at scale the central observability becomes load-bearing. Decide the monitoring stack alongside the capabilities, not after.

Summary#

Integration Suite is not five products you deploy in sequence — it is one platform with a small number of use case shapes and a methodology, ISA-M, that turns those shapes into defensible technology choices. The five shapes (A2A, API exposure, event-driven, B2B, hybrid) cover almost everything a real project does. The three questions (measurable pain, endpoint domain, owner with budget) decide which shape applies. The seven failures are all decision-stage failures, not implementation bugs. A consultant who can walk a customer through this frame in one workshop is worth the engagement; a project that skips the frame and starts in the implementation tool is the one that comes back for a redesign.

What to Read Next#