ABAP Developmentintermediate

BAdI Part 5: Single-Use vs Multiple-Use BAdIs

Key takeaway

Understand how the "multiple use" setting changes BAdI behaviour: several implementations running in sequence, no guaranteed order, CHANGING parameters in multiple-use BAdIs, single-use BAdIs that return values, conflicts between implementations and how to manage several teams in one BAdI.

Explanation

📌 KEY POINTS
✅ Multiple-use BAdI: all active (filter-matching) implementations run, one after another.
✅ Single-use BAdI: exactly one implementation (or the fallback) runs — typical when the method returns a value.
✅ Multiple-use BAdIs cannot have EXPORTING/RETURNING parameters; they use CHANGING, so each implementation sees previous changes.
⚠️ The execution order of multiple implementations is not guaranteed (unless sorting is configured) — never depend on it.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 4 compared BAdI generations. Now: what happens when more than one team implements the same BAdI?

━━━━━━━━━━━━━━━━━━━━
▶ 1. MULTIPLE USE

Setting in the BAdI definition (SE18: "Multiple Use").
Example: ME_PROCESS_PO_CUST — purchasing, finance and a logistics project can each have an implementation.
All run; each can set CH_FAILED or change CHANGING data.
Order: not defined by default. New BAdIs allow a sort sequence via the BAdI implementation's layer/sort settings (BADI_SORTER) in some releases; don't rely on it without documentation.

━━━━━━━━━━━━━━━━━━━━
▶ 2. SINGLE USE

Only one active implementation per filter combination allowed; activating a second one gives an error.
Methods may return values (EXPORTING/RETURNING) — no conflict about "whose result wins".
A fallback class provides the default if nobody implements it.

━━━━━━━━━━━━━━━━━━━━
▶ 3. CONFLICTS IN MULTIPLE-USE BADIS

Two implementations change the same field → the last one wins, order undefined.
One implementation relies on data set by another → breaks when order changes.
Solution: one implementation per business area that calls a central dispatcher class, or clearly separated responsibilities (different fields, different filters).

━━━━━━━━━━━━━━━━━━━━
▶ 4. GOVERNANCE

Before creating a new implementation, list existing ones (SE19 → where-used / SE18 "Implementations").
Define an owner per BAdI and per implementation.
Prefer one implementation per project that delegates to several classes in a defined order.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DEACTIVATING
Classic: deactivate in SE19. New: BAdI implementation "Implementation is active" flag (via SE19/SE20). Deactivation is a transport — plan it.

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

SE18: check the "Multiple use" flag of ME_PROCESS_PO_CUST and BADI_MATERIAL_CHECK.
SE19: list existing implementations of a multiple-use BAdI in your system.
Design a dispatcher implementation as in the code example.

✅ CHECKPOINT: you know how single- and multiple-use BAdIs behave and how to avoid implementation conflicts.

Code example

ABAP Code

* ===== One implementation per area, with explicit order inside =====CLASS zcl_im_po_dispatcher DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    INTERFACES if_ex_me_process_po_cust.ENDCLASS. CLASS zcl_im_po_dispatcher IMPLEMENTATION.  METHOD if_ex_me_process_po_cust~check.*   Order is defined HERE, not by the BAdI framework    zcl_po_rule_purchasing=>check( EXPORTING io_header = im_header                                   CHANGING  cv_failed = ch_failed ).    IF ch_failed = abap_false.      zcl_po_rule_finance=>check( EXPORTING io_header = im_header                                  CHANGING  cv_failed = ch_failed ).    ENDIF.  ENDMETHOD.ENDCLASS. * ===== Single-use BAdI with returning value (own BAdI, new technology) =====* INTERFACE zif_ex_freight_rate PUBLIC.*   INTERFACES if_badi_interface.*   METHODS get_rate IMPORTING iv_route TYPE route*                    RETURNING VALUE(rv_rate) TYPE netwr.   " allowed: single use* ENDINTERFACE.** DATA lo_badi TYPE REF TO zbadi_freight_rate.* GET BADI lo_badi.                          " exactly one implementation or fallback* lv_rate = lo_badi->get_rate( lv_route ).   " functional call via CALL BADI also possible * ===== Multiple-use: CHANGING only =====*   METHODS adjust CHANGING cs_item TYPE zs_item.   " each implementation sees the previous result

Real project scenario

Two projects implemented a multiple-use sales BAdI: one set a default shipping condition, the other changed it for export customers. After a transport in a different sequence, the default implementation ran second and overwrote the export value.
The architects merged both into one implementation per sales area with a dispatcher class that ran default first and export second. They added a register listing every implementation of shared BAdIs with owner and purpose.

Common mistakes

Relying on execution order of multiple implementations.
Two implementations changing the same field.
Creating a new implementation without checking existing ones.
Expecting return values from multiple-use BAdIs.
Activating a second implementation of a single-use BAdI.

Best practices

Check existing implementations first.
Use dispatcher implementations for defined order.
Separate responsibilities by field or filter.
Use single-use BAdIs with fallback when a value must be returned.
Maintain an owner register per BAdI.

Interview angle

Questions: "Single-use vs multiple-use BAdI?", "Execution order of multiple implementations?", "Why no EXPORTING parameters in multiple-use BAdIs?"
Strong answer: multiple-use runs all active implementations in undefined order and only allows CHANGING-type data flow; single-use allows one implementation (or fallback) and can return values; avoid conflicts with dispatcher implementations and clear responsibilities; check existing implementations and governance.

Practice this lesson

Quick check

1. Two implementations of a multiple-use BAdI change the same CHANGING field. What is the result?

2. When a BAdI definition is marked as 'multiple use', what does this setting actually control?

3. Multi-use BAdIs allow:

Interview questions

1. A delivery field was changed twice during save by two implementations of a multiple-use BAdI, with inconsistent results. How do you resolve it?

Answer it in your own words first, then compare.

2. BAdI CHANGING parameter is not reflected in caller. Why?

Answer it in your own words first, then compare.

Practice more with Interview AI →

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.