SAP BAPIs and RFC Integration

TL;DR

• Bottom line: BAPIs are SAP's stable, business-object-oriented API layer built on top of RFC. Use bgRFC for all new asynchronous/transactional integrations; sRFC only for real-time lookups requiring immediate response.
• Key limit: sRFC blocks one dialog work process per call for the entire duration; tRFC/qRFC are deprecated — migrate to bgRFC which offers 40% better throughput via parallel queue scheduling. [src1, src7]
• Watch out for: Forgetting to call BAPI_TRANSACTION_COMMIT after BAPI calls — without it, no data persists. BAPI_TRANSACTION_ROLLBACK cannot reverse a previous commit. [src3, src4]
• Best for: System-to-system integration with SAP ECC or S/4HANA on-premise/private cloud where OData is not available or ABAP function modules are the primary interface.
• Authentication: RFC connections use SAP system user credentials (user/password or SNC certificate) via SM59 destination configuration; authorize with S_RFC object. [src8]

System Profile

This card covers SAP's Business Application Programming Interface (BAPI) and Remote Function Call (RFC) integration layer, applicable to both SAP ECC 6.0 (all EHP levels) and SAP S/4HANA on-premise/private cloud editions. BAPIs are methods of SAP Business Objects defined in the Business Object Repository (BOR, transaction BAPI/SWO1) that wrap RFC-enabled function modules with standardized interfaces, stable naming, and guaranteed backward compatibility. [src1, src5]

RFC is the underlying transport protocol. Five variants exist: synchronous (sRFC), asynchronous (aRFC), transactional (tRFC), queued (qRFC), and background (bgRFC). This card does NOT cover SAP Cloud Integration Suite, SAP BTP destinations, or S/4HANA Cloud public edition APIs (which use OData/REST exclusively).

API Surfaces & Capabilities

BAPIs are the application-level API; RFC variants are the transport-level protocol beneath them. Choosing the right RFC variant is critical. [src1, src5]

Rate Limits & Quotas

RFC does not have API call quotas like REST APIs. Instead, limits are defined by system resources — dialog work processes, memory, and RFC connection parameters. [src1]

Per-Request Limits

System Resource Limits

Transaction / Governor Limits

Authentication

RFC authentication is configured at the SAP system level via SM59 (RFC destination maintenance) and is fundamentally different from token-based REST authentication. [src8]

Authentication Gotchas

• S_RFC wildcard authorization is a critical security risk: Many systems still have S_RFC = * which grants access to ALL remote-enabled function modules. Use UCON enforcement mode to whitelist only required FMs. [src8]
• SNC certificate mismatch silently downgrades to unencrypted: If snc/only_encrypted_rfc is not set to 1, failed SNC negotiation falls back to plaintext. [src8]
• Service user password expiration breaks integrations: Use system users (type B) for RFC connections — they don't expire. Dialog users (type A) have password policies that will break unattended integrations. [src8]
• Trusted RFC (S_RFCACL) with wildcards enables privilege escalation: An attacker on a trusted system can impersonate any user. Define exact user mappings. [src8]

Constraints

• BAPI_TRANSACTION_COMMIT is mandatory: No BAPI call persists data without an explicit commit. This is not auto-committed like REST APIs. [src3, src4]
• tRFC and qRFC are deprecated: SAP recommends bgRFC for all new development since NetWeaver 7.0. [src1, src6]
• sRFC blocks caller and target work process: Unsuitable for high-volume or high-latency scenarios. Each concurrent sRFC ties up one dialog work process on both sides. [src1]
• RFC SDK licensing: JCo, NCo, PyRFC, and NW RFC SDK require a valid SAP license. Cannot be redistributed in open-source projects. [src2]
• ROLLBACK cannot undo a prior COMMIT: If you commit after step 1 and rollback after step 2, step 1 remains committed. Structure all steps in a single LUW. [src3, src4]
• No native webhook/push from RFC: RFC is pull-based. For event-driven patterns, combine with SAP Event Mesh, ALE/IDocs, or bgRFC with custom scheduling. [src1]

Integration Pattern Decision Tree

