Sap S4hana Extensibility

SAP S/4HANA Extensibility & Clean Core

Related Skills

• sap-rap-comprehensive — RAP business object development and extension
• sap-security-authorization — Authorization for extensions
• sap-abap-advanced — ABAP Cloud Tier 1/Tier 2 patterns and classic-to-cloud migration
• sap-migration — S/4HANA system conversion and data migration

Quick Start

Choose your extensibility approach:

Check if your API is released:

ADT → Project Explorer → Released Objects → filter by object type
or: api.sap.com → Package S4HANACloudBADI (for Cloud BAdIs)

Core Concepts

Clean Core 4-Level Model

Target: Level A for all new development.

Extensibility Availability Matrix

Release Contracts

Check in ADT: Right-click object → Properties → API State.

Common Patterns

Pattern 1: Implement a Cloud BAdI (Developer Extensibility)

" Example: Validate Purchase Requisition
CLASS zcl_check_purch_req DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_badi_interface.
    INTERFACES if_mm_pur_s4_pr_check.
ENDCLASS.

CLASS zcl_check_purch_req IMPLEMENTATION.
  METHOD if_mm_pur_s4_pr_check~check.
    LOOP AT purchaserequisitionitem ASSIGNING FIELD-SYMBOL(<item>).
      IF <item>-PurchaseRequisitionType = 'NB'
         AND <item>-PurchasingGroup IS INITIAL.
        APPEND VALUE #(
          %tky = <item>-%tky
          %msg = new_message(
            id       = 'ZMM_PR'
            number   = '001'
            severity = if_abap_behv_message=>severity-warning )
        ) TO reported-purchaserequisitionitem.
      ENDIF.
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.

Pattern 2: Extend a CDS View Entity

" Add custom field to a released SAP CDS view
extend view entity I_PurchaseOrderItemAPI01
  with {
    pur_doc_item.YY1_CustomField as CustomField
  }

With association:

extend view entity I_SalesOrder
  with association [0..*] to ZI_CustomData as _CustomData
    on $projection.SalesOrder = _CustomData.SalesOrder
  {
    _CustomData
  }

Prerequisite: Target CDS must have @AbapCatalog.viewEnhancementCategory: [#PROJECTION_LIST].

Pattern 3: Extend RAP BO Behavior

extend behavior for I_PurchaseOrderTP {
  determination SetCustomDefault on modify { field PurchaseOrderType; }
  validation ValidateCustomField on save { field YY1_CustomField; }
}

Pattern 4: Tier 2 Wrapper (Classic API → ABAP Cloud)

When a released API doesn't exist for a needed classic function:

" Step 1: Interface (released with C1)
INTERFACE zif_po_create PUBLIC.
  METHODS create_po
    IMPORTING is_header TYPE bapimepoheader
    EXPORTING es_result TYPE bapimepoheaderx
    RAISING   zcx_po_error.
ENDINTERFACE.

" Step 2: Factory (released with C1)
CLASS zcl_po_create_factory DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    CLASS-METHODS get_instance
      RETURNING VALUE(ro_instance) TYPE REF TO zif_po_create.
ENDCLASS.

" Step 3: Implementation (NOT released — classic ABAP, calls BAPI)
CLASS zcl_po_create_impl DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_po_create.
ENDCLASS.

CLASS zcl_po_create_impl IMPLEMENTATION.
  METHOD zif_po_create~create_po.
    CALL FUNCTION 'BAPI_PO_CREATE1'
      EXPORTING poheader = is_header
      IMPORTING expheader = es_result.
    " ... error handling ...
  ENDMETHOD.
ENDCLASS.

Key: Release the interface and factory with C1. The implementation stays unreleased (Tier 2).

Pattern 5: Custom Business Object (Key-User)

1. Open Fiori app Custom Business Objects
2. Name: YY1_ProjectTracker, fields: ProjectID, Name, Status, StartDate
3. Check UI Generation for auto-generated Fiori maintenance app
4. Add logic: After Modification → Determination (auto-set defaults)
5. Add logic: Before Save → Validation (mandatory field checks)
6. Publish → OData API auto-generated at /sap/opu/odata/sap/YY1_PROJECTTRACKER_CDS/

Error Catalog

Performance Tips

• Run ATC cloud readiness checks early and often (variant: ABAP_CLOUD_READINESS)
• Keep wrapper classes thin — only translate parameters, don't add business logic
• Use EXTEND VIEW ENTITY (new syntax), not deprecated EXTEND VIEW
• Prefer CBO for simple master data; use RAP BO for complex scenarios
• Side-by-side extensions: cache API responses to reduce round-trips to S/4HANA

Bundled Resources

Read these files on demand for deeper guidance:

Gotchas

• Cloud vs. on-premise BAdIs: Cloud BAdIs (released for ABAP Cloud) are NOT the same as classic BAdIs — different registration, different lifecycle
• Released API stability: C1-released APIs guarantee backward compatibility; C0 can change with any upgrade — always check release contract
• Key User extensibility limits: Custom fields added via Key User tools have a maximum count per business object (~50) — plan ahead
• CBO naming: Custom Business Objects created via Key User tools get auto-generated technical names (YY1_*) that cannot be changed later
• Side-by-side latency: BTP extensions calling S/4HANA APIs add network latency — design for async where possible
• Tier 2 wrapper trap: Creating too many Tier 2 wrappers defeats Clean Core purpose — prefer released alternatives first
• Extension stability: In-app extensions survive upgrades; classic modifications (user exits) may break — always prefer in-app or side-by-side

Validation Workflow

Before committing extension code, run Clean Core compliance check:

bash scripts/check-clean-core.sh ./src

Checklist before release:

• No direct access to SAP standard tables (use CDS views/APIs)
• No non-released function modules (check Cloudification Repository)
• All CDS views have @AccessControl annotations
• BAdI implementations use released interfaces only
• Extension is covered by at least one unit test

Source Documentation

• SAP Extensibility Explorer
• SAP API Business Hub — Cloud BAdIs
• GitHub: SAP ATC Cloud Readiness Checks
• GitHub: RAP Tier 2 Wrapper Workshop
• GitHub: RAP Developer Extensibility
• SAP Help: ABAP Cloud Language Version