BAdI Part 6: Debugging BAdIs in Real Projects
Debug BAdI problems systematically: is the BAdI called at all, which implementations are active and match the filter, is my method reached, what data arrives — using breakpoints in CL EXITHANDLER, GET BADI / CALL BADI, the implementation class, and the debugger's enhancement tools.
Explanation
📌 KEY POINTS
✅ Debug in four steps: is the BAdI called? which implementations are found? is my method executed? is the data what I expect?
✅ Breakpoints: statement GET BADI / CALL BADI (new), method CL_EXITHANDLER=>GET_INSTANCE (classic), and your implementation method.
✅ Most "BAdI not working" cases are: implementation inactive, filter value not matching, wrong BAdI or code path, or another implementation overriding.
⚠️ External (user) breakpoints are needed when the BAdI runs in RFC/HTTP calls (e.g. Fiori, OData); background jobs need JDBG or SM50 debugging.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–5 built implementations. In support, the question is usually: "why does my BAdI not work?"
━━━━━━━━━━━━━━━━━━━━
▶ 1. IS THE BADI CALLED?
- Set a statement breakpoint on GET BADI/CALL BADI or a method breakpoint on CL_EXITHANDLER=>GET_INSTANCE and run the transaction.
- If never reached: wrong transaction step, wrong BAdI, or the code path (e.g. BAPI vs dialog) doesn't call it.
━━━━━━━━━━━━━━━━━━━━
▶ 2. WHICH IMPLEMENTATIONS?
- New BAdI: after GET BADI, inspect the BAdI reference in the debugger — it lists the implementation classes found for the filter.
- Classic: step into the adapter's method to see which implementations are called.
- SE19: check "active" status of your implementation in this system (transported? activated?).
━━━━━━━━━━━━━━━━━━━━
▶ 3. IS MY METHOD REACHED?
- Breakpoint in your implementing class method. If not reached though the BAdI is called: filter mismatch, inactive implementation, or a single-use conflict.
- Check filter values: company code '1000' vs '1000 ' or wrong characteristic.
━━━━━━━━━━━━━━━━━━━━
▶ 4. IS THE DATA RIGHT?
- Inspect import parameters and objects (e.g. IM_HEADER->GET_DATA( )).
- Check whether CHANGING values are overwritten by another implementation later (watchpoint).
━━━━━━━━━━━━━━━━━━━━
▶ 5. SPECIAL CASES
- Fiori/OData: set external breakpoints for the user making the call (Utilities → Settings → Debugging user).
- Background: JDBG in the job overview (SM37) or debug the running process from SM50.
- Update task: activate update debugging in the debugger settings when the BAdI runs during update.
━━━━━━━━━━━━━━━━━━━━
▶ 6. AFTER THE FIX
Document root cause; add a regression test case (transaction + data).
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- Deactivate your training implementation in a sandbox and debug: observe the BAdI reference without your class.
- Activate it with a wrong filter value; observe again.
- Correct the filter and verify with a breakpoint in the method.
✅ CHECKPOINT: you can find why a BAdI implementation does not run and prove the fix.
Code example
* ===== Debugging checklist as code comments =====* 1) Called? Breakpoint at statement GET BADI / CALL BADI* or method CL_EXITHANDLER=>GET_INSTANCE (classic)* 2) Found? Inspect BAdI reference after GET BADI (implementations list)* SE19: implementation active in THIS system?* 3) Reached? Breakpoint in your method; check filter values* 4) Correct? Inspect parameters; watchpoint on changed fields * ===== Temporary diagnostic logging in an implementation (remove after analysis) =====CLASS zcl_bi_invoice_1000 DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. INTERFACES if_badi_interface. INTERFACES zif_ex_invoice_check.ENDCLASS. CLASS zcl_bi_invoice_1000 IMPLEMENTATION. METHOD zif_ex_invoice_check~check. DATA ls_msg TYPE bapiret2.* Checkpoint group: activate in SAAB only when needed, no effect otherwise LOG-POINT ID zbadi_debug SUBKEY 'INVOICE_CHECK' FIELDS is_invoice-bukrs is_invoice-amount. BREAK-POINT ID zbadi_debug. " inactive unless activated in SAAB IF is_invoice-xblnr IS INITIAL. ls_msg-type = 'E'. ls_msg-id = 'ZFI'. ls_msg-number = '010'. APPEND ls_msg TO et_messages. ENDIF. ENDMETHOD.ENDCLASS. * ===== Background job: debug with JDBG =====* SM37 -> select finished job -> type JDBG in the command field -> job runs in debugger * ===== Fiori / OData call: external breakpoint =====* Debugger settings: set external breakpoint for the user calling the serviceReal project scenario
A BAdI validation worked in VA01 but not when orders came from the Fiori app. The developer's session breakpoint never stopped. With an external breakpoint for the Fiori user, the debugger showed the BAdI was called, but the filter value (sales org) was blank because the app filled it later in the process.
The team moved the check to a method called after the sales org was determined and documented the difference between the dialog and the API path.
Common mistakes
- Using session breakpoints for RFC/OData calls.
- Assuming the implementation is active in the target system.
- Ignoring filter mismatches (wrong value, leading zeros).
- Leaving BREAK-POINT statements without checkpoint group.
- Not checking other implementations that overwrite data.
Best practices
- Follow the four-step debugging sequence.
- Use external breakpoints for Fiori/RFC; JDBG for jobs.
- Use checkpoint groups (SAAB) for diagnostic points.
- Verify activation after every transport.
- Document root cause and test case.
Interview angle
Questions: "Your BAdI implementation is not triggered. What do you check?", "How do you debug a BAdI called from Fiori?"
Strong answer: check if the BAdI is called (GET BADI/CALL BADI or CL_EXITHANDLER breakpoints), which implementations are found (BAdI reference, SE19 active, filter values), whether the method is reached, and whether data is correct/overwritten; external breakpoints for OData/RFC, JDBG for jobs, update debugging for update task; checkpoint groups for diagnostics.
Practice this lesson
Quick check
1. A BAdI implementation is not reached, although the BAdI is called. Which is a likely cause?
2. What should you check if a BAdI implementation is not triggered?
3. New BAdIs are called using…
Interview questions
1. A BAdI implementation is active but not getting triggered. What would you check?
Answer it in your own words first, then compare.
2. My BAdI implementation is not triggered. Why?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.
More lessons in this topic
- BAdI Part 1: What a BAdI Is and How SAP Calls It
- BAdI Part 10: BAdIs in S/4HANA and Clean Core
- BAdI Part 2: Finding and Implementing a BAdI Step by Step
- BAdI Part 3: Designing Your Own BAdI — Fallback Class and Filters
- BAdI Part 4: Classic BAdI vs New BAdI
- BAdI Part 5: Single-Use vs Multiple-Use BAdIs
- BAdI Part 7: Using Filter-Dependent BAdIs
- BAdI Part 8: Implementation Design — Keep BAdI Logic Clean