Debugging BAdIs in Real Projects

Explanation

BAdI debugging is a key real-project skill. Sometimes the developer knows the BAdI name and can place a breakpoint directly in the implementation method. Other times, the BAdI must be found by debugging the process and searching for GET BADI or CALL BADI. For standard transactions, start with the business action such as Save, Post, Release or Output. Use the call stack to understand where the BAdI is called and whether required data is available. If filters are used, verify the filter value. If multiple implementations exist, check all active implementations.

Code example

* Practical BAdI debugging steps:* 1. Put external/session breakpoint in implementation method if known* 2. Execute the exact business action, such as Save button* 3. If BAdI is unknown, debug standard flow and search for GET BADI or CALL BADI* 4. Check filter values passed to GET BADI* 5. Check which implementation method is executed* 6. Inspect changing parameters and return messages * Important:* BAdI may be called before or after data is fully prepared.* Always verify whether required data is available at that point.

Real project scenario

A custom validation unexpectedly blocks purchase order save. Debugging shows that a filter-dependent BAdI implementation for the plant is active and returns an error message.

Common mistakes

- Debugging wrong transaction step. - Ignoring filter value. - Not checking all active implementations. - Assuming data is already available at BAdI call point.

Best practices

- Debug the exact business action. - Check BAdI method parameters. - Verify active implementation. - Check filter values. - Use call stack to understand timing.

Interview angle

A practical answer should include breakpoints, GET BADI, CALL BADI, filter values and active implementations.