Switch-Controlled Enhancements

Explanation

Production enhancements should be controllable. A switch-controlled enhancement uses a custom configuration table, feature toggle or switch class to decide whether custom logic should run. This is useful when the same enhancement is transported across multiple company codes, regions, processes or rollout phases. It also helps during emergency support because logic can be disabled without code rollback if designed correctly. Switch control is especially important for enhancements in sensitive transactions such as sales order save, delivery creation, billing, invoice posting and IDoc processing.

Code example

* Purpose:* Control enhancement execution using configuration.* This avoids hardcoding and makes rollout safer. DATA(lv_active) = zcl_enh_switch=>is_active(  iv_key   = 'DELIVERY_BLOCK_CHECK'  iv_vkorg = vbak-vkorg ). IF lv_active = abap_true.   * Execute custom rule only when configured as active  DATA(lo_checker) = NEW zcl_delivery_block_checker( ).  DATA(lv_block) = lo_checker->should_block_delivery( is_header = vbak ).   IF lv_block = abap_true.    likp-lifsk = 'Z1'.  ENDIF. ENDIF.

Real project scenario

A delivery block enhancement was enabled only for selected sales organizations using a custom Z configuration table. During rollout, the team activated it plant by plant without changing code.

Common mistakes

- Hardcoding activation logic. - Not allowing emergency disablement. - Using broad condition that affects all processes. - Not logging why enhancement was skipped or executed.

Best practices

- Use config-driven activation. - Avoid hardcoded org values. - Make enhancements easy to disable. - Log critical decisions where needed.

Interview angle

Architect-level answer should include switch/config control, rollout safety, emergency disable and auditability.