Enhancements Part 9: Performance and Safety in Enhancements

📌 KEY POINTS
✅ Enhancement code runs inside SAP's LUW: never COMMIT WORK, ROLLBACK WORK or CALL TRANSACTION that commits.
✅ Code in exits and BAdIs may run per item, per document and in background — design for volume.
✅ Messages must fit the context: type E at the right place (check exits), no popups in background or update task.
⚠️ One SELECT in an item-level exit can become 500,000 SELECTs in a mass run — buffer.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–8 were about choosing and implementing enhancements. This lesson makes sure they don't break or slow down standard processes.

━━━━━━━━━━━━━━━━━━━━
▶ 1. TRANSACTION CONSISTENCY

• SAP saves the document at the end of its own LUW. A COMMIT in your code writes half-finished data or breaks the update.
• Don't call BAPIs that commit, CALL TRANSACTION, or SUBMIT AND RETURN with commits inside save exits.
• For additional database changes: use update function modules IN UPDATE TASK or PERFORM … ON COMMIT so they are saved with SAP's commit.

━━━━━━━━━━━━━━━━━━━━
▶ 2. MESSAGES AND DIALOGS

• Error messages (type E) belong in validation exits (e.g. USEREXIT_SAVE_DOCUMENT_PREPARE, check BAdI methods). In other exits they can terminate processing unexpectedly.
• No POPUP_TO_CONFIRM, no screens when sy-batch = 'X' or in update task.
• In BAPIs/IDocs there is no user — messages must be returned, not displayed.

━━━━━━━━━━━━━━━━━━━━
▶ 3. PERFORMANCE

• Avoid SELECT inside item loops; read once per document (or buffer in a static/class attribute keyed by document).
• Use SELECT SINGLE with full key or buffered tables; check with ST05 and SAT.
• Guard conditions first: IF vbak-auart <> 'ZOR'. RETURN. ENDIF. → the enhancement does nothing for other cases.
• Clear buffers when the document changes (keyed buffer, not "first call only").

━━━━━━━━━━━━━━━━━━━━
▶ 4. ROBUSTNESS

• Catch exceptions from your classes; a dump in an exit stops the whole transaction (ST22).
• Don't rely on SAP global variables that are not documented for that exit.
• Initialise your own global variables — exits run many times in one session.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TESTING AND MONITORING

• Test all paths: dialog, background (mass), BAPI, IDoc.
• Measure with a realistic volume; compare runtime with and without the enhancement.
• After go-live, check ST22 and SM13 (update errors) regularly.

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

1. Review an existing item-level exit: count SELECTs with ST05 on a 100-item order.
2. Introduce a keyed buffer as in the code example and re-measure.
3. Search your enhancements for COMMIT WORK (SE80 code scanner / CODE_SCANNER).

✅ CHECKPOINT: your enhancements respect the LUW, give correct messages and scale with volume.

A billing exit read the customer master (KNVV) and a Z pricing table for every item. Monthly billing of 400,000 items took 9 hours instead of 2, and the job overlapped with the morning shift.
ST05 showed 800,000 identical SELECTs. The team added a guard condition for the relevant billing types and a keyed buffer class; runtime dropped to 2 hours 15 minutes. A code review also found a COMMIT WORK in another exit, which was replaced by an update function module.

• COMMIT WORK or BAPI with commit inside exits.
• Popups or error messages in background and interfaces.
• SELECT per item without buffering.
• No guard conditions — code runs for every document.
• Global variables not initialised between documents.

• Respect SAP's LUW; use update task for extra writes.
• Guard conditions at the top.
• Buffer reads with keyed tables.
• Messages appropriate to exit type and processing mode.
• Test with volume and all paths; monitor ST22/SM13.

Questions: "What must you never do in a user exit or BAdI?", "How do you make enhancements performant?", "How do you save extra data from an exit?"
Strong answer: no COMMIT/ROLLBACK/CALL TRANSACTION inside SAP's LUW; extra data via update FM IN UPDATE TASK or PERFORM ON COMMIT; no dialogs in background/BAPI; error messages only in validation exits; guard conditions, buffered reads, no SELECT per item; test all paths with volume; monitor ST22/SM13.