START — User needs to integrate with SAP via BAPI/RFC
|
+-- What's the integration pattern?
|   |
|   +-- Real-time (individual records, <1s latency)
|   |   +-- Need immediate response? --> sRFC: call BAPI, get RETURN
|   |   +-- Fire-and-forget OK? --> bgRFC with high-priority queue
|   |   +-- Write with confirmation? --> sRFC + check RETURN + COMMIT
|   |
|   +-- Batch/Bulk (scheduled, high volume)
|   |   +-- <1,000 records? --> sRFC loop with commit per batch
|   |   +-- >1,000 records? --> bgRFC with parallel queues (40% faster)
|   |   +-- Need ordering? --> bgRFC single named queue (FIFO)
|   |
|   +-- Event-driven
|   |   +-- SAP triggers? --> bgRFC outbound to registered RFC server
|   |   +-- Need exactly-once? --> bgRFC (replaces tRFC semantics)
|   |   +-- Not native RFC --> use SAP Event Mesh or IDoc
|   |
|   +-- File-based --> Not RFC — use IDoc, FBDI, or BW extractors
|
+-- Which connector?
|   +-- Java --> SAP JCo 3.1
|   +-- .NET --> SAP NCo 3.1
|   +-- Python --> PyRFC 3.x (via SAP NW RFC SDK)
|   +-- Node.js --> node-rfc or SAP Cloud SDK
|   +-- Other --> SAP NW RFC SDK (C/C++)
|
+-- Error tolerance?
    +-- Zero-loss --> bgRFC + SBGRFCMON + dead letter handling
    +-- Best-effort --> aRFC (fastest, no persistence)

Quick Reference

Common BAPIs for Integration

RFC Variant Quick Comparison

Step-by-Step Integration Guide

1. Configure RFC Destination (SM59)

Create an RFC destination in the SAP system to define connection parameters for external systems. [src1]

Transaction: SM59
1. Create new destination: Type T (TCP/IP) for external, Type 3 for SAP-to-SAP
2. Set Activation Type: "Registered Server Program"
3. Set Program ID (must match external application)
4. For SNC: Technical Settings tab, set SNC partner name and QoP
5. Test connection: green light = success

Verify: SM59 → select destination → "Connection Test" → expected: green status, round-trip time displayed

2. Call a BAPI via sRFC with JCo (Java)

Use SAP JCo 3.1 to invoke a BAPI synchronously. JCo handles connection pooling, data type conversion, and RFC protocol details. [src2]

// Get destination from properties file
JCoDestination destination = JCoDestinationManager.getDestination("SAP_SYSTEM");

// Get function template from SAP metadata
JCoFunction function = destination.getRepository()
    .getFunction("BAPI_COMPANYCODE_GETLIST");

// Execute synchronous RFC call
function.execute(destination);

// Check RETURN for errors
JCoStructure ret = function.getExportParameterList().getStructure("RETURN");
if ("E".equals(ret.getString("TYPE")))
    throw new RuntimeException("BAPI error: " + ret.getString("MESSAGE"));

// Process results
JCoTable codes = function.getTableParameterList().getTable("COMPANYCODE_LIST");
for (int i = 0; i < codes.getNumRows(); i++) {
    codes.setRow(i);
    System.out.println(codes.getString("COMP_CODE") + " - " + codes.getString("COMP_NAME"));
}

Verify: Run application → expected: list of company codes printed; no exceptions

3. Call a Write BAPI with Commit/Rollback Pattern

Write BAPIs require explicit BAPI_TRANSACTION_COMMIT. Never call COMMIT WORK directly — it skips BAPI buffer refresh logic. [src3, src4]

// Execute the write BAPI
createSO.execute(dest);

// Check ALL RETURN table entries for errors
JCoTable returnTable = createSO.getTableParameterList().getTable("RETURN");
boolean hasErrors = false;
for (int i = 0; i < returnTable.getNumRows(); i++) {
    returnTable.setRow(i);
    String msgType = returnTable.getString("TYPE");
    if ("E".equals(msgType) || "A".equals(msgType)) {
        hasErrors = true;
    }
}

// Single commit or rollback for entire LUW
if (!hasErrors) {
    JCoFunction commit = dest.getRepository()
        .getFunction("BAPI_TRANSACTION_COMMIT");
    commit.getImportParameterList().setValue("WAIT", "X"); // Synchronous
    commit.execute(dest);
} else {
    JCoFunction rollback = dest.getRepository()
        .getFunction("BAPI_TRANSACTION_ROLLBACK");
    rollback.execute(dest);
}

Verify: SE16 → table VBAK → expected: new sales order with correct header data

4. Implement bgRFC for Guaranteed Async Delivery

bgRFC replaces tRFC and qRFC with better performance and monitoring. [src1, src6]

" Get bgRFC destination (configured in SBGRFCCONF)
DATA(lo_dest) = cl_bgrfc_destination_outbound=>create( 'DESTINATION_NAME' ).

" Create bgRFC unit (use create_qrfc_unit for ordered delivery)
DATA(lo_unit) = lo_dest->create_trfc_unit( ).

" Call function module within bgRFC unit
CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
  IN BACKGROUND UNIT lo_unit
  EXPORTING order_header_in = ls_header
  TABLES order_items_in = lt_items return = lt_return.

