BAPI

A BAPI connects an object-oriented definition to a classic implementation:

1. In the Business Object Repository, a business object type such as a purchase order declares methods like create, change or get detail. Each of these API methods is a BAPI.
2. Behind each method sits an RFC-enabled function module, so the BAPI can be called inside the system or remotely over RFC.
3. The caller passes import parameters and tables; the BAPI reports success or errors in a return parameter typed with the BAPIRET2 structure rather than raising exceptions.
4. Changing BAPIs follow a transaction model in which the BAPI itself does not commit. The caller decides when to save, typically by calling BAPI_TRANSACTION_COMMIT after one or more BAPI calls, or the rollback counterpart after an error.

The BAPI Explorer, started with transaction BAPI, browses business object types and their BAPIs by application component and shows parameters and documentation. A BAPI is therefore a business-level contract over a function module, with the commit left to the caller.

BAPIs predate SAP Fiori and OData, yet they remain part of many landscapes:

• Point-to-point and middleware integrations that call SAP ERP or SAP S/4HANA over RFC, for example to create sales orders from a web shop.
• Data migration and mass processing programs that post documents through the same checks as the dialog transactions.
• OData services built on top of BAPIs. On-premise, SAP Gateway projects often map an entity's operations to existing BAPIs through the Service Builder's RFC/BOR import, and SAP documents a RAP pattern that calls a BAPI inside a RAP business object through a wrapper class.

At Alder Manufacturing, a supplier portal that creates purchase orders for Cedar Office Supply may still post through a purchase order BAPI wrapped in a newer API. BAPIs often survive as the engine under a modern interface rather than as the interface itself.

SAP classifies BAPIs as classic APIs. They are not released APIs in the ABAP Cloud sense, so code written in the ABAP for Cloud Development language version cannot call them directly.

SAP publishes a list of classic APIs for Private Edition and points developers to the BAPI Explorer to study them. Clean core reporting counts references to listed classic APIs separately from released APIs. A BAPI is therefore tolerated as a bridge in a clean core landscape, not treated as the target interface.

1. Forgetting the commit. The call returns without errors but nothing is saved, because the caller never triggered BAPI_TRANSACTION_COMMIT.
2. Ignoring the return table. BAPIs report errors as messages in the return parameter; a program that only checks for exceptions posts nothing and reports success.
3. Confusing "released" labels. The BAPI Explorer shows BAPIs released in the Business Object Repository, which is not the same as an API released under an ABAP Cloud release contract.
4. Wrapping without ownership. A C1 wrapper around a BAPI needs an owner who replaces it when SAP releases a successor API.

Most BAPI defects come from the transaction model and message handling, not from the business logic inside the BAPI.