ABAP Developmentbeginner

BAdI Part 1: What a BAdI Is and How SAP Calls It

Key takeaway

Understand Business Add-Ins: the BAdI definition and its interface, implementations as classes, how SAP calls classic BAdIs (CL EXITHANDLER) and new BAdIs (GET BADI / CALL BADI), and the transactions SE18 and SE19.

What this complete series covers

Learn BAdIs from definitions and implementations through filters, debugging, performance and clean-core extension design.

Who it is for: Best for SAP consultants, developers, and learners who want a practical understanding of BAdI.
Prerequisites: Basic SAP navigation and ABAP syntax help. For hands-on practice, use an ABAP system with ADT or the relevant ABAP development tools.
Final outcome: By the end, you should be able to find the correct BAdI, implement it safely, understand filter behavior and troubleshoot active implementations.

Part 1: BAdI Part 1: What a BAdI Is and How SAP Calls It
Understand a BAdI as a framework-defined extension contract: the definition describes interface and selection behavior, while one or more active implementations provide customer lo
Part 2: BAdI Part 2: Finding and Implementing a BAdI Step by Step
Find and implement a BAdI correctly by understanding the definition, enhancement spot, interface, filter behavior, implementation type and the runtime call path before writing custom code.
Part 3: BAdI Part 3: Designing Your Own BAdI — Fallback Class and Filters
Design filter-dependent BAdIs so every supported business case resolves predictably, with non-overlapping filter ownership, documented fallback behavior and testable implementation logic.
Part 4: BAdI Part 4: Classic BAdI vs New BAdI
Understand classic and new BAdIs by their enhancement-framework model, runtime behavior and implementation lifecycle, and always inspect the actual definition, filters and active i
Part 5: BAdI Part 5: Single-Use vs Multiple-Use BAdIs
Understand whether a BAdI permits one or multiple active implementations and how runtime behavior, filters and implementation ordering expectations affect production troubleshooting.
Part 6: BAdI Part 6: Debugging BAdIs in Real Projects
Debug BAdIs by identifying the actual definition and active implementation set, capturing runtime filter values and call timing, then reproducing the exact business action with targeted breakpoints.
Part 7: BAdI Part 7: Using Filter-Dependent BAdIs
Use filter-dependent BAdIs when one extension definition needs distinct implementations selected by stable business context, with governed filter ownership and explicit behavior fo
Part 8: BAdI Part 8: Implementation Design — Keep BAdI Logic Clean
Keep BAdI implementations as thin extension adapters that validate context and delegate reusable business logic to service classes, preserving testability and minimizing upgrade-sensitive coupling.
Part 9: BAdI Part 9: Performance and Database Access in BAdIs
Keep BAdI methods efficient by eliminating repeated SQL, caching stable configuration within the call, using set-based reads and avoiding synchronous external dependencies in criti
Part 10: BAdI Part 10: BAdIs in S/4HANA and Clean Core
Use released BAdIs as a preferred in-core S/4HANA extension mechanism when configuration is insufficient and the requirement must participate directly in the standard transaction,

System and release assumptions: Examples follow modern ABAP practices. Exact syntax, available APIs, and tools can vary by SAP release, so release-dependent points are called out where needed.

Explanation

📌 KEY POINTS
✅ A BAdI (Business Add-In) is an object-oriented enhancement: SAP defines an interface, you implement it in a class.
✅ SE18 shows the BAdI definition (interface, methods, parameters); SE19 is where you create your implementation.
✅ Classic BAdIs are called via CL_EXITHANDLER=>GET_INSTANCE; new BAdIs (Enhancement Framework) via GET BADI and CALL BADI.
⚠️ A BAdI method only receives what its parameters provide — design your logic around that data, not around global SAP variables.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

Part 1 — what a BAdI is and how SAP calls it (this lesson)
Part 2 — finding and implementing a BAdI step by step
Part 3 — own BAdIs: fallback class and filter design
Part 4 — classic BAdI vs new BAdI
Part 5 — single-use vs multiple-use BAdIs
Part 6 — debugging BAdIs
Part 7 — using filter-dependent BAdIs
Part 8 — clean implementation design
Part 9 — performance and database access
Part 10 — BAdIs in S/4HANA and clean core

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHY BADIS
User exits and customer exits allow only one implementation and are procedural. BAdIs are interfaces: several implementations are possible (if allowed), filters select implementations by org unit or country, and each implementation is a class with methods and typed parameters.

━━━━━━━━━━━━━━━━━━━━
▶ 2. THE PARTS

BAdI definition (SE18) — name, interface (e.g. IF_EX_ME_PROCESS_PO_CUST for classic BAdI ME_PROCESS_PO_CUST), settings: multiple use, filter.
Interface — methods with IMPORTING/CHANGING/EXPORTING parameters and exceptions.
Implementation (SE19) — your Z implementation with an implementing class (ZCL_IM_… for classic).
Calling code in the SAP program.