" Unit persisted to DB on COMMIT WORK
COMMIT WORK.
" bgRFC scheduler delivers when target is available

Verify: SBGRFCMON → expected: unit ID visible with status "Executed" or "Waiting"

Code Examples

Python: Read Material Master via PyRFC

# Input:  SAP connection parameters, material number
# Output: Material description and base unit of measure
# Requires: pyrfc>=3.3 + SAP NW RFC SDK installed

from pyrfc import Connection

conn = Connection(
    ashost='sap-server.example.com', sysnr='00',
    client='100', user='RFC_USER', passwd='secure_password', lang='EN'
)

result = conn.call('BAPI_MATERIAL_GETDETAIL', MATERIAL='MAT-001', PLANT='1000')

ret = result.get('RETURN', {})
if ret.get('TYPE') == 'E':
    raise RuntimeError(f"BAPI error: {ret['MESSAGE']}")

mat_desc = result['MATERIAL_GENERAL_DATA']['MATL_DESC']
print(f"Material: {mat_desc}")
conn.close()

JavaScript/Node.js: Call BAPI via node-rfc

// Input:  SAP connection parameters
// Output: List of company codes
// Requires: [email protected] + SAP NW RFC SDK

const noderfc = require('node-rfc');
const client = new noderfc.Client({
    ashost: 'sap-server.example.com', sysnr: '00',
    client: '100', user: 'RFC_USER', passwd: 'secure_password'
});

async function getCompanyCodes() {
    await client.open();
    const result = await client.call('BAPI_COMPANYCODE_GETLIST', {});
    if (result.RETURN?.TYPE === 'E')
        throw new Error(`BAPI error: ${result.RETURN.MESSAGE}`);
    for (const cc of result.COMPANYCODE_LIST)
        console.log(`${cc.COMP_CODE} - ${cc.COMP_NAME}`);
    await client.close();
}
getCompanyCodes().catch(console.error);

cURL: N/A — RFC Is Not HTTP-Based

# RFC is a binary protocol, not HTTP. Cannot use cURL directly.
# For HTTP-based SAP integration, use:
# - SAP API Business Hub (api.sap.com) with OData/REST
# - SAP Cloud Connector + BTP for RFC-over-HTTP tunneling
# - SAP Gateway (SEGW) to expose BAPIs as OData services

Data Mapping

BAPI Parameter Structure Reference

BAPI RETURN Structure (BAPIRET2)

Data Type Gotchas

• SAP dates are CHAR 8 (YYYYMMDD), not ISO 8601: Convert '20260301' to '2026-03-01'. Empty date = '00000000', not null. [src5]
• SAP amounts may lack decimal places: Check CURRENCY field to determine positioning. JPY has 0 decimals; USD has 2. Use BAPI_CURRENCY_CONV_TO_EXTERNAL. [src5]
• Leading zeros in SAP IDs: Material, customer, and vendor numbers have leading zeros (e.g., '0000001000'). Use CONVERSION_EXIT_ALPHA_INPUT/OUTPUT. [src5]
• Character encoding on older systems: Verify target code page (SM21). JCo/NCo handle conversion; raw RFC SDK requires manual handling. [src2]

Error Handling & Failure Points

Common Error Codes

Failure Points in Production

• Missing BAPI_TRANSACTION_COMMIT: Data appears to save but disappears after dialog step ends. Fix: Always call BAPI_TRANSACTION_COMMIT with WAIT='X' after checking RETURN. [src3, src4]
• tRFC queue buildup (SM58): Thousands of stuck entries consume DB space. Fix: Migrate to bgRFC; parallel schedulers + efficient storage. [src6, src7]
• JCo connection pool exhaustion: Under load, all connections used. Fix: Set jco.destination.peak_limit > pool_capacity; set expiration_time. [src2]
• SNC certificate expiration: Integration stops silently. Fix: Monitor with STRUST; set reminders 30 days before expiry. [src8]
• Partial commit in multi-BAPI transactions: Earlier commits cannot be rolled back. Fix: Call ALL BAPIs first, check ALL RETURNs, then single COMMIT/ROLLBACK. [src3]
• aRFC data loss: Calls to unreachable systems silently lost. Fix: Use bgRFC for guaranteed delivery; never aRFC for business-critical data. [src1]

Anti-Patterns

Wrong: COMMIT WORK Instead of BAPI_TRANSACTION_COMMIT

" BAD — COMMIT WORK skips BAPI buffer refresh logic
CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2' ...
COMMIT WORK.  " Missing BUFFER_REFRESH_ALL, stale buffers

Correct: Always Use BAPI_TRANSACTION_COMMIT

