BAdI Implementation Design: Keep Logic Clean

Explanation

A BAdI method should not become a huge block of custom code. The better design is to keep the BAdI method as an adapter and delegate business logic to a service class. This makes the code easier to test, reuse and debug. It also prevents the BAdI implementation from becoming tightly coupled to one transaction. Clean BAdI design is especially important in processes such as sales order save, delivery processing, billing, purchase order release and finance posting, where custom logic can affect critical business operations.

Code example

* Purpose:* Keep BAdI method small.* Delegate business logic to reusable service class.* This makes implementation easier to test and maintain. METHOD if_ex_zsd_order_check~check_order.   DATA(lo_validator) = NEW zcl_sd_order_validator( ).   * BAdI method only passes data and receives messages  lo_validator->validate(    EXPORTING      is_header = is_header      it_item   = it_item    CHANGING      ct_return = ct_return ). ENDMETHOD. * Why this is better:* The same validator can be reused outside the BAdI.* Unit testing is easier.* BAdI implementation remains readable.

Real project scenario

A sales order BAdI calls a custom validation service class. The service class can also be reused by an OData service and a background validation report.

Common mistakes

- Writing hundreds of lines directly inside BAdI method. - Mixing validation, database selection and message formatting together. - Not creating reusable service classes. - Making BAdI implementation hard to test.

Best practices

- Keep BAdI method small. - Use service classes for business rules. - Keep message handling consistent. - Avoid hidden global dependencies.

Interview angle

Senior candidates should explain that BAdI implementation should delegate complex logic to classes and remain lightweight.