ABAP Developmentintermediate

BAPI Part 4: Understanding BAPI RETURN Messages

Key takeaway

Read BAPI results correctly: BAPIRET2 fields (TYPE, ID, NUMBER, MESSAGE, MESSAGE V1–V4, PARAMETER, ROW, FIELD), message types S/I/W/E/A, older RETURN types (BAPIRETURN, BAPIRETURN1), mapping messages to logs, and turning them into readable errors for users and interfaces.

Explanation

📌 KEY POINTS
✅ BAPIRET2 contains TYPE (S, I, W, E, A), ID + NUMBER (message class/number), MESSAGE (text), MESSAGE_V1–V4, PARAMETER, ROW and FIELD.
✅ Types E and A mean failure; W and I are information; S is success — but a BAPI may return several messages of different types.
✅ PARAMETER and ROW tell you which input structure and which line caused the error — essential for uploads.
⚠️ Some older BAPIs use BAPIRETURN or BAPIRETURN1 (a single structure, not a table) — check the parameter type.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–2 checked RETURN simply. Real projects need precise error handling and logging.

━━━━━━━━━━━━━━━━━━━━
▶ 1. BAPIRET2 FIELDS

TYPE — S success, I info, W warning, E error, A abort.
ID / NUMBER — message class and number (e.g. V1 / 382); allows looking up the long text (SE91) and precise handling.
MESSAGE — formatted text in the logon language.
MESSAGE_V1..V4 — variables.
PARAMETER — BAPI parameter name (e.g. ORDER_ITEMS_IN); ROW — line in that table; FIELD — field name.
LOG_NO / LOG_MSG_NO — application log references (some BAPIs).
SYSTEM — logical system that produced the message.

━━━━━━━━━━━━━━━━━━━━
▶ 2. SUCCESS OR FAILURE

Failure: any TYPE = 'E' or 'A'.
Success: no E/A; often a specific S message (e.g. "Standard Order 12345 has been saved" — only after commit is it really saved).
Warnings can indicate incomplete documents (e.g. incompletion) — decide per business process whether they are acceptable.

━━━━━━━━━━━━━━━━━━━━
▶ 3. OLDER RETURN TYPES

BAPIRETURN (CODE instead of ID/NUMBER), BAPIRETURN1 (single structure). Check TYPE similarly.

━━━━━━━━━━━━━━━━━━━━
▶ 4. LOGGING

Persist messages per business key (file row, IDoc, external ID) — e.g. in the application log (SLG1 via BAL_LOG_CREATE / BAL_LOG_MSG_ADD / BAL_DB_SAVE) or a Z log table.
Keep ID/NUMBER/variables, not only text (texts are language-dependent).

━━━━━━━━━━━━━━━━━━━━
▶ 5. USER-FRIENDLY OUTPUT

In an upload report: show row number from your file + PARAMETER/ROW mapping + MESSAGE.
In dialog: MESSAGE ID ls_return-id TYPE 'I' NUMBER ls_return-number WITH v1 v2 v3 v4.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Call a BAPI with a wrong material and inspect all RETURN fields in the debugger.
Add the messages to an application log (code example) and view it in SLG1.
Map PARAMETER/ROW back to your input line.

✅ CHECKPOINT: you evaluate RETURN precisely, log it and present errors clearly.

Code example

ABAP Code

* ===== Evaluate RETURN and write an application log (SLG1) =====FORM evaluate_return USING it_return  TYPE bapiret2_t                           iv_extkey  TYPE balnrext         " e.g. file row / external ID                  CHANGING cv_error   TYPE abap_bool.  DATA: ls_return TYPE bapiret2,        ls_log    TYPE bal_s_log,        ls_msg    TYPE bal_s_msg,        lv_handle TYPE balloghndl,        lt_handle TYPE bal_t_logh.   cv_error = abap_false. * ----- create log -----  ls_log-object    = 'ZINTERFACE'.       " defined in SLG0  ls_log-subobject = 'SALESORDER'.  ls_log-extnumber = iv_extkey.  CALL FUNCTION 'BAL_LOG_CREATE'    EXPORTING i_s_log = ls_log IMPORTING e_log_handle = lv_handle    EXCEPTIONS OTHERS = 1.   LOOP AT it_return INTO ls_return.    IF ls_return-type CA 'EA'.      cv_error = abap_true.              " E or A = failure    ENDIF.*   ----- keep ID/NUMBER/variables, not only text -----    CLEAR ls_msg.    ls_msg-msgty = ls_return-type.    ls_msg-msgid = ls_return-id.    ls_msg-msgno = ls_return-number.    ls_msg-msgv1 = ls_return-message_v1.    ls_msg-msgv2 = ls_return-message_v2.    ls_msg-msgv3 = ls_return-message_v3.    ls_msg-msgv4 = ls_return-message_v4.    CALL FUNCTION 'BAL_LOG_MSG_ADD'      EXPORTING i_log_handle = lv_handle i_s_msg = ls_msg      EXCEPTIONS OTHERS = 1.*   PARAMETER / ROW point to the failing input line    IF ls_return-parameter IS NOT INITIAL.      WRITE: / iv_extkey, ls_return-parameter, ls_return-row, ls_return-message.    ENDIF.  ENDLOOP.   APPEND lv_handle TO lt_handle.  CALL FUNCTION 'BAL_DB_SAVE'    EXPORTING i_t_log_handle = lt_handle    EXCEPTIONS OTHERS = 1.ENDFORM. * Note: BAL_DB_SAVE writes to the DB; call it where a separate commit is acceptable* (e.g. after BAPI_TRANSACTION_COMMIT/ROLLBACK), or save with i_2th_connection.

Real project scenario

An upload of 2,000 purchase orders reported "Error in document" for 300 rows without details, because the program only showed the first RETURN message text. Users could not correct the file.
The team logged every message with PARAMETER, ROW and the file row number to SLG1 and showed an ALV of errors per file row. Most errors turned out to be missing purchasing info records, which master data fixed in one day.

Common mistakes

Checking only the first RETURN line.
Treating warnings as errors (or vice versa) without a business decision.
Storing only MESSAGE text (language-dependent).
Ignoring PARAMETER/ROW.
Assuming BAPIRET2 when the BAPI uses BAPIRETURN1.

Best practices

Evaluate all lines; E/A = failure.
Log ID/NUMBER/V1–V4 with a business key.
Use SLG1 application logs for interfaces.
Map PARAMETER/ROW to input lines.
Check the RETURN type of each BAPI.

Interview angle

Questions: "How do you evaluate BAPI RETURN?", "What are PARAMETER and ROW?", "How do you log BAPI messages?"
Strong answer: BAPIRET2 with TYPE/ID/NUMBER/MESSAGE/V1–V4/PARAMETER/ROW/FIELD; E/A = error, check all lines; warnings per business rule; log with application log (BAL_LOG_CREATE, BAL_LOG_MSG_ADD, BAL_DB_SAVE) using ID/number/variables and a business key; older BAPIs use BAPIRETURN/BAPIRETURN1.

Practice this lesson

Quick check

1. A BAPI call returns sy-subrc = 0 and RETURN contains a type 'E' message. What is the result?

2. In the standard BAPIRET2 return structure, what does a value of 'E' in the TYPE field indicate?

3. Why do standard BAPIs generally avoid declaring classic ABAP EXCEPTIONS in their interface?

Interview questions

1. A material upload reported success because every function module call returned SY-SUBRC = 0, but many materials were not created. What went wrong?

Answer it in your own words first, then compare.

2. External system floods SAP with BAPI calls. How do you protect performance?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.