Embedded Extensions (Tier 2)
In-system S/4HANA extensions using SAP-released extension points — BAdIs, Custom Fields, Custom Business Objects, and SSCUI configuration. Everything you need to extend S/4HANA without modifying standard code.
Tier 2 Embedded Extension Architecture
Tier 2 extensions run inside S/4HANA but exclusively through released extension points. SAP Standard code (Tier 1) is never modified — only extended through the published extension API surface.
Executive Summary
Key User vs Developer Extensions
| Dimension | Key User (No-code) | Developer (ABAP Cloud) |
|---|---|---|
| Tooling | Fiori apps (F1481, F1731) | ADT (Eclipse) / SAP BAS |
| Language | No code / decision tables | ABAP Cloud (restricted) |
| Upgrade safety | Full (SAP-managed) | Full (API contract C1) |
| Complexity limit | Simple fields, validations | Complex business logic |
| Transport | Customising transport | ABAP transport (Workbench) |
| Suitable for | Business consultants | ABAP developers |
| Examples | Custom field on SalesOrder | BAdI for pricing logic |
Key User Extension Points
Add fields to standard BOs (Sales Order, PO, Customer, etc.). Fields appear automatically in Fiori UIs and are exposed in the standard OData V4 API. Supports validation logic via a guided rule builder. Naming convention: YY1_ prefix.
Create complete new transactional objects (header + item structure, draft workflow, OData service). Auto-generated Fiori Elements app. No ABAP coding — fully guided UI generator. Supports associations to standard objects.
Decision-table-based logic for pricing, routing, and approval thresholds. Maintained by business users directly — no transport required for rule changes. Can be called from BAdIs, workflow steps, or directly from process code.
Fiori-based SPRO replacement. Scoped configuration by business process area. Role-based access so different users see only their relevant configuration activities. All changes tracked in Cloud ALM.
Developer Extension Points (ABAP Cloud)
SAP-published switch points where customer code injects logic. The implementing class must use ABAP Cloud language version. BAdI interface is C1-released — guaranteed stable across upgrades.
Source code exit points published by SAP. Implemented via Enhancement Implementation Objects. Only enhancements in the released enhancement catalog are permitted in ABAP Cloud.
Extend standard RAP business objects by adding custom validations, determinations, and actions to the standard BO behaviour definition. Fully integrated with the RAP framework lifecycle.
BAdI Implementation Example
A released BAdI implementation for Sales Order item creation. The implementing class uses ABAP Cloud language version — direct database access is forbidden; only released CDS views and BAPI/EML entities are used.
" Implementing a released BAdI — SD_DOC_ITEM_CREATE
" This BAdI fires when a Sales Order item is created
CLASS zcl_dewa_so_item_badi DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_badi_so_item_create. " Released BAdI interface
PRIVATE SECTION.
METHODS validate_item_data
IMPORTING is_item TYPE badi_so_item_data
RAISING cx_badi_validation_error.
ENDCLASS.
CLASS zcl_dewa_so_item_badi IMPLEMENTATION.
METHOD if_badi_so_item_create~check_item.
" Called for every new sales order item
" Only ABAP Cloud language version allowed here
" Validate DEWA-specific business rule: items above AED 1M need approval flag
IF is_item-net_value > 1000000 AND is_item-currency = 'AED'.
IF is_item-yy1_approval_required_sdh IS INITIAL.
" Set custom field (defined via Custom Fields F1481)
MODIFY ENTITIES OF i_salesorderitem_api01
ENTITY salesorderitem
UPDATE FIELDS ( yy1_approval_required_sdh )
WITH VALUE #( (
%key-salesorder = is_item-salesorder
%key-salesorderitem = is_item-salesorderitem
yy1_approval_required_sdh = abap_true
) ).
ENDIF.
ENDIF.
ENDMETHOD.
ENDCLASS.Enterprise Example: DEWA Order-to-Cash Tier 2 Extensions
- Total Tier 2 extensions implemented
- 14
- Custom Fields
- 6 — Sales Order, Customer, Delivery
- Custom Business Objects
- 2 — DEWA approval objects
- Released BAdIs
- 4 — Pricing, shipping, billing, credit check
- Business Rules
- 2 — Customer routing and classification
- ATC status
- All 14 extensions ATC-clean
- Upgrade rework (2025 OP)
- Zero — all extensions survived unchanged
Best Practices
Always check SAP's released BAdI catalog before building a side-by-side extension — an existing BAdI is faster to build and simpler to maintain.
If the business requirement fits Key User tools, use them — they are faster to build and fully upgrade-safe with zero developer involvement.
Set ABAP Cloud language version on ALL new development objects from the first day of the project — retrofitting is painful and error-prone.
Implement BAdIs in single-purpose classes (one BAdI per class, not "God classes" implementing five BAdIs). Easier to test, debug, and transport independently.
Register every BAdI implementation in Cloud ALM with its business rationale — prevents accidental deletion and helps future developers understand why it exists.