Debugging Part 7: Update Task Debugging

📌 KEY POINTS
✅ CALL FUNCTION … IN UPDATE TASK only registers the call; the update function runs after COMMIT WORK in an update work process — not in your dialog session.
✅ To stop there, activate "Update Debugging" in the debugger settings before the COMMIT (then the update runs in a new debugger session).
✅ Failed updates appear in SM13 (status ERR) with the terminated function module; the dump is in ST22 for the update user/work process.
⚠️ An error in the update task rolls back the whole LUW's V1 updates — the user saw "saved", but nothing was written.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 6 read dumps. Some errors happen after the user already saw a success message — in the update task.

━━━━━━━━━━━━━━━━━━━━
▶ 1. HOW THE UPDATE TASK WORKS

• Dialog program registers update FMs (IN UPDATE TASK) and forms (PERFORM … ON COMMIT).
• COMMIT WORK: ON COMMIT forms run, then update records (VBHDR/VBMOD/VBDATA) are processed by an update work process.
• V1 (critical, e.g. document tables) processed first, V2 (statistics) later; V1 errors cancel the LUW.
• COMMIT WORK AND WAIT: dialog waits for V1 completion.

━━━━━━━━━━━━━━━━━━━━
▶ 2. WHY BREAKPOINTS DON'T STOP
The update FM runs in another work process; session breakpoints don't apply.

━━━━━━━━━━━━━━━━━━━━
▶ 3. UPDATE DEBUGGING

• In the debugger: Settings → Update Debugging (on).
• Continue to COMMIT WORK; after it, a new debugger window opens for the update task; set breakpoints in the update FM there.
• For PERFORM ON COMMIT: breakpoints work in the same session (they run in dialog at commit), no update debugging needed.

━━━━━━━━━━━━━━━━━━━━
▶ 4. FAILED UPDATES

• SM13: records with status ERR (error), INIT (waiting), per user/date; details show the FM and the error; in test systems they can be re-processed after fixing (careful in production).
• ST22: dump in the update work process.
• SM21: system log entries about update terminations.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TYPICAL CAUSES
Duplicate keys (INSERT of existing record), data type conversions, locks not held, missing mandatory fields, custom update FMs with MESSAGE E/A.

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

1. Run the code example; activate update debugging before COMMIT WORK.
2. Force a duplicate key insert and find the error in SM13 and ST22.
3. Fix the logic (MODIFY or existence check) and rerun.

✅ CHECKPOINT: you can debug update-task code and analyse update terminations.

Users confirmed that sales orders were "saved", but some did not exist. SM13 showed update terminations in a custom log FM called from USEREXIT_SAVE_DOCUMENT: it inserted a record with a key that already existed for reprocessed orders, and the abort message rolled back the whole order.
Changing INSERT to MODIFY for the log and removing the abort message fixed the lost orders. SM13 monitoring for ERR records became part of daily checks.

• Expecting session breakpoints in update FMs.
• MESSAGE A/E in custom update FMs.
• INSERT without duplicate handling.
• Not monitoring SM13.
• Reprocessing failed updates in production without analysis.

• Use update debugging for IN UPDATE TASK code.
• Robust update FMs (MODIFY, no dialog messages).
• COMMIT WORK AND WAIT when results are needed.
• Monitor SM13/ST22.
• Analyse before reprocessing updates.

Questions: "How do you debug a function module called IN UPDATE TASK?", "Where do you see update errors?", "V1 vs V2?"
Strong answer: IN UPDATE TASK registers, runs after COMMIT WORK in update work process; enable update debugging before commit; PERFORM ON COMMIT runs in dialog; V1 critical first, V2 later, V1 error rolls back LUW; SM13 ERR records, ST22 dumps, SM21; common causes duplicate keys, messages in update FMs.