BAPI Part 5: Commit, WAIT, Rollback and the SAP LUW

📌 KEY POINTS
✅ Most BAPIs register their database changes in the update task; nothing is saved until the caller commits.
✅ BAPI_TRANSACTION_COMMIT with WAIT = 'X' waits until the update is done — needed before reading the new document or calling a dependent BAPI.
✅ On errors, BAPI_TRANSACTION_ROLLBACK discards everything registered since the last commit.
⚠️ A successful RETURN does not guarantee the update succeeds — update errors appear later in SM13; with WAIT = 'X' the commit's RETURN shows them.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 4 read RETURN. Now we decide what gets saved and when.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHY BAPIS DON'T COMMIT
The caller may need several BAPIs to form one business transaction (e.g. create order + change something else). Leaving the commit to the caller allows all-or-nothing behaviour.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 2. BAPI_TRANSACTION_COMMIT\n• Calls COMMIT WORK (AND WAIT if WAIT = 'X').

• RETURN parameter: reports problems of the synchronous commit (with WAIT).
• Without WAIT, the program continues while the update runs; reading the document immediately may fail.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 3. BAPI_TRANSACTION_ROLLBACK\nCalls ROLLBACK WORK — discards registered updates and releases locks. Always call it after E/A messages, before processing the next document.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ONE LUW PER BUSINESS DOCUMENT
In uploads, commit (or roll back) after each document, so one bad row doesn't discard the others, and locks are released.

━━━━━━━━━━━━━━━━━━━━
▶ 5. SEVERAL BAPIS IN ONE LUW

• Allowed when documented (e.g. dependent changes that must succeed together).
• If the second BAPI needs data from the first document in the database, you need a commit in between — then they are no longer one LUW.
• Some BAPIs must not be combined in one LUW (see documentation: "must not be called together with …").

━━━━━━━━━━━━━━━━━━━━
▶ 6. BAPIS THAT COMMIT THEMSELVES
A few older BAPIs commit internally (check documentation, e.g. some master data BAPIs). Don't combine them with others in one LUW.

━━━━━━━━━━━━━━━━━━━━
▶ 7. AFTER THE COMMIT

• Check document existence if critical (SELECT SINGLE on the header table).
• Update terminations: SM13 and ST22; monitor them in interfaces.

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

1. Post a goods movement with BAPI_GOODSMVT_CREATE (code example) without commit — check MKPF: nothing.
2. Commit with WAIT and read the material document.
3. Force an error and verify rollback.

✅ CHECKPOINT: you control commit and rollback deliberately around each BAPI-based business transaction.

A goods receipt interface posted material documents and immediately called a Z BAPI to update a tracking table with the document number. Randomly, the second step failed with "document not found", because the first commit was issued without WAIT and the update had not finished.
Using BAPI_TRANSACTION_COMMIT with WAIT = 'X' and checking its RETURN fixed the timing. The team also added an SM13 monitor alert for update terminations from the interface user.

• Forgetting the commit (nothing saved, locks held).
• Commit without WAIT, then reading the new document.
• No rollback after errors, so the next document's commit saves partial data.
• Combining BAPIs that commit themselves with others.
• Not monitoring SM13 update errors.

• One LUW per business document in mass processing.
• Commit with WAIT when results are needed immediately.
• Roll back after E/A.
• Read BAPI documentation for LUW restrictions.
• Monitor SM13/ST22 for update terminations.

Questions: "Why do BAPIs not commit?", "What does WAIT do?", "What happens if you don't roll back after an error?"
Strong answer: BAPIs register updates in the update task, caller controls the LUW; BAPI_TRANSACTION_COMMIT WAIT = 'X' waits for V1 update (needed before reading/dependent calls) and returns update errors; ROLLBACK discards and releases locks; without it the next commit may save leftovers; one LUW per document; monitor SM13.