Safe Coding Rules Inside User Exits

Explanation

User exits run inside SAP standard flow, often during save, post or create actions. This means custom logic must be very safe. Start with guard conditions. Use configuration or switch control. Keep the exit small. Move complex logic into a service class. Avoid COMMIT WORK, rollback, slow RFC calls and broad database reads. Use clear messages. In production support, a support consultant should be able to quickly understand why the exit is running and how to disable or restrict it if needed.

Code example

* Purpose:* Production-safe pattern for user exits.* Keep the exit as a thin adapter and call reusable service logic. FORM userexit_save_document_prepare.   * Step 1: Check activation switch/config.  IF zcl_exit_switch=>is_active(       iv_key   = 'SD_ORDER_VALIDATION'       iv_vkorg = vbak-vkorg ) <> abap_true.    RETURN.  ENDIF.   * Step 2: Delegate business logic to service class.  DATA(lo_validator) = NEW zcl_sd_order_validator( ).   DATA(lt_return) = lo_validator->validate_order(    is_header = vbak    it_item   = xvbap[] ).   * Step 3: Raise clean business message if validation failed.  IF line_exists( lt_return[ type = 'E' ] ).    MESSAGE 'Sales order validation failed. Check mandatory business data.' TYPE 'E'.  ENDIF. ENDFORM.

Real project scenario

A delivery block rule is controlled through a Z configuration table so it can be activated sales-org wise during rollout.

Common mistakes

- Writing hundreds of lines inside the exit. - Hardcoding activation values. - Using COMMIT WORK inside save exits. - Not providing emergency disable option.

Best practices

- Use configuration-driven activation. - Keep exit code small. - Delegate to service class. - Avoid unsafe COMMIT WORK. - Document business purpose.

Interview angle

Senior candidates should mention guard conditions, switch control, service class delegation and no unsafe commits.