RFC vs BAPI in SAP: Protocol, Function Modules and Business APIs

Remote Function Call defines how ABAP systems and external programs invoke remote-enabled function modules, transfer typed parameters, handle communication/system failures, and support synchronous or transactional variants. BAPIs add an application contract on top: named business object/method semantics, standardized RETURN handling, documented transaction behavior, and a stability/release expectation for external consumption. A custom Z RFC can be perfectly valid for an internal landscape but it does not become a BAPI merely because it starts with a certain name or is remotely enabled. Conversely, a BAPI's underlying technical implementation is still an RFC-capable function module in classic systems.

Choose a released BAPI when SAP provides one that matches the required business operation and the target landscape still supports BAPI/RFC integration. Use a custom RFC only when no appropriate released API exists and the organization accepts ownership of the custom contract. For new S/4HANA clean-core integrations, first evaluate released OData/SOAP/event APIs and communication scenarios; a classic BAPI may still be right, but existence in SE37 is not enough. Use RFC for technical/admin operations only when the called interface is intentionally remote-enabled and authorized.

RFC destinations in SM59 supply connectivity and authentication. BAPIs often require BAPI_TRANSACTION_COMMIT/ROLLBACK because the business LUW is controlled by the remote caller. tRFC/qRFC/bgRFC add reliability/ordering patterns, while a normal BAPI call is usually synchronous RFC unless wrapped differently. Integration Suite can call RFC/BAPI through supported adapters/connectivity, but the business semantics still come from the BAPI or custom function. Authorization checks run in the target system under the RFC user/principal.

An external procurement app needs to create purchase orders. The backend contains many remote-enabled function modules that standard SAP itself uses, plus BAPI_PO_CREATE1 and a released REST API. Calling an internal remote FM may work in development but ties the integration to an implementation detail. The team compares the released API and BAPI based on functional coverage. If it chooses the BAPI, it handles RETURN fully and commits explicitly. SM59 connectivity is infrastructure; it does not define the business API contract.

Classic RFC/BAPI remains available in S/4HANA on-premise/private cloud and is still widely used. SAP's clean-core direction favors released APIs and contracts, and ABAP Cloud cannot freely call unreleased function modules. Side-by-side extensions should select the released interface with the best semantic fit; that may be OData, SOAP, event, IDoc or BAPI depending on the scenario.

Integration architects choose the contract; ABAP teams own custom RFCs/wrappers and BAPI handling; Basis owns SM59/connectivity; Security owns authentication/authorizations; functional teams validate that the chosen BAPI/API actually implements the required business semantics.

SM59 maintains RFC destinations. The BAPI library documents individual business APIs. The RFC-types topic explains synchronous, transactional, queued and background RFC behavior beyond a simple remote call.

Production verification: Capture destination or caller and target system, RFC user or propagated identity, function or BAPI name, business key, complete RETURN or message set, transaction and commit state, and any SM59, SM58 or SMQ evidence. Separate communication success from application authorization and from durable business posting.

Operational readiness: For production readiness of RFC vs BAPI in SAP: Protocol, Function Modules and Business APIs, add an operational runbook that names the source owner, integration or platform owner, and target application owner; defines correlation, retry or replay and duplicate handling; and states where a support engineer can prove the last successful handoff. Test authentication expiry, receiver outage, malformed or business-invalid payloads, and ambiguous timeouts—not only the happy path. If the interface is asynchronous, document queue, retention and order behavior and how a corrected message is reprocessed without duplicating a business transaction.