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:

| Need | Approach | Who | |------|----------|-----| | Add field to standard object | Key-User: Custom Fields app (F1481) | Consultant | | Add validation/defaulting logic | Key-User: Custom Logic app (F6957) or Developer: Cloud BAdI in ADT | Consultant/Developer | | New standalone business object | Key-User: Custom Business Objects app or Developer: RAP BO | Consultant/Developer | | Complex app on BTP | Side-by-Side: CAP/Fiori on BTP via released APIs | Developer | | Extend CDS view with custom field | Developer: EXTEND VIEW ENTITY in ADT | Developer | | Extend RAP BO behavior | Developer: extend behavior for in ADT | Developer |

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

| Level | Name | What's Allowed | Upgrade Safety | |-------|------|----------------|----------------| | A | Fully Compliant | Released APIs only (C0/C1/C2), ABAP Cloud | Fully safe | | B | Compliant | Level A + classic APIs (BAPIs, standard BAdIs) | Generally safe | | C | Partially Compliant | SAP internal objects, unrestricted ABAP | Risk of breakage | | D | Non-Compliant | Modifications, direct table writes, implicit enhancements | High risk |

Target: Level A for all new development.

Extensibility Availability Matrix

| Type | Public Cloud | Private Cloud | On-Premise | |------|-------------|---------------|------------| | Key-User (In-App) | Yes | Yes | Yes (limited) | | Developer (ABAP Cloud) | Yes | Yes | Yes (2022+) | | Side-by-Side (BTP) | Yes | Yes | Yes | | Classic ABAP (unrestricted) | No | Yes | Yes | | SAP GUI (SE80, SE38...) | No | Yes | Yes | | Code modifications | No | No | Yes (discouraged) |

Release Contracts

| Contract | Name | Use | |----------|------|-----| | C0 | Extensibility | CDS extend, BAdI implement | | C1 | System-Internal | On-stack consumption (classes, interfaces, CDS) | | C2 | Remote API | External consumption (OData, SOAP, RFC) | | C3 | Key-User Apps | Custom Fields, Custom Logic apps |

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().
      IF -PurchaseRequisitionType = 'NB'
         AND -PurchasingGroup IS INITIAL.
        APPEND VALUE #(
          %tky = -%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

| Error | Cause | Fix | |-------|-------|-----| | "Not released for ABAP Cloud" | Calling unreleased API from Tier 1 | Find released successor or create Tier 2 wrapper | | "Object type not available" | Using classic types (FM, include) in ABAP Cloud | Refactor to class-based approach | | "View entity does not allow extensions" | Missing @AbapCatalog.viewEnhancementCategory | CDS view is not extensible; check api.sap.com | | "BAdI implementation will not be called" | Filter mismatch or not activated | Check enhancement implementation activation and filter values | | "No released successor found" | Classic API has no cloud equivalent | Check nominated APIs; create Tier 2 wrapper; log SAP influence request | | "Enhancement implementation exists" | Duplicate name | Use unique Z-namespaced names | | "Transport failed" for CBO | Not assigned to transport request | Check Extensibility Inventory app | | ATC: "Incompatible change detected" | Breaking change in custom code | Review ATC findings; use Quick Fix in ADT | | "Maximum fields exceeded" on CBO | CBO field count limit reached | Split into header/item structure | | "Association target not published" | Target CBO not yet published | Publish target CBO first |

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:

| File | When to Read | |------|-------------| | references/clean-core-levels.md | Deep dive on 4-level model with migration guidance | | references/cloud-badi-catalog.md | Finding and implementing released Cloud BAdIs | | references/tier2-wrapper-guide.md | Step-by-step wrapper pattern with full examples | | references/cbo-guide.md | Custom Business Objects creation and integration | | references/cds-extension-patterns.md | All CDS view extension patterns | | templates/badi-implementation.abap | Cloud BAdI implementation template | | templates/tier2-wrapper.abap | Tier 2 wrapper class template | | templates/cds-extend.cds | CDS view extension template |

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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: efeumutaslan
• Source: efeumutaslan/SAP-SKILLS
• License: MIT

Install and usage instructions live in the source repository linked above.