S/4HANA Public Cloud integration: options and architecture

What makes S/4HANA Public Cloud integration different?

SAP S/4HANA Cloud Public Edition is a clean-core system. You do not modify it, and you do not reach into its database or call arbitrary function modules. Instead, you integrate only through the interfaces SAP has released for external use. This constraint is the whole point: by integrating through stable, versioned, released APIs and events, your integrations survive quarterly upgrades rather than breaking on them.

If you are coming from on-premise habits, this is the biggest mental shift. The good news is that the released surface is large and well documented, and SAP Integration Suite is designed to sit in front of it. For the platform context, see the SAP Integration Suite complete guide.

What does clean core actually mean for integration?

Quick answer: clean core means all integration and extension happens through released interfaces and events, keeping the digital core standard and upgrade-safe.

Clean core is not only about not modifying ABAP. For integration it means three habits: consume released APIs rather than building bespoke extractors; react to business events rather than polling tables; and put custom logic in side-by-side extensions on SAP BTP that talk to S/4HANA through the same released interfaces. The payoff is that upgrades stop being integration risk events.

Where do I find the integration points?

Released APIs are published in the SAP Business Accelerator Hub. For a given business object you check what is available, in which protocol, and in which version. The two main protocols are:

OData is the recommended default for most request-response scenarios because it is REST-based and supports modern query operations. SOAP remains fully supported and is the right choice when the interface is provided that way or when the process is inherently asynchronous.

How do I activate an interface?

Finding an API is not the same as being able to call it. In Public Cloud you activate interfaces through communication arrangements, which build on two other objects:

• A communication system represents the external partner you integrate with, including its host and identity.
• A communication user holds the credentials, using OAuth, certificates or basic authentication.
• A communication arrangement activates a communication scenario and ties the system and user to the specific inbound or outbound services.

Outbound arrangements let S/4HANA call out; inbound arrangements let other systems call in. Treat communication arrangements as part of your integration design and your security boundary, so a change to one is a security-relevant change that belongs under change control.

When should I use events instead of APIs?

Quick answer: use events when many systems must react to the same business moment and you want loose coupling; use APIs when a caller needs an immediate answer.

APIs are pull: a caller asks for data or submits a change and waits. Events are push: S/4HANA emits a business event when something happens, and interested systems subscribe. Events are the better fit when many consumers react to the same business moment, for example notifying inventory, finance and a partner portal that a sales order was created. S/4HANA business events flow through SAP Integration Suite's eventing capabilities. The architecture and trade-offs are covered in event-driven integration with SAP Event Mesh.

Where does SAP Integration Suite fit?

You can call S/4HANA APIs directly from another system, but you usually should not. Putting SAP Integration Suite in the middle gives you:

• Mediation: map between the S/4HANA data model and whatever the other system expects.
• Routing: send to different targets based on content.
• Security and governance: manage credentials centrally, apply API policies, and keep a single audit trail. The governance detail is in SAP API Management: governance, security and monitoring.
• Resilience: add retry and error handling so a brief outage in one system does not break the business process.

How does extension relate to integration?

In a clean-core world, custom logic lives outside the digital core, typically as side-by-side extensions on SAP BTP that talk to S/4HANA through the same released APIs and events. This keeps the core clean and makes your extensions and integrations follow the same rules. The boundary between extension and integration blurs, which is exactly why a single platform approach helps: the same connectivity, security and monitoring serve both.

What are the common pitfalls?

• Assuming an on-premise interface exists in Public Cloud. If it is not released, it is not available, and you must find the released equivalent.
• Calling S/4HANA directly from many consumers, duplicating credentials and losing central governance.
• Polling instead of subscribing where an event exists, which adds load and latency.
• Treating communication arrangements casually, when they are a security boundary.
• Ignoring API versions, then being surprised when a V2 service behaves differently from V4.

What about moving from on-premise or PI/PO?

Many teams reach Public Cloud integration while also retiring older middleware. If you still run SAP Process Orchestration, plan the move to Integration Suite in the same programme, because the target patterns are the same released APIs, communication arrangements and events. The step-by-step is in SAP PI/PO to Integration Suite migration, and the gated guides on governing integration change on S/4HANA and API management on S/4HANA and BTP go deeper.

What are the main integration scenarios?

In practice, S/4HANA Public Cloud integration falls into a few recurring shapes:

• Master data distribution: keeping business partners, materials and cost centres aligned across systems, increasingly event-driven.
• Transactional integration: creating or reading documents such as sales orders, purchase orders and invoices through OData or SOAP services.
• Analytics and extraction: feeding downstream reporting and data platforms through released extraction APIs rather than table reads.
• Process integration with non-SAP systems: connecting CRM, logistics, banks or partner portals to S/4HANA processes.

Each maps naturally onto the API, event and messaging styles described in the complete guide. The skill is choosing the right style per scenario rather than forcing everything through synchronous APIs.

How do I secure S/4HANA integration?

Quick answer: authenticate with OAuth or certificates, scope communication users tightly, and govern communication arrangements as security objects.

