BAPI
Calling BAPIs from ABAP is the standard, safe way to create and change SAP business data programmatically, respecting SAP’s validations and logic. This page covers the practical pattern every ABAP developer must know.
BAPIs enforce SAP’s business logic and validations; writing to tables directly bypasses them and corrupts data.
- A BAPI is a released, remote-enabled function module for a business object (e.
- The RETURN table carries messages; an entry with type 'E' (or 'A') means failure.
- This page covers the practical pattern every ABAP developer must know.
- Watch out: Forgetting BAPI_TRANSACTION_COMMIT.
The BAPI calling pattern
A BAPI is a released, remote-enabled function module for a business object (e.g. create a sales order). You fill its import structures/tables, call it, inspect the RETURN table for errors, and, if successful, commit with BAPI_TRANSACTION_COMMIT (most BAPIs do not commit themselves).
Example
DATA lt_return TYPE bapiret2_t.
CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
EXPORTING order_header_in = ls_header
IMPORTING salesdocument = DATA(lv_vbeln)
TABLES order_items_in = lt_items
return = lt_return.
IF line_exists( lt_return[ type = 'E' ] ).
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
ELSE.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = abap_true.
ENDIF.Always check RETURN
The RETURN table carries messages; an entry with type 'E' (or 'A') means failure. Committing without checking, or ignoring errors, leads to partial or wrong data. Checking RETURN and committing/rolling back accordingly is non-negotiable.
Why BAPIs over direct writes
BAPIs enforce SAP’s business logic and validations; writing to tables directly bypasses them and corrupts data. Always prefer a BAPI (or a modern released API) for creating/changing business objects.
Common pitfalls
- Forgetting BAPI_TRANSACTION_COMMIT.
- Not checking the RETURN table for errors.
- Direct table writes instead of a BAPI.