SAP Integration Options: IDoc, BAPI, OData or CPI

Most SAP integration decisions come down to one question that is rarely asked out loud: will this interface still work after the next upgrade?

SAP offers several ways in and out. Some are decades old and still the right answer for certain jobs. Some are newer and preferred for S/4HANA. Choosing among the SAP integration options is less about which is most modern and more about which fits the data, the volume, the direction of flow and the system’s future.

This guide compares the main options, explains when each is the right choice, and sets out the questions that should decide it.

SAP capabilities vary by release, deployment model and license. Confirm specifics against the client’s landscape.

The options at a glance

Interface	Best for	Direction	Watch out for
IDoc and ALE	Document-level business messages – orders, deliveries, invoices, master data – exchanged asynchronously	Both	Silent failures if IDoc status monitoring is not set up and owned
BAPI and RFC	Synchronous transactional calls into ECC or S/4HANA where no newer interface exists	Mostly inbound to SAP	Tight coupling to SAP’s internal behavior; callers should be insulated from it
OData through SAP Gateway	Exposing SAP data and operations to applications in a clean, RESTful way, especially on S/4HANA	Both	Exposing more than consumers need; performance on large datasets
Integration Suite (CPI)	Orchestration, mapping and connectivity where the client has already licensed it	Both	Using it for everything because it is there, including work better done elsewhere
File-based batch	Large periodic extracts where timing is not critical	Both	Becoming permanent when it should have been replaced

IDoc and ALE: still the right answer for business documents

IDocs are SAP’s long-standing format for exchanging business documents. They are asynchronous, structured, and well understood by SAP teams. For sending purchase orders to suppliers, receiving invoices, or distributing master data, they remain a sound choice.

The common problem is not the IDoc itself but what happens when one fails. An IDoc stuck in an error status can sit unnoticed for days unless someone owns the monitoring. Any IDoc-based interface needs alerting on failed statuses, a defined reprocessing procedure, and reconciliation of what was sent against what was received.

BAPI and RFC: transactional calls, wrapped

BAPIs are SAP’s business APIs, called over RFC. They let an external system create or change a business object – a sales order, a goods movement – with SAP’s own validation applied.

They work, and on older ECC systems they are often the only option for some operations. The risk is coupling: an external application that calls BAPIs directly is tied to SAP’s internal structures and behavior. The better pattern is to wrap BAPI calls behind your own service, so callers see a stable contract and only the wrapper changes when SAP does.

OData: the modern surface

On S/4HANA, OData services exposed through SAP Gateway are the standard way to give applications access to SAP data and operations. They are RESTful, work naturally with web and mobile applications, and can be scoped to exactly what a consumer needs.

That last point matters. A common request is exposing SAP data to a customer-facing application – order status, invoices, availability – without granting that application access to SAP itself. A well-designed OData service, or an API layer in front of it, exposes only what the application needs and nothing it should never see.

Integration Suite: use it for what it is good at

SAP Integration Suite (formerly Cloud Platform Integration) provides managed integration flows, prebuilt content for common SAP scenarios, and connectivity to cloud and on-premises systems. Where the client has already bought it, it is often the right home for SAP-centric flows.

It is not automatically the right home for everything. Complex non-SAP orchestration, high-volume event streaming, or logic that belongs to another system may be better placed in the client’s existing middleware or a purpose-built service. The test is maintainability: who will understand and change this flow in three years?

How to choose

Five questions usually settle it:

Is the flow a business document, a transaction, or a query? Documents suit IDocs, transactions suit wrapped BAPIs or OData, and queries suit OData.
Does it need to be synchronous? If the caller must wait for SAP’s answer, rule out asynchronous patterns. If it does not, prefer them.
What will exist after the next upgrade? On an S/4HANA journey, favor released, supported interfaces over custom function modules or direct table access.
What does the client already run and support? A technically better interface the client cannot operate is a worse choice.
How will failure be noticed? Every option needs monitoring, alerting and reconciliation. Choose the one the client’s team can actually watch.

Batch to events during an S/4HANA program

Many organizations use an S/4HANA program to move from nightly file transfers to event-driven integration. That is a good instinct, but it is easier to do in stages than all at once:

Keep the batch interface running while the event-driven replacement runs in parallel.
Reconcile the two until the results agree for several cycles.
Retire the batch interface only when downstream consumers have moved.

Trying to change the ERP and every interface around it in the same cutover concentrates risk at exactly the wrong moment.

Illustrative scenario: exposing SAP to a customer portal

This scenario is a composite. It is representative of the SAP integration work we do, but it does not describe a specific client, and nothing in it is a reported result.

A manufacturer is midway through an S/4HANA program run by a system integrator. The business wants a customer portal that shows order status, deliveries and invoices. The first proposal is for the portal to call BAPIs directly.

Instead, the integration layer exposes a small set of versioned APIs – orders, deliveries, invoices – backed by OData services on S/4HANA and, for one legacy plant still on ECC, a wrapped BAPI. The portal never connects to SAP. Each customer sees only their own records, enforced in the API layer. Outbound delivery notifications move from a nightly file to events, running in parallel with the file until the two reconcile.

What a good outcome looks like: the portal launches without SAP access of its own, the ECC plant’s later migration changes the API’s back end but not its contract, and the system integrator never has to staff a middleware team for one project.

Working with eProxim

eProxim does not run an SAP practice. We work alongside system integrators and SAP partners, and build the layer between SAP and everything it has to agree with: OData services and API layers, monitored IDoc interfaces, wrapped BAPI and RFC calls, Integration Suite flows where the client has it, and the move from batch to events.

Bring us the SAP integration work you would rather not hire for. See our SAP partner page, or start a partner conversation.

SAP Integration Options: IDoc, BAPI, OData or Integration Suite?