━━━━━━━━━━━━━━━━━━━━
▶ 3. HOW SAP CALLS A CLASSIC BADI
CALL METHOD cl_exithandler=>get_instance CHANGING instance = l_badi. then CALL METHOD l_badi->check EXPORTING … . The exit handler creates an object that calls all active implementations.

━━━━━━━━━━━━━━━━━━━━
▶ 4. HOW SAP CALLS A NEW BADI
GET BADI l_badi (FILTERS …). then CALL BADI l_badi->method … . The kernel handles instances — faster than classic BAdIs. New BAdIs live in enhancement spots.

━━━━━━━━━━━━━━━━━━━━
▶ 5. WHAT A METHOD LOOKS LIKE
Example classic BAdI ME_PROCESS_PO_CUST (purchase order), method CHECK: gets the PO header object IM_HEADER and a CHANGING flag CH_FAILED. Your code reads the header/items via the object's methods and sets CH_FAILED to prevent saving.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

SE18: display ME_PROCESS_PO_CUST; look at the interface methods and "multiple use" setting.
Open the interface IF_EX_ME_PROCESS_PO_CUST in SE24 and read the parameters of CHECK.
SE19: display existing implementations of this BAdI in your system.

✅ CHECKPOINT: you can explain what a BAdI consists of and recognise classic and new BAdI calls in SAP code.

Code example

ABAP Code

* ===== How SAP calls a CLASSIC BAdI (inside SAP code, read-only) =====*  DATA l_badi TYPE REF TO if_ex_me_process_po_cust.*  CALL METHOD cl_exithandler=>get_instance*    EXPORTING exit_name = 'ME_PROCESS_PO_CUST'*    CHANGING  instance  = l_badi.*  CALL METHOD l_badi->check*    EXPORTING im_header = l_header ...*    CHANGING  ch_failed = l_failed. * ===== How SAP calls a NEW BAdI =====*  DATA l_badi TYPE REF TO badi_name.*  GET BADI l_badi FILTERS bukrs = l_bukrs.*  CALL BADI l_badi->method EXPORTING ... * ===== Your implementation class (classic BAdI ME_PROCESS_PO_CUST, created in SE19) =====CLASS zcl_im_po_check DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    INTERFACES if_ex_me_process_po_cust.ENDCLASS. CLASS zcl_im_po_check IMPLEMENTATION.  METHOD if_ex_me_process_po_cust~check.    DATA ls_header TYPE mepoheader.    ls_header = im_header->get_data( ).           " read PO header via the object     IF ls_header-bsart = 'ZNB' AND ls_header-ekgrp IS INITIAL.      ch_failed = abap_true.                      " prevents saving    ENDIF.  ENDMETHOD. * Other interface methods stay empty (implement only what you need)  METHOD if_ex_me_process_po_cust~initialize.  ENDMETHOD.  METHOD if_ex_me_process_po_cust~open.  ENDMETHOD.  METHOD if_ex_me_process_po_cust~process_header.  ENDMETHOD.  METHOD if_ex_me_process_po_cust~process_item.  ENDMETHOD.  METHOD if_ex_me_process_po_cust~post.  ENDMETHOD.  METHOD if_ex_me_process_po_cust~close.  ENDMETHOD.* ... (the interface has further methods; SE19 creates empty ones for you)ENDCLASS.

Real project scenario

A purchasing team wanted to stop POs of type ZNB without a purchasing group. The developer found classic BAdI ME_PROCESS_PO_CUST, created implementation ZIM_PO_CHECK in SE19 and implemented method CHECK.
Because the BAdI is multiple-use, another team's implementation for approvals continued to work unchanged. During testing the team learned that CH_FAILED alone blocks saving silently in some cases, so they added a proper error message via the MM message macros (Part 2).

Common mistakes

Confusing the BAdI definition (SAP) with the implementation (customer).
Using global SAP variables instead of method parameters.
Forgetting to activate the implementation in SE19.
Putting all logic directly in the method instead of a class.
Not checking for existing implementations.

Best practices

Read the interface documentation in SE18 before coding.
Implement only the methods you need; leave others empty.
Keep BAdI methods thin and delegate to own classes.
Check existing implementations and multiple-use setting.
Test all processing paths that call the BAdI.

Interview angle

Questions: "What is a BAdI?", "Difference between SE18 and SE19?", "How does SAP call a BAdI?"
Strong answer: a BAdI is an OO enhancement with an interface defined by SAP (SE18) and customer implementations as classes (SE19); classic BAdIs are called via CL_EXITHANDLER=>GET_INSTANCE, new BAdIs via GET BADI/CALL BADI (kernel-based, in enhancement spots); can be multiple-use and filter-dependent; data only via method parameters.

Practice this lesson

Quick check

1. In a classic BAdI such as ME_PROCESS_PO_CUST, who creates the implementing class?

2. Which transaction is commonly used to view BAdI definitions?

3. What does BAdI stand for?

Interview questions

1. What is a BAdI?

Answer it in your own words first, then compare.

2. What is a BAdI in SAP ABAP?