Security in Public Cloud integration rests on three things. First, strong authentication: prefer OAuth or certificate-based authentication over basic credentials for communication users. Second, least privilege: a communication user should be scoped to only the scenarios it needs, not granted broad access. Third, treat communication arrangements as part of the security perimeter, so a change that exposes a new service or relaxes authentication goes through proper review. Putting API Management in front adds a central place to apply threat protection, rate limiting and token verification.

How do I test S/4HANA integrations safely?

Test in a non-production S/4HANA environment with synthetic or masked data, never by moving real production data into test. Build a regression pack that covers the happy path and the error paths, and run it before every production change. Because Public Cloud receives regular upgrades, re-run your regression pack after each upgrade to catch any behavioural change early. This upgrade-safe testing discipline is one of the main benefits of integrating only through released, versioned interfaces.

What are the governance implications?

Because the integration surface is released APIs and events, governance becomes tractable: you can catalogue exactly which interfaces are active, which communication arrangements exist, and who owns each. Reconcile active communication arrangements against what has been approved, and retire ones that are no longer used. The gated guide on governing integration change on S/4HANA covers this operating model, and the API management on S/4HANA and BTP guide covers the API governance layer.

What are communication scenarios, systems, users and arrangements?

Quick answer: they are the four building blocks of every S/4HANA Public Cloud integration. A scenario defines what can be exchanged, a system describes the partner, a user authenticates inbound calls, and an arrangement binds them together and activates the interface.

Understanding this model removes most of the confusion teams experience early on. You do not "open an API" in Public Cloud; you create an arrangement for the scenario that contains it, with a specific partner system, and only then does the interface become callable.

Step by step: how do I activate a standard API?

Quick answer: find the API and its communication scenario on SAP Business Accelerator Hub, create a communication system and user, create the communication arrangement, then test from Integration Suite.

1. Identify the API. On SAP Business Accelerator Hub, find the released API, for example the Business Partner API, and note its communication scenario. For business partner, customer and supplier integration this is SAP_COM_0008.
2. Create the communication user. In the Maintain Communication Users app, create the technical user for inbound calls, or plan certificate-based authentication instead.
3. Create the communication system. In the Communication Systems app, describe the partner, typically your Integration Suite tenant, and assign the inbound user and outbound authentication.
4. Create the arrangement. In the Communication Arrangements app, choose the scenario, select the system, review the service URLs, and save to activate.
5. Test from Integration Suite. Call the service from a test iFlow using credentials stored on the tenant, never in the flow itself.
6. Record it. Add the arrangement, owner and purpose to your integration inventory so it is governed, not forgotten.

How do I publish business events from S/4HANA Public Cloud?

Quick answer: set up the enterprise eventing communication arrangement, typically SAP_COM_0092, then activate the outbound topics you need in the Enterprise Event Enablement – Configure Channel Binding app.

Enterprise Event Enablement is the framework S/4HANA Public Cloud uses to exchange events with other platforms. Once the channel to your event broker is configured through the communication arrangement, you bind only the topics consumers actually need, such as business partner or sales order changes. Resist the temptation to activate everything "in case"; every active topic is something to monitor and govern. For broker choices and event design, see our event-driven integration guide.

What if there is no released API for my requirement?

Quick answer: check for an alternative released API or event first, then consider a custom CDS view exposed through a custom communication scenario, or a custom API built with ABAP Cloud on released objects. Do not reach for unreleased interfaces.

• Search again: many requirements are covered by a different released API, an event, or a newer API version.
• Key user extensibility: the Custom CDS Views and Custom Communication Scenarios apps let you expose read-oriented data through a governed, clean-core interface.
• Developer extensibility: with ABAP Cloud you can build a custom service on released objects when the requirement includes logic or writes.
• Influence SAP: if the gap is generic, raise it through SAP's customer influence channels so it can become a standard API.

How do release upgrades affect my integrations?

Quick answer: Public Cloud is upgraded by SAP on a fixed schedule, so integrations must be built on released APIs, regression-tested against each upcoming release, and monitored closely after every upgrade.

Released APIs come with a stability contract, and SAP signals deprecations in advance rather than removing interfaces without notice. That protection only applies if you used released interfaces in the first place, which is why clean core matters so much for integration. Plan a regression run for critical interfaces in your test tenant ahead of each major release, watch deprecation notes for APIs you depend on, and schedule a heightened-monitoring window in the days after production is upgraded. The gated guide on governing integration change for S/4HANA turns this into a repeatable calendar.

Which authentication should I use?

Quick answer: prefer OAuth 2.0 or certificate-based authentication for production; keep basic authentication for limited, well-controlled cases and plan to replace it.

Whatever you choose, store credentials on the Integration Suite tenant as security material, rotate them on a schedule, and alert well before certificates expire. Expired certificates are one of the most avoidable causes of integration outages.

A reference architecture in one paragraph

Expose S/4HANA through released OData and SOAP APIs and business events, activated with communication arrangements. Put SAP Integration Suite in front for mediation, routing, security and monitoring. Use APIs for request-response, events for loose coupling, and messaging where reliable asynchronous delivery matters. Keep all custom logic in side-by-side extensions that use the same released interfaces. Govern every interface the same way, and you have an architecture that survives upgrades and scales across teams. Return to the complete guide for the platform-wide view.