BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
SAP BAPI
Business Application Programming Interface
A Comprehensive Technical Guide
From ECC to S/4HANA to the Cloud Era
1. Introduction to BAPIs
A BAPI (Business Application Programming Interface) is a standardized programming interface that
provides external access to business processes and data in SAP systems. BAPIs are implemented
as RFC-enabled function modules and are a core part of the SAP Business Object Repository
(BOR). They allow external applications, third-party systems, and custom developments to interact
with SAP in a controlled, stable, and officially supported way.
BAPIs are central to SAP integration architecture. They abstract the complexity of internal SAP
tables and logic, presenting clean, well-documented interfaces that developers can rely on without
deep knowledge of SAP's internal data model.
2. Technical Architecture of BAPIs
2.1 Core Components
• Business Object Repository (BOR): The BOR is SAP's central catalog of business objects
(e.g., SalesOrder, Customer, Material). Each business object exposes its functionality via
BAPIs.
• RFC-Enabled Function Modules: BAPIs are technically implemented as Remote Function
Call (RFC) function modules, allowing them to be called from external systems over a
network connection.
• ABAP Dictionary Structures: BAPIs use flat ABAP Dictionary structures as parameters —
not internal tables or complex nested objects — to ensure compatibility with external
languages.
• Return Parameter: Every BAPI includes a RETURN parameter (typically a table of
BAPIRET2 structures) that carries messages, warnings, and error codes back to the caller.
2.2 BAPI Categories
Page 1 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
Category Description Examples
Read BAPIs Retrieve data from SAP BAPI_SALESORDER_GETLIST,
without making changes BAPI_CUSTOMER_GETDETAIL
Create BAPIs Create new business objects BAPI_SALESORDER_CREATEFROMDAT2,
or transactions BAPI_PO_CREATE1
Change BAPIs Update existing business BAPI_SALESORDER_CHANGE,
objects BAPI_CUSTOMER_CHANGE
Check BAPIs Validate data without posting BAPI_SALESORDER_SIMULATE
Status BAPIs Update or query the status of BAPI_GOODSMVT_CREATE (GI/GR)
an object
2.3 Commit Handling
A critical architectural rule: BAPIs do not automatically commit database changes. After calling a
create or change BAPI, the developer must explicitly call BAPI_TRANSACTION_COMMIT (or
BAPI_TRANSACTION_ROLLBACK on error). This gives the calling program full control over
transaction boundaries and allows multiple BAPIs to be grouped in a single logical unit of work
(LUW).
Page 2 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
3. BAPIs in SAP ECC Days
SAP ERP Central Component (ECC) — spanning versions from R/3 to ECC 6.0 — represented the
era where BAPIs became the de facto standard for enterprise integration. During this period, BAPIs
were the primary mechanism for connecting third-party systems, middleware platforms (like SAP
PI/XI), and custom ABAP or non-ABAP programs to core SAP processes.
3.1 Role and Importance in ECC
• BAPIs replaced the older, less structured Direct Table Access (DTA) approach, which was
fragile and unsupported.
• They enabled Middleware Integration through SAP Business Connector, SAP PI/XI (Process
Integration), and third-party platforms like TIBCO, WebMethods, and IBM MQ.
• BAPIs were the backbone of SAP's B2B scenarios — connecting suppliers, customers, and
logistics providers through EDI and IDoc-to-BAPI bridges.
• Custom ABAP programs called BAPIs to encapsulate business logic, reducing direct table
manipulation and improving upgrade stability.
• SAP shipped hundreds of standard BAPIs covering FI, CO, MM, SD, PP, HR, and all major
modules.
3.2 Common ECC Integration Patterns
Pattern Technology Used BAPI Role
Middleware SAP PI/XI, IBM WebSphere Called via RFC adapter as integration
Integration endpoint
Legacy System SAP Business Connector Exposed as web services over HTTP/SOAP
Connection
Batch Data Transfer LSMW, BDC with BAPI Replaced screen-based BDC programs
Custom ABAP User Exits, BAdIs Called inside custom programs for standard
Enhancements object creation
External Application JCo (Java Connector), NCo Called directly from Java or .NET business
Integration (.NET) apps
3.3 Calling BAPIs from External Systems in ECC
Using SAP Java Connector (JCo)
The SAP Java Connector (JCo) library allowed Java applications to call BAPIs and RFC function
modules directly. A typical flow involved establishing an RFC destination, creating a JCoFunction
object, populating input parameters, executing the call, and reading the RETURN table for status
messages.
Page 3 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
Using SAP .NET Connector (NCo)
Similar to JCo, the SAP .NET Connector (NCo) provided .NET applications with an object-oriented
API to invoke BAPIs using RfcDestination and IRfcFunction objects, enabling integration from
Microsoft-based enterprise applications.
3.4 Limitations of BAPIs in ECC
• BAPIs were synchronous by nature — long-running calls could block client processes.
• Error handling required careful inspection of the RETURN table; there was no native
exception mechanism in RFC.
• BAPIs did not support complex nested object structures, requiring workarounds with multiple
flat parameter tables.
• Real-time event-driven integration was limited; most integrations were polling-based or
batch-triggered.
• Versioning was informal — SAP added parameters but rarely versioned BAPIs formally,
leading to compatibility challenges across releases.
Page 4 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
4. BAPIs in SAP S/4HANA
SAP S/4HANA, launched in 2015 and continuously evolved, brought a radical simplification of the
data model (Universal Journal in FI, simplified material management tables, etc.) and introduced
the ABAP RESTful Application Programming Model (RAP) as the modern development paradigm.
BAPIs were not eliminated but their role was strategically repositioned.
4.1 Compatibility and Continued Support
SAP took a pragmatic approach to BAPIs in S/4HANA: the majority of classic BAPIs are still
available and functionally supported. SAP's official stance is that BAPIs are 'stable but not strategic'
— they will continue to work, but new development should prefer the modern APIs. This ensures
that customers migrating from ECC can retain their existing integrations without immediate re-
development.
• Most standard ECC BAPIs (SD, MM, FI, HR, etc.) remain available in S/4HANA.
• SAP has flagged certain BAPIs as deprecated where the underlying data model has
fundamentally changed (e.g., some classic CO BAPIs due to the Universal Journal).
• Existing RFC/BAPI-based integrations via SAP PI/PO, CPI, or direct RFC typically work
without modification post-migration.
4.2 The Rise of Modern Alternatives
S/4HANA introduced and promoted several modern integration approaches that address the
structural limitations of BAPIs:
Technology Type Key Advantage over BAPIs
OData Services (v2/v4) REST/HTTP API Stateless, web-native, supports JSON, no RFC
required
ABAP RESTful App ABAP Framework Behavior-driven, CDS-based, built-in OData
Model (RAP) exposure
SAP Business REST API Catalog Officially published, versioned, contract-based
Accelerator Hub APIs
IDoc (continued) Async Messaging Asynchronous, reliable delivery, event-driven
Events (SAP Event Event-Driven Decoupled, near-real-time, cloud-native pattern
Mesh)
4.3 When to Still Use BAPIs in S/4HANA
Despite the availability of modern alternatives, BAPIs remain the practical choice in several
S/4HANA scenarios:
Page 5 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
• Existing custom ABAP programs and legacy enhancements that already use BAPIs — no
benefit in rewriting stable code.
• Middleware integrations via SAP PI/PO where the integration flow is already certified and
tested.
• Complex transactional scenarios (e.g., multi-step order processing) where the BAPI's batch-
commit pattern is intentional.
• Situations where no equivalent OData service exists for a given business object or action.
• ABAP unit testing scenarios where BAPIs provide well-understood, stable interfaces for test
data setup.
4.4 Performance in S/4HANA
S/4HANA's in-memory HANA database significantly improves the performance profile of BAPI calls,
particularly for read-intensive BAPIs (GetList, GetDetail). The elimination of aggregation tables
(e.g., BSEG improvements, material ledger simplification) means that BAPIs that previously
triggered full table scans can now leverage HANA's columnar storage and in-memory processing
for dramatically faster responses.
Page 6 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
5. BAPIs in the Cloud Era
The move to SAP's cloud portfolio — SAP S/4HANA Cloud (Public and Private Edition), SAP BTP
(Business Technology Platform), SAP Integration Suite, and SuccessFactors — has fundamentally
changed how BAPI-style integration is architected. The cloud era is defined by API-first design,
statelessness, microservices, and event-driven architectures.
5.1 SAP S/4HANA Cloud Public Edition
In the Public Cloud (multi-tenant) edition of S/4HANA, direct RFC-based BAPI calls are not
available. The multi-tenant architecture prohibits direct system-level access. All integrations must
go through official, published APIs:
• SAP Business Accelerator Hub ([Link]) is the definitive catalog of all supported
integration APIs.
• OData v4 APIs are the primary integration mechanism for synchronous, request-response
integration.
• SOAP APIs are available for compatibility with older integration patterns.
• Eventing via SAP Event Mesh enables asynchronous, decoupled integration for scenarios
like order creation events or goods movement notifications.
The absence of direct BAPI calls in Public Cloud is by design — it enforces clean extensibility and
protects the upgrade path by preventing low-level system access.
5.2 SAP S/4HANA Cloud Private Edition
Private Edition (single-tenant, managed by SAP) offers greater flexibility. Direct RFC/BAPI access
is technically possible when connecting from SAP Integration Suite (CPI) or on-premise middleware
via SAP BTP Connectivity Service (Cloud Connector):
• Cloud Connector establishes a secure, reverse-proxy tunnel between SAP BTP and the on-
premise or private cloud S/4HANA system.
• Once connected, SAP Integration Suite iFlows can use the RFC adapter to call BAPIs just
as they would in a classic PI/PO scenario.
• This approach is common in hybrid landscapes where a Public Cloud tenant is not yet
feasible.
5.3 SAP BTP and Integration Suite
Integration Approach BAPI Access Recommended Use Case
SAP Integration Suite (CPI) Yes (via Cloud Hybrid scenarios, existing BAPI-based iFlows
— RFC Adapter Connector) migrated from PI/PO
SAP Integration Suite — No (uses OData Cloud-first, stateless, modern integrations
OData Adapter APIs)
Page 7 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
Integration Approach BAPI Access Recommended Use Case
SAP BTP ABAP Limited (own Custom ABAP extensions consuming released
Environment ABAP stack) APIs
SAP Event Mesh No (event-driven) Async, decoupled, event-triggered processes
Open Connectors No (REST- Third-party SaaS connectivity (Salesforce,
based) ServiceNow, etc.)
5.4 The BAPI Wrapper Pattern in Cloud Contexts
A common architectural pattern in hybrid cloud landscapes is the BAPI Wrapper Service: an on-
premise or Private Edition ABAP class or OData service that internally calls one or more BAPIs and
exposes the result as a clean REST/OData endpoint. This pattern:
• Allows existing BAPI-based business logic to be surfaced to cloud consumers without direct
RFC dependency.
• Enables gradual modernization — the BAPI call can be replaced with a RAP-based
implementation internally without changing the external API contract.
• Insulates cloud integrations from the RFC protocol, which is not natively supported in HTTP-
only cloud runtimes.
5.5 BAPIs vs. Modern Cloud APIs: A Comparison
Dimension Classic BAPI (RFC) Modern OData/REST API
Protocol SAP proprietary RFC HTTP/HTTPS (standard)
Data Format ABAP structures/tables JSON / XML (OData)
State Model Stateful (explicit COMMIT) Stateless (REST principle)
Firewall Friendliness Requires RFC port (33xx) Port 443 (HTTPS)
Versioning Informal / implicit Formal (v1, v2, v4)
Discovery SE37 / BOR (SAP-only) SAP BTP API Hub (public)
Error Handling RETURN table inspection HTTP status codes + OData errors
Cloud Native No (requires SAP tooling) Yes (any HTTP client)
Performance (Read) Fast (RFC binary) Slightly higher overhead (HTTP)
Async Support tRFC / qRFC (transactional) Events / Webhooks / Event Mesh
Page 8 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
6. BAPI Programming: Practical Guide
6.1 Finding BAPIs
• Transaction BAPI: The BAPI Explorer — browse by business object or search by keyword.
This is the primary tool for BAPI discovery.
• Transaction SE37: Function Module Browser — search for BAPIs by module prefix (e.g.,
BAPI_SD_*, BAPI_MM_*).
• SAP Help Portal: Official documentation with parameter descriptions and usage notes.
• SAP Business Accelerator Hub: For S/4HANA systems — lists both classic BAPIs and
modern OData APIs.
6.2 Standard BAPI Call Pattern (ABAP)
The following pattern represents the standard, recommended approach for calling a BAPI in ABAP:
DATA: ls_return TYPE BAPIRET2,
lt_return TYPE TABLE OF BAPIRET2.
CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
EXPORTING order_header_in = ls_header
TABLES order_items_in = lt_items
return = lt_return.
READ TABLE lt_return INTO ls_return
WITH KEY type = 'E'.
IF sy-subrc <> 0. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
6.3 Key BAPI Best Practices
• Always check the RETURN table: Never assume success. Check for TYPE = 'E' (Error) or
TYPE = 'A' (Abort) before committing.
• Explicit COMMIT / ROLLBACK: Always call BAPI_TRANSACTION_COMMIT on success
or BAPI_TRANSACTION_ROLLBACK on error.
• Test in SE37: Always test BAPIs in transaction SE37 with test data before calling
programmatically.
• Use test mode flags: Many BAPIs have a TEST_RUN or TESTRUN parameter — use it
during development to simulate without posting.
• Handle all message types: Process S (Success), W (Warning), E (Error), I (Information),
and A (Abort) messages appropriately.
• Document parameter mapping: BAPI parameters are often abbreviated — document what
each parameter maps to in the business context.
Page 9 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
7. BAPI Migration and Modernization Strategy
Organizations running ECC and planning or executing an S/4HANA or cloud migration must
develop a clear strategy for their BAPI-based integrations. A blanket replace-all approach is neither
practical nor necessary.
7.1 Assessment Framework
S/4HANA On-Prem /
BAPI Integration Type S/4HANA Public Cloud
Private
Internal ABAP custom code Keep as-is (stable) Not applicable (no custom ABAP)
PI/PO RFC adapter iFlows Keep/migrate to CPI Must replace with OData/API
RFC
Java/JCo external apps Assess: keep or move to Must replace with OData/REST
OData
.NET/NCo external apps Assess: keep or move to Must replace with OData/REST
OData
Third-party middleware Depends on adapter Must replace with standard APIs
support
Legacy BDC replacements Keep (stable, no Reassess with SAP Fiori APIs
replacement)
7.2 Modernization Decision Tree
• Is the BAPI deprecated by SAP in S/4HANA?: Yes → must migrate to the replacement
API. Check SAP Note 2265093 and the S/4HANA simplification list.
• Is an equivalent OData/REST API available?: Yes + integration is external/cloud → prefer
OData. No → continue using BAPI.
• Is the integration performance-critical and synchronous?: BAPIs over RFC may still
outperform OData for high-volume bulk operations.
• Is the integration team non-ABAP (Java, .NET, Python)?: Strongly prefer OData/REST
— eliminates the need for RFC libraries entirely.
• Is this a new development?: Always use modern APIs (OData, RAP-based, Events) for
greenfield development in S/4HANA or cloud.
Page 10 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
8. Frequently Used BAPIs by Module
8.1 Sales & Distribution (SD)
BAPI Name Purpose
BAPI_SALESORDER_CREATEFROMDAT2 Create sales order with full item and partner data
BAPI_SALESORDER_CHANGE Modify existing sales order (items, quantities, dates)
BAPI_SALESORDER_GETLIST Retrieve list of sales orders by criteria
BAPI_SALESORDER_SIMULATE Simulate order creation for validation without posting
BAPI_DELIVERY_CHANGE Change delivery document (quantities, shipping data)
BAPI_BILLINGDOC_CREATEMULTIPLE Create multiple billing documents in one call
8.2 Materials Management (MM)
BAPI Name Purpose
BAPI_PO_CREATE1 Create Purchase Order with items, conditions, account
assignment
BAPI_PO_CHANGE Change existing Purchase Order
BAPI_GOODSMVT_CREATE Post goods movements (GI, GR, transfer posting)
BAPI_MATERIAL_SAVEDATA Create or extend material master records
BAPI_PR_CREATE Create Purchase Requisition
BAPI_STOCK_AVAILABILITY Check material availability by plant and storage location
8.3 Financial Accounting (FI)
BAPI Name Purpose
BAPI_ACC_DOCUMENT_POST Post accounting documents (FI journal entries)
BAPI_INCOMINGINVOICE_CREATE Create vendor (Logistics) invoice via MIRO process
BAPI_INCOMINGINVOICE_PARK Park incoming invoice for later review and posting
BAPI_CUSTOMERDEBIT_CREATE Create customer debit memo / credit memo
BAPI_CUSTOMER_GETDETAIL2 Get detailed customer master financial data
BAPI_PAYMENT_SIMUL Simulate payment run for cash management / analysis
Page 11 of 12 | Confidential
BAPIs in SAP: ECC, S/4HANA & Cloud | Technical Reference Guide
9. Summary and Conclusion
BAPIs have been one of the most durable and impactful components of SAP's integration
architecture over the past three decades. From their introduction in R/3 as a replacement for raw
table access, through their central role in ECC integration landscapes, to their continued presence
in S/4HANA and hybrid cloud environments, BAPIs have proven remarkably resilient.
The transition to cloud does not eliminate BAPIs — rather, it provides a richer palette of integration
options alongside them. For existing landscapes, BAPIs remain valid, stable, and supported. For
new developments, particularly those targeting cloud-native or multi-cloud architectures, modern
OData and event-based APIs provide a more suitable foundation.
The key takeaway for architects and developers is to treat BAPIs as a managed asset: understand
what you have, know what SAP has replaced or deprecated, and make deliberate migration
decisions based on technical value rather than technology trend alone.
Primary Integration
Era BAPI Status Key Recommendation
Pattern
ECC (R/3 – ECC Primary standard RFC, JCo, NCo, SAP PI/XI Central to all integration
6.0) — use confidently
S/4HANA On-Prem Stable, supported, RFC + OData coexistence Keep existing, use OData
/ Private non-strategic for new builds
S/4HANA Cloud Not available (no OData v4, Events, REST Full migration to API Hub
Public RFC) services required
SAP BTP / Hybrid Via Cloud Connector CPI RFC adapter (hybrid) Wrap in REST service for
Cloud only cloud consumption
— End of Document —
Page 12 of 12 | Confidential