User Exits Part 7: Safe Coding Rules Inside User Exits

📌 KEY POINTS
✅ Every exit starts with guard conditions: document type, org unit, transaction type (T180-TRTYP), processing mode.
✅ Never COMMIT WORK, ROLLBACK WORK, CALL TRANSACTION, SUBMIT … AND RETURN with commits, or leave the program inside an exit.
✅ Declare own global variables with a ZZ prefix in the customer declaration includes and reset them when a new document starts.
⚠️ Exits run in dialog, background, BAPIs and IDocs — a popup or a type 'A' message can stop a whole interface run.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 4–6 showed what to do in specific exits. This lesson is the rule set for any exit.

━━━━━━━━━━━━━━━━━━━━
▶ 1. GUARD FIRST

• CHECK vbak-auart = 'ZOR'. or IF … RETURN.
• CHECK t180-trtyp <> 'A'. (no logic in display)
• Check the call context when needed: sy-tcode is unreliable for BAPIs; use call_bapi/call_activity flags where the program provides them, or sy-batch.

━━━━━━━━━━━━━━━━━━━━
▶ 2. TRANSACTIONAL SAFETY

• SAP commits the document itself. Own DB writes → update function modules IN UPDATE TASK or PERFORM … ON COMMIT.
• No CALL TRANSACTION / BAPIs that commit / RFC with implicit commit inside save exits.

━━━━━━━━━━━━━━━━━━━━
▶ 3. MESSAGES

• E in checking exits (e.g. SAVE_DOCUMENT_PREPARE) — stops save, BAPI returns it.
• W/I only when the process can handle it; avoid in background.
• Never 'A' or 'X' messages in exits.
• No POPUP_TO_CONFIRM when sy-batch = 'X' or in BAPI calls.

━━━━━━━━━━━━━━━━━━━━
▶ 4. GLOBAL DATA

• Change only fields the exit is intended to change.
• Don't modify SAP internal tables used for control (except documented X tables with UPDKZ).
• Own globals: declare in MV45ATZZ (sales) / similar declaration includes with ZZ prefix; CLEAR them at the start of a new document.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CODE ORGANISATION

• FORM in SAP include only calls Z FORMs/classes (e.g. INCLUDE ZMV45AFZZ_SO in MV45AFZZ, or class methods).
• One requirement = one clearly named routine with a header comment (requirement ID, owner).
• Version history and transport description reference the requirement.

━━━━━━━━━━━━━━━━━━━━
▶ 6. REVIEWS
Code review checklist: guards, no commit, messages, performance (Part 8), all paths tested.

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

1. Review one existing exit against this checklist.
2. Move its logic into a Z include or class with a header comment.
3. Add a guard and test in dialog and via BAPI.

✅ CHECKPOINT: your exit code is guarded, transaction-safe and organised for maintenance.

An EDI interface creating 5,000 orders per night started failing after a change: a new check in MV45AFZZ used POPUP_TO_CONFIRM to ask users about a price deviation. In the BAPI path there was no user, and the IDoc processing ended with errors for every affected order.
The check was changed to an error message with a clear text in dialog and a RETURN entry in BAPI calls; the price deviation was also added to the IDoc monitoring. The team added "no popups in exits" to the review checklist.

• Missing guard conditions.
• COMMIT WORK or CALL TRANSACTION inside exits.
• Popups or A-messages that block background processing.
• Own globals not reset between documents.
• Logic written directly into SAP includes without structure.

• Guard by document type, org unit and TRTYP.
• Own writes via update task only.
• Messages suitable for dialog and BAPI.
• ZZ-prefixed, reset globals in declaration includes.
• Z includes/classes with requirement headers and code reviews.

Questions: "What rules do you follow in user exits?", "Why no COMMIT in a user exit?", "How do you handle messages in exits used by BAPIs?"
Strong answer: guard conditions (type, org, TRTYP), no COMMIT/ROLLBACK/CALL TRANSACTION (SAP owns the LUW; use update task), E messages in check exits, no popups/A messages, change only intended fields, ZZ globals reset per document, logic in Z includes/classes, test dialog/BAPI/IDoc.