Modularization Part 5: Update Function Modules and IN UPDATE TASK

📌 KEY POINTS
✅ An SAP LUW groups all database changes of a business transaction — they are written together or not at all.
✅ CALL FUNCTION 'Z_UPD' IN UPDATE TASK only registers the call; it runs at COMMIT WORK.
✅ V1 = critical, synchronous-with-commit updates; V2 = statistical, lower priority.
⚠️ Never COMMIT WORK inside an update function module or in code called from BAdIs/user exits of standard transactions.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–4 covered units. This part explains how SAP transactions save data consistently — you will see it in every standard transaction, BAPI and in RAP's save phase.

━━━━━━━━━━━━━━━━━━━━
▶ 1. DATABASE LUW VS SAP LUW

• Database LUW: changes between two database commits. Every dialog step (screen change) triggers an implicit database commit.
• SAP LUW: a business transaction spanning several dialog steps (e.g. VA01 screens). To keep it atomic, changes are collected and executed together at COMMIT WORK in the update task.

━━━━━━━━━━━━━━━━━━━━
▶ 2. UPDATE FUNCTION MODULES

• Processing type "Update module" in SE37 (start immediately = V1, start delayed = V2).
• Only IMPORTING and TABLES parameters (by value), no EXPORTING — they run later, in the update work process.
• Contain the actual INSERT/UPDATE/DELETE statements.

━━━━━━━━━━━━━━━━━━━━
▶ 3. THE FLOW

1. Dialog/program: CALL FUNCTION 'Z_FLIGHT_BOOK_UPD' IN UPDATE TASK EXPORTING … (registered, not executed).
2. More registrations possible (several tables/FMs).
3. COMMIT WORK — the update work process executes all registered update FMs in one database LUW.
4. On error in an update FM → all changes rolled back, update terminated, entry in SM13, user gets an express mail.

• COMMIT WORK AND WAIT — waits until the update is finished (synchronous) — use when the next step needs the data (e.g. read the new document).
• ROLLBACK WORK — discards all registered update calls.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 4. PERFORM … ON COMMIT\nRegisters a FORM to be executed at COMMIT WORK (in the dialog process), e.g. to collect data before the update. ON ROLLBACK for cleanup.

━━━━━━━━━━━━━━━━━━━━
▶ 5. LOCKS
Lock the objects (ENQUEUE) before changing; locks are passed to the update task (_SCOPE = 2 default) and released after the update.

━━━━━━━━━━━━━━━━━━━━
▶ 6. WHERE YOU MEET THIS

• Standard transactions and BAPIs (BAPI_TRANSACTION_COMMIT = COMMIT WORK).
• User exits/BAdIs in save processing — they run inside SAP's LUW: no COMMIT WORK there!
• RAP unmanaged/unmanaged-save scenarios call legacy code IN UPDATE TASK in the save phase.

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

1. Create update FM Z_FLIGHT_LOG_UPD (update module, start immediately) inserting into a custom log table.
2. Register it in a report IN UPDATE TASK, then COMMIT WORK AND WAIT.
3. Force an error in the FM and check SM13.

✅ CHECKPOINT: you understand how SAP transactions save atomically and where not to commit.

A developer added a COMMIT WORK into a user exit during sales order save "to make sure the Z table is written". Occasionally, the order save later failed; the Z table already contained data for orders that did not exist, and some orders were partially saved.
The fix wrote the Z table via an update function module registered IN UPDATE TASK in the exit — without COMMIT. SAP's own COMMIT WORK then saved order and Z data together, or neither.

• COMMIT WORK in user exits, BAdIs or update modules.
• Expecting IN UPDATE TASK calls to run immediately.
• EXPORTING parameters in update FMs.
• Not using COMMIT WORK AND WAIT when the next step reads the new data.
• Ignoring SM13 update errors.

• Put DB changes of a business transaction into update FMs.
• Register with IN UPDATE TASK; commit once at the end.
• Use AND WAIT when subsequent reads depend on the update.
• Lock objects before changing them.
• Monitor SM13 for update terminations.

Questions: "What is an SAP LUW?", "What does IN UPDATE TASK do?", "V1 vs V2 update?", "Why no COMMIT WORK in user exits?"
Strong answer: an SAP LUW bundles changes of a business transaction across dialog steps; update FMs registered IN UPDATE TASK execute together at COMMIT WORK in the update process (V1 critical, V2 statistical), rolled back entirely on error (SM13); COMMIT WORK AND WAIT is synchronous; exits run inside SAP's LUW, so committing there breaks atomicity.