ABAP Developmentadvanced

BAdI Part 10: BAdIs in S/4HANA and Clean Core

Key takeaway

See how BAdIs fit clean core: released BAdIs for developer extensibility, Custom Logic app for key user extensibility, BAdIs in RAP business objects, what happens to classic BAdI implementations after conversion, and ATC checks for cloud readiness.

Explanation

📌 KEY POINTS
✅ BAdIs remain SAP's main extension point in S/4HANA — but for clean core, use BAdIs released for key user or cloud development.
✅ Key user extensibility: the Custom Logic app implements released BAdIs in the browser with restricted ABAP.
✅ Developer extensibility: implement released BAdIs in ADT with ABAP for Cloud Development, using only released APIs inside.
⚠️ Existing classic BAdI implementations often keep working in S/4HANA on-premise, but they may use unreleased objects and are tier 3 until reworked.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–9 used BAdIs in the classic way. In S/4HANA the same concept continues with stricter rules.

━━━━━━━━━━━━━━━━━━━━
▶ 1. RELEASED BADIS

SAP marks BAdIs as released for key user extensibility and/or cloud development (API state).
In ADT, the "Released Objects" tree or the API state tab shows this.
Released BAdIs have stable interfaces — upgrade-safe.

━━━━━━━━━━━━━━━━━━━━
▶ 2. KEY USER: CUSTOM LOGIC APP

Business contexts (e.g. sales document) offer BAdIs for validations, defaults and field logic.
Code editor in the browser, restricted language scope, test function, publish.
Good for simple rules; no transports in the classic sense (adaptation transport).

━━━━━━━━━━━━━━━━━━━━
▶ 3. DEVELOPER EXTENSIBILITY

Create the BAdI implementation in ADT in a package with ABAP language version "ABAP for Cloud Development".
Inside: only released CDS views, classes and APIs; unreleased needs → tier 2 wrapper.
Unit tests and ATC cloud checks.

━━━━━━━━━━━━━━━━━━━━
▶ 4. RAP AND BADIS

SAP's RAP business objects offer released BAdIs or extension points for determinations/validations of standard objects.
Your own RAP objects usually don't need BAdIs internally — but you can define BAdIs to let others extend them.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CONVERSION FROM ECC

Custom code migration (ATC) lists classic BAdI implementations using changed tables or objects.
Many SAP BAdIs still exist; some are replaced (e.g. by new BAdIs for the S/4HANA data model).
Classify: keep as tier 3, migrate to a released BAdI, or replace with standard/key user extensibility.

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

In ADT, search released BAdIs for your application area.
Open the Custom Logic app (or its documentation) for sales documents and list available BAdIs.
Review one classic implementation in your system: which unreleased objects does it use?

✅ CHECKPOINT: you can choose between classic, released developer and key user BAdI implementations in S/4HANA.

Code example

ABAP Code

* ===== Classic implementation in ECC (tier 3 in S/4HANA) =====* METHOD if_ex_badi_material_check~check_data.*   SELECT SINGLE * FROM mara INTO ls_mara WHERE matnr = wmara-matnr.  " direct table access*   ...* ENDMETHOD. * ===== Developer extensibility (ABAP for Cloud Development) - structure =====* Package language version: ABAP for Cloud Development* Implementation of a RELEASED BAdI (name from ADT released-objects view)CLASS zcl_bi_product_check DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    INTERFACES if_badi_interface.*   INTERFACES <released_badi_interface>.    METHODS check_product      IMPORTING iv_product_type  TYPE c                iv_product_group TYPE c      EXPORTING ev_error         TYPE abap_bool.ENDCLASS. CLASS zcl_bi_product_check IMPLEMENTATION.  METHOD check_product.*   Only released objects may be used here (released CDS views instead of MARA)    ev_error = abap_false.    IF iv_product_type = 'ZFER' AND iv_product_group IS INITIAL.      ev_error = abap_true.    ENDIF.  ENDMETHOD.ENDCLASS. * ===== Key user (Custom Logic app) - equivalent logic in the browser =====*   IF product-producttype = 'ZFER' AND product-productgroup IS INITIAL.*     " add message via the BAdI's message parameter*   ENDIF. * ===== Conversion checklist per classic implementation =====* 1. Still needed?  2. Released BAdI available?  3. Unreleased objects used?* 4. Target: key user / developer extensibility / tier 3 with plan

Real project scenario

In an S/4HANA conversion, a company had 70 classic BAdI implementations. ATC custom code checks showed 25 accessing tables changed by the simplified data model (e.g. old material ledger or customer/vendor tables replaced by business partner).
Simple validations moved to the Custom Logic app, complex ones were reimplemented as released BAdI implementations in ABAP Cloud, and 18 stayed in tier 3 with a documented plan. New requirements now require an architecture decision before any classic implementation.

Common mistakes

Assuming every classic BAdI is clean core.
Using unreleased tables in cloud-language implementations.
Ignoring key user extensibility for simple rules.
Not running ATC cloud readiness checks.
Converting implementations 1:1 without checking standard functionality.

Best practices

Prefer released BAdIs; check API state in ADT.
Use Custom Logic for simple validations/defaults.
Wrap unreleased needs in tier 2 classes.
Classify existing implementations with ATC.
Keep implementations thin and tested.

Interview angle

Questions: "How are BAdIs used in S/4HANA clean core?", "What is the Custom Logic app?", "What happens to classic BAdI implementations in a conversion?"
Strong answer: released BAdIs for key user (Custom Logic app, restricted ABAP) and developer extensibility (ABAP Cloud in ADT with released APIs only); classic implementations often still run on-premise but are tier 3; ATC custom code migration identifies issues; classify and migrate to released BAdIs or standard, wrappers for unreleased needs.

Practice this lesson

Quick check

1. Which option implements a simple sales validation in a clean-core way without ABAP development tools?

2. In ABAP for Cloud Development, what may a BAdI implementation use?

3. In clean-core S/4HANA strategy, which enhancement option is generally preferred when available?

Interview questions

1. A sales validation previously implemented as an implicit enhancement in standard code must be moved during an S/4HANA project. What target would you choose?

Answer it in your own words first, then compare.

2. Why are released BAdIs important in S/4HANA clean-core strategy?

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.