SAP BAPIs and RFCs

RFC stands for Remote Function Call. It is SAP's mechanism for calling a function that runs on a remote SAP system as if it were running locally. When System A needs System B to execute a calculation or retrieve data, System A makes an RFC call. System B runs the function and returns the result. To System A, it feels like calling a local function — the remote execution is hidden underneath.

Think of RFC like a phone order at a restaurant. You call the kitchen from your table (a remote call), tell them what you want (the function parameters), and they prepare it and send it back to you (the return values). You did not go to the kitchen yourself — you made a remote call and got the result delivered.

Types of RFC

sRFC – Synchronous RFC

The caller waits until the remote function finishes and returns a result. If the network fails mid-call, the call fails and must be retried manually. Use sRFC when the caller needs the result immediately before continuing.

aRFC – Asynchronous RFC

The caller fires the RFC and does not wait for a response. Execution continues immediately. Use aRFC when the calling program does not need the result from the remote function.

tRFC – Transactional RFC

Guarantees that the remote function executes exactly once, even if the network fails. The system assigns a unique transaction ID (TID) to each call. If the call is retried due to network failure, SAP checks the TID and skips execution if it already ran. Use tRFC for business-critical data that must not be duplicated.

qRFC – Queued RFC

Extends tRFC by adding message queues. Calls are placed in a named queue and processed in order, one at a time. Use qRFC when the sequence of processing matters — for example, material master updates must process in the order they were created.

RFC TYPE COMPARISON:
┌──────┬─────────────┬──────────────┬─────────────────────────┐
│ Type │ Waits?      │ Exactly Once?│ Ordered?                │
├──────┼─────────────┼──────────────┼─────────────────────────┤
│ sRFC │ Yes         │ No           │ N/A                     │
│ aRFC │ No          │ No           │ No                      │
│ tRFC │ No          │ Yes          │ No                      │
│ qRFC │ No          │ Yes          │ Yes (within queue)      │
└──────┴─────────────┴──────────────┴─────────────────────────┘

What Is a BAPI

BAPI stands for Business Application Programming Interface. A BAPI is a special type of RFC function module that SAP designed specifically for external use. While general RFC function modules may be internal SAP utilities, BAPIs are stable, documented, and intended to be called from outside SAP.

SAP ships hundreds of BAPIs covering all major business processes. They follow naming conventions and include standardized return structures. BAPIs are the recommended way to integrate external applications with SAP business processes without direct database access.

BAPI Examples You Will Commonly Use

BAPI_SALESORDER_CREATEFROMDAT2 – Create a sales order in SD
BAPI_PO_CREATE1 – Create a purchase order in MM
BAPI_MATERIAL_SAVEDATA – Create or update material master data
BAPI_CUSTOMER_CREATEFROMDATA1 – Create a customer master record
BAPI_ACC_DOCUMENT_POST – Post an accounting document in FI
BAPI_EMPLOYEE_GETDATA – Read employee data from HCM
BAPI_GOODSMVT_CREATE – Post a goods movement in MM/WM

BAPI Structure

Every BAPI has a consistent parameter structure:

BAPI PARAMETERS:
┌─────────────────────────────────────────────────┐
│  IMPORT parameters  → Data you send to SAP      │
│    (order header, line items, quantities)       │
├─────────────────────────────────────────────────┤
│  EXPORT parameters  ← Data SAP sends back       │
│    (created document number, status)            │
├─────────────────────────────────────────────────┤
│ TABLES parameters  → Send lists; ← receive lists│
│    (multiple line items, multiple messages)     │
├─────────────────────────────────────────────────┤
│  RETURN parameter   ← Always present            │
│    TYPE: S=Success, E=Error, W=Warning, I=Info  │
│    MESSAGE: Human-readable description          │
└─────────────────────────────────────────────────┘

Always check the RETURN table after calling a BAPI. A call that does not throw a technical error can still return business errors in the RETURN table. For example, calling BAPI_SALESORDER_CREATEFROMDAT2 might technically succeed but return RETURN entries saying the customer does not exist. Your integration must read and handle these return messages.

The BAPI Commit Step

Most BAPIs that create or change data require a separate commit call after the BAPI itself. The data is staged in memory until you explicitly call BAPI_TRANSACTION_COMMIT. Only then does SAP save it to the database. This is critical — calling the BAPI without the commit means the data is never saved.

CORRECT sequence:
1. Call BAPI_SALESORDER_CREATEFROMDAT2 (stages data)
2. Check RETURN for errors
3. If no errors: Call BAPI_TRANSACTION_COMMIT (saves to database)
4. If errors: Call BAPI_TRANSACTION_ROLLBACK (discards staged data)

INCORRECT (data never saved):
1. Call BAPI_SALESORDER_CREATEFROMDAT2
2. ← MISSING COMMIT → data lost

Calling BAPIs from CPI

CPI uses the RFC adapter to call BAPIs. You configure the adapter with the SAP system connection details and specify the BAPI name. CPI sends the parameters as XML, the RFC adapter converts them to the binary RFC format, SAP executes the BAPI, and the result comes back to CPI as XML for further processing.

[CPI iFlow] → [RFC Adapter] → BAPI_SALESORDER_CREATEFROMDAT2 → [SAP SD]
               (XML to RFC)                                    (creates order)
[CPI iFlow] ← [RFC Adapter] ← RETURN table + order number    ← [SAP SD]
               (RFC to XML)

Finding BAPIs in SAP

Use SAP transaction BAPI (the BAPI Explorer) to browse all available BAPIs organized by business object. Search for the business object you need (Customer, SalesOrder, PurchaseOrder) and see all BAPIs available for that object. Each BAPI entry shows its parameters, documentation, and sample code.

You can also use transaction SE37 (Function Module display) to examine a specific BAPI's parameters in detail, see example values, and even test the BAPI directly with sample data before building your integration.

BAPIs vs IDocs vs OData

Three major mechanisms exist for posting data to SAP. Choosing the right one depends on your scenario:

Use BAPIs/RFCs when you need synchronous confirmation of success or failure, and when the calling system needs the SAP document number returned immediately
Use IDocs when dealing with EDI partners, high-volume batch transfers, or when guaranteed delivery queuing is required
Use OData APIs in SAP S/4HANA scenarios where modern REST-based integration is preferred

Many projects use all three depending on the specific interface requirement.

Previous lesson

Back to course

Next lesson