" GOOD — calls BUFFER_REFRESH_ALL internally
CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2' ...
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
  EXPORTING WAIT = 'X'.  " Synchronous — waits for DB commit

[src4]

Wrong: Committing Inside a Loop

// BAD — each iteration is a separate LUW; cannot rollback later
for (Item item : items) {
    function.execute(destination);
    commitFunction.execute(destination); // COMMIT per item -- WRONG
}

Correct: Batch All Calls, Single Commit at End

// GOOD — all items in one LUW; single commit/rollback
boolean hasErrors = false;
for (Item item : items) {
    function.execute(destination);
    if (checkReturnForErrors(function)) { hasErrors = true; break; }
}
if (!hasErrors) commitFunction.execute(destination);
else rollbackFunction.execute(destination);

[src3, src4]

Wrong: Using tRFC for New Projects

" BAD — tRFC deprecated; single scheduler, poor performance
CALL FUNCTION 'Z_SEND_ORDER'
  IN BACKGROUND TASK DESTINATION 'TARGET_SYSTEM' ...
COMMIT WORK.

Correct: Use bgRFC for All New Async Work

" GOOD — multiple schedulers, parallel queues, 40% better throughput
DATA(lo_dest) = cl_bgrfc_destination_outbound=>create( 'TARGET_SYSTEM' ).
DATA(lo_unit) = lo_dest->create_trfc_unit( ).
CALL FUNCTION 'Z_SEND_ORDER'
  IN BACKGROUND UNIT lo_unit DESTINATION 'TARGET_SYSTEM' ...
COMMIT WORK.

[src6, src7]

Common Pitfalls

• Forgetting WAIT='X' on BAPI_TRANSACTION_COMMIT: Without it, commit is async — next read may return stale data. Fix: Always pass WAIT='X' for integrations reading back after writing. [src4]
• Not handling the full RETURN table: Checking only RETURN structure misses errors in RETURN[] table. Fix: Iterate the RETURN table, not just the export structure. [src3]
• Dialog users for RFC accounts: Password expiration breaks unattended integrations. Fix: Use system users (type B) in SU01. [src8]
• JCo pool_capacity=1 default: Serializes all requests under load. Fix: Set pool_capacity to expected concurrency; peak_limit 2-3x pool_capacity. [src2]
• Ignoring SM58/SBGRFCMON monitoring: Stuck entries silently accumulate. Fix: Periodic monitoring jobs; alert on entries stuck >1h. [src6, src7]
• Hardcoding SAP field lengths: Material number extended to 40 chars in S/4HANA. Fix: Use JCo/NCo metadata APIs for dynamic field lengths. [src2]

Diagnostic Commands

# SAP transaction codes for RFC diagnostics

# Check RFC destination connectivity
SM59 -> select destination -> "Connection Test"

# Monitor stuck tRFC entries (legacy)
SM58 -> filter by date/destination

# Monitor bgRFC units and queues
SBGRFCMON -> filter by destination/status

# bgRFC history and performance
SBGRFCHIST (history) / SBGRFCPERFMON (throughput)

# Short dumps from failed RFC calls
ST22 -> filter by date/user

# RFC work process usage
SM66 (running processes) / SM04 (active sessions)

# Authorization failure diagnosis
SU53 -> shows last auth failure

# External: Check JCo version
java -cp sapjco3.jar com.sap.conn.jco.JCo

# External: Check PyRFC version
python -c "import pyrfc; print(pyrfc.__version__)"

# External: Test RFC connection from Python
python -c "
from pyrfc import Connection
c = Connection(ashost='host', sysnr='00', client='100', user='USER', passwd='PASS')
print('Connected:', c.get_connection_attributes())
c.close()
"

Version History & Compatibility

Deprecation policy: SAP does not formally sunset tRFC/qRFC — they remain functional indefinitely. However, all new documentation and features target bgRFC exclusively. SAP Note 1889823 recommends bgRFC migration. [src1, src6]

When to Use / When Not to Use

Important Caveats

• tRFC/qRFC are deprecated but not removed: They will continue to work, but SAP invests zero effort in performance improvements. Plan bgRFC migration for any system on NetWeaver 7.0+. [src6]
• RFC SDK licensing is strict: JCo, NCo, PyRFC, and NW RFC SDK cannot be bundled in commercial products without SAP licensing agreement. [src2]
• S/4HANA Cloud public edition does NOT support RFC: Only OData, REST, and SOAP APIs available. This card is irrelevant for public cloud customers.
• Performance varies by network latency: sRFC round-trip directly affected by WAN latency. Consider SAP Cloud Connector for cross-region integrations. [src1]
• BAPI behavior differs between ECC and S/4HANA: Some BAPIs have changed parameters (e.g., material number extended to 40 chars). Always test against target version. [src2]