---
# === IDENTITY ===
id: business/erp-integration/sap-clean-core-extensibility/2026
canonical_question: "What is SAP Clean Core - Tier 1/2/3 extensibility model, ABAP Cloud, BTP side-by-side extensions?"
aliases:
  - "SAP Clean Core extensibility levels A B C D explained"
  - "ABAP Cloud vs classic ABAP extensibility"
  - "SAP BTP side-by-side vs on-stack extensions"
  - "SAP S/4HANA custom code clean core compliance"
entity_type: erp_integration
domain: business > erp-integration > SAP Clean Core Extensibility
region: global
jurisdiction: global
temporal_scope: 2024-2026

# === SYSTEM PROFILE ===
systems:
  - name: "SAP S/4HANA"
    vendor: "SAP"
    version: "2025 / 2408"
    edition: "Cloud Public, Cloud Private, On-Premise"
    deployment: "hybrid"
    api_surface: "OData, ABAP Cloud, BTP CAP"

# === VERIFICATION ===
last_verified: 2026-03-02
confidence: 0.92
version: 1.0
first_published: 2026-03-01

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "2025-08 — 3-tier model replaced with A-D clean core levels"
  next_review: 2026-08-29
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "ABAP Cloud language version restricts syntax to a defined subset — no classic dynpro, no direct SAP table writes"
  - "Only released APIs (from SAP API Business Hub / Cloudification Repository) may be used in Level A extensions"
  - "Wrappers for unreleased APIs (old Tier 2 pattern) now classified as Level B — not fully clean-core compliant"
  - "Level D extensions (modifications, implicit enhancements, NoAPI objects) may be blocked from transport in CI/CD pipelines"
  - "SAP S/4HANA Cloud Public Edition permits only Level A (on-stack key user + developer extensibility via released APIs)"
  - "BTP side-by-side extensions require separate BTP licensing — not included in base S/4HANA license"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "Need specific OData API capabilities and rate limits for S/4HANA"
    use_instead: "business/erp-integration/sap-s4hana-odata-api-capabilities/2026"
  - condition: "Need BAPI/RFC/IDoc integration patterns for classic SAP"
    use_instead: "business/erp-integration/sap-bapi-rfc-integration/2026"
  - condition: "Need SAP Integration Suite middleware capabilities"
    use_instead: "business/erp-integration/sap-integration-suite-capabilities/2026"
  - condition: "Need SAP authentication methods (OAuth, X.509, SAP Logon)"
    use_instead: "business/erp-integration/sap-authentication-methods/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: deployment_model
    question: "Which SAP deployment model are you using?"
    type: choice
    options:
      - "S/4HANA Cloud Public Edition"
      - "S/4HANA Cloud Private Edition"
      - "S/4HANA On-Premise"
      - "ECC (pre-S/4HANA)"
  - key: extension_type
    question: "What type of extension do you need?"
    type: choice
    options:
      - "Key user configuration (custom fields, logic, forms)"
      - "Developer on-stack extension (ABAP Cloud)"
      - "Side-by-side extension (BTP)"
      - "Migrating existing classic ABAP custom code"
  - key: clean_core_goal
    question: "What is your primary clean core objective?"
    type: choice
    options:
      - "Assess existing custom code compliance"
      - "Build new extensions clean-core compliant"
      - "Migrate existing extensions to clean core"
      - "Understand governance and ATC setup"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/erp-integration/sap-clean-core-extensibility/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-02)"

# === RELATED UNITS ===
related_kos:
  depends_on:
    - id: "business/erp-integration/sap-authentication-methods/2026"
      label: "SAP Authentication Methods — required for BTP and API access"
  related_to:
    - id: "business/erp-integration/sap-s4hana-odata-api-capabilities/2026"
      label: "SAP S/4HANA OData API — the released API surface for clean core"
    - id: "business/erp-integration/sap-event-mesh-capabilities/2026"
      label: "SAP Event Mesh — async event-driven extensions on BTP"
    - id: "business/erp-integration/sap-integration-suite-capabilities/2026"
      label: "SAP Integration Suite — iPaaS for side-by-side integration"
  alternative_to:
    - id: "business/erp-integration/sap-bapi-rfc-integration/2026"
      label: "SAP BAPI/RFC Integration — classic (Level B/C) extension approach"
    - id: "business/erp-integration/sap-idoc-edi-integration/2026"
      label: "SAP IDoc/EDI — classic interface (Level B in new model)"
  often_confused_with:
    - id: "business/erp-integration/sap-ecc-vs-s4hana-integration/2026"
      label: "SAP ECC vs S/4HANA — clean core applies only to S/4HANA"

# === SOURCES (7 authoritative sources) ===
sources:
  - id: src1
    title: "ABAP Extensibility Guide - Clean Core for SAP S/4HANA Cloud (August 2025 Update)"
    author: SAP
    url: https://community.sap.com/t5/technology-blog-posts-by-sap/abap-extensibility-guide-clean-core-for-sap-s-4hana-cloud-august-2025/ba-p/14175399
    type: official_docs
    published: 2025-08-15
    reliability: authoritative
  - id: src2
    title: "S/4HANA Clean Core Update 2025: How the New A-D Extensibility Model Works"
    author: Avotechs
    url: https://avotechs.com/blog/what-is-clean-core-a-d-extensibility-model/
    type: technical_blog
    published: 2025-09-01
    reliability: high
  - id: src3
    title: "How to Extend SAP S/4HANA Cloud the Right Way - Clean and Clear"
    author: SAP
    url: https://news.sap.com/2025/08/extend-sap-s4hana-cloud-right-way-clean-clear/
    type: official_docs
    published: 2025-08-20
    reliability: authoritative
  - id: src4
    title: "SAP S/4HANA Clean Core: Principles, Benefits, and Best Practices"
    author: SAP Press
    url: https://blog.sap-press.com/sap-s4hana-clean-core-principles-benefits-and-best-practices
    type: technical_blog
    published: 2025-06-01
    reliability: high
  - id: src5
    title: "ABAP Test Cockpit (ATC) Recommendations for Governance of Clean Core ABAP Development"
    author: SAP
    url: https://community.sap.com/t5/technology-blog-posts-by-sap/abap-test-cockpit-atc-recommendations-for-governance-of-clean-core-abap/ba-p/14186130
    type: official_docs
    published: 2025-08-20
    reliability: authoritative
  - id: src6
    title: "SAP S/4HANA Extensibility Options for Clean Core Journey"
    author: SAP
    url: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-s-4hana-extensibility-options-for-clean-core-journey/ba-p/13568992
    type: official_docs
    published: 2024-06-15
    reliability: authoritative
  - id: src7
    title: "Cloudification Repository - ABAP ATC Cloud Readiness Check Variants (GitHub)"
    author: SAP
    url: https://github.com/SAP/abap-atc-cr-cv-s4hc
    type: official_docs
    published: 2025-01-01
    reliability: authoritative
---

# SAP Clean Core Extensibility: Tier Model, ABAP Cloud, and BTP Side-by-Side Extensions

## TL;DR

- **Bottom line**: SAP Clean Core is a governance framework that classifies all S/4HANA extensions into four compliance levels (A-D). Level A (released APIs only, ABAP Cloud or BTP) is the only fully clean approach; the old 3-tier model (Tier 1/2/3) was replaced by this A-D system in August 2025. [src1]
- **Key limit**: S/4HANA Cloud Public Edition only allows Level A extensions -- no classic ABAP, no unreleased APIs, no modifications. Private Edition and On-Premise allow Levels A-D but only A is "clean." [src3]
- **Watch out for**: The old Tier 2 "wrapper" pattern (wrapping unreleased SAP objects in standard ABAP and releasing for ABAP Cloud) is now classified as Level B -- technically stable but not fully clean-core compliant. [src1, src2]
- **Best for**: Any organization planning S/4HANA cloud migration, custom code remediation, or new extension development that needs to remain upgrade-safe. [src4]
- **Authentication**: BTP side-by-side extensions use OAuth 2.0 (SAML assertion or client credentials) via SAP BTP Destination Service; on-stack ABAP Cloud uses system communication arrangements. [src6]

## System Profile

SAP Clean Core is not a single API or product -- it is a strategic framework and governance model that spans all SAP S/4HANA editions (Cloud Public, Cloud Private, and On-Premise). The framework defines how custom extensions, integrations, and configurations should be built to keep the ERP core standard, upgrade-safe, and cloud-ready. It applies to all ABAP custom code, BTP extensions, key user configurations, and integration interfaces. [src4]

The extensibility model covers six dimensions: clean processes, clean extensions, clean data, clean integration, clean operations, and clean software stack. This card focuses on the **clean extensions** dimension -- specifically the evolution from the 3-tier model to the A-D clean core level concept. [src4]

| Property | Value |
|---|---|
| **Vendor** | SAP |
| **System** | SAP S/4HANA (2025 / 2408) |
| **API Surface** | OData v2/v4, ABAP Cloud, BTP CAP (Node.js / Java) |
| **Framework Version** | Clean Core Level Concept (replaces 3-Tier, August 2025) |
| **Editions Covered** | Cloud Public, Cloud Private, On-Premise |
| **Deployment** | Cloud / On-Premise / Hybrid |
| **API Docs URL** | [SAP API Business Hub](https://api.sap.com/) |
| **Status** | GA (evolved from 3-Tier to A-D in 2025) |

## API Surfaces & Capabilities

SAP Clean Core defines multiple extension surfaces, each with different clean core compliance implications. The fundamental principle is: extensions must access SAP business objects only through well-defined, upgrade-stable interfaces. [src3]

| Extension Surface | Technology | Clean Core Level | Best For | Deployment | Upgrade-Safe? | Cloud Public? |
|---|---|---|---|---|---|---|
| Key User Extensibility | Custom Fields & Logic, SAP Build | A | Simple field additions, validations, form adaptations | On-stack | Yes | Yes |
| Developer On-Stack (ABAP Cloud) | ABAP Cloud (restricted language version) | A | Complex business logic using released APIs only | On-stack | Yes | Yes |
| Side-by-Side (BTP CAP) | CAP (Node.js/Java), SAP Build Apps | A | Independent apps, AI/ML, cross-system orchestration | BTP | Yes | Yes |
| Classic ABAP (released BAPIs/RFCs) | BAPIs, IDocs, RFCs, batch jobs | B | Legacy-compatible, stable but not cloud-ready | On-stack | Mostly | No |
| Classic ABAP (unreleased objects) | Internal SAP objects, archiving frameworks | C | Legacy gap-filling, data management | On-stack | Risky | No |
| Modifications / direct table writes | SAP standard modifications, implicit enhancements | D | Never recommended | On-stack | No | No |

[src1, src2, src3]

## Rate Limits & Quotas

Clean Core does not define traditional API rate limits like SaaS platforms. Instead, the constraints are governance-based: what you are allowed to develop, and what the ATC (ABAP Test Cockpit) will permit through transport pipelines. [src5]

### ABAP Cloud Language Restrictions

| Restriction | ABAP Cloud (Level A) | Classic ABAP (Level B-D) | Notes |
|---|---|---|---|
| **Allowed syntax** | Restricted subset (no dynpro, no classic reports, no direct DB writes) | Full ABAP syntax | ABAP Cloud enforces at compile time [src1] |
| **Object access** | Released APIs only (SAP API Business Hub / Cloudification Repository) | Any SAP object | ~25,000+ released objects as of 2025 [src7] |
| **Database access** | CDS views and released ABAP SQL only | Direct table reads/writes | No SELECT on SAP tables in ABAP Cloud [src1] |
| **UI technology** | SAP Fiori / SAPUI5 (via RAP) | Classic dynpro, SAP GUI, Web Dynpro | Classic UIs are Level C/D [src2] |
| **Enhancement technique** | BAdIs (released) only | BAdIs, enhancements, modifications, user exits | Only released BAdIs qualify for Level A [src1] |

### ATC Governance Thresholds

| ATC Check Variant | Purpose | Level A Finding | Level B Finding | Level C Finding | Level D Finding |
|---|---|---|---|---|---|
| CLOUD_READINESS | Primary clean core assessment | No findings | Informational messages | Warnings | Errors (may block transport) |
| S4HANA_READINESS | Legacy ECC pattern detection | N/A | N/A | Warnings | Errors |
| ABAP_CLEAN_CORE_READINESS | Comprehensive (BTP 2605+) | No findings | Informational | Warnings | Errors (blocking) |

[src2, src5]

## Authentication

Authentication differs significantly between on-stack and side-by-side extension patterns. [src6]

| Flow | Use When | Technology | Level | Notes |
|---|---|---|---|---|
| Communication Arrangement | On-stack ABAP Cloud calling external systems | SAP Communication Management | A | Standard for on-stack outbound calls |
| OAuth 2.0 Client Credentials | BTP side-by-side calling S/4HANA APIs | SAP BTP Destination Service | A | Recommended for server-to-server |
| OAuth 2.0 SAML Assertion | BTP extension with user context propagation | SAP BTP + IAS/IPS | A | Preserves user identity across systems |
| Principal Propagation | BTP app needs S/4HANA user authorization | SAP Cloud Connector + BTP | A | Required when on-premise |
| RFC Trust (SM59) | Classic system-to-system communication | RFC Destinations | B | Stable but not cloud-ready |

[src6]

### Authentication Gotchas

- BTP side-by-side extensions to S/4HANA Cloud Public Edition must use Communication Arrangements -- direct RFC/HTTP destinations are not available. [src6]
- Principal propagation through SAP Cloud Connector requires matching user stores (IAS/IPS sync) -- mismatched users silently fail authorization checks. [src6]
- OAuth tokens from BTP Destination Service have configurable lifetimes, but the destination configuration caches tokens -- changing token lifetime requires destination recreation or cache flush. [src3]

## Constraints
<!-- Agents: read this section before recommending any extension approach from this unit.
     These are hard constraints that must not be violated. -->

- **Cloud Public Edition is Level A only**: No classic ABAP development, no unreleased API access, no modifications. All extensions must use key user tools, ABAP Cloud (restricted language), or BTP side-by-side. [src3]
- **ABAP Cloud restricts language syntax**: No dynpro, no classic reports (WRITE), no direct SAP table access, no classic enhancements. Only released objects from the Cloudification Repository are accessible. [src1]
- **Wrappers for unreleased APIs are Level B**: The old Tier 2 pattern of wrapping unreleased objects in Standard ABAP and releasing them for ABAP Cloud is now Level B -- technically stable but not fully clean. Wrappers should be replaced when SAP releases the official API. [src1, src2]
- **ATC can block transports**: Level D findings (modifications, NoAPI objects, direct table writes) can be configured to block transport requests in CI/CD pipelines. Organizations should enforce "no new Level D code" policies. [src2, src5]
- **BTP requires separate licensing**: Side-by-side extensions on BTP are not included in the base S/4HANA license. BTP credits (CPEA or subscription) must be purchased separately. [src3]
- **Released API coverage is incomplete**: Not all SAP business objects have released APIs yet. The Cloudification Repository (GitHub) tracks ~25,000+ released objects, but gaps exist -- especially in industry solutions, complex logistics, and finance sub-modules. [src7]
- **ECC systems cannot be clean core**: Clean Core applies only to S/4HANA. ECC customers must first migrate to S/4HANA, then remediate custom code. [src4]

## Integration Pattern Decision Tree

```
START -- Organization wants clean core compliant extensions for SAP S/4HANA
|
+-- Which S/4HANA edition?
|   +-- Cloud Public Edition
|   |   +-- Only Level A allowed
|   |   +-- Key user extension? (custom fields, logic, forms)
|   |   |   +-- YES --> Custom Fields & Logic app, SAP Build Process Automation
|   |   |   +-- NO  --> Developer extension needed?
|   |   |       +-- On-stack logic, tight ERP integration --> ABAP Cloud (RAP, released BAdIs)
|   |   |       +-- Independent app, AI/ML, cross-system --> BTP side-by-side (CAP)
|   |   |       +-- Low-code workflow/app --> SAP Build Apps / Process Automation
|   |
|   +-- Cloud Private Edition or On-Premise
|       +-- New development?
|       |   +-- YES --> Target Level A (ABAP Cloud or BTP)
|       |   +-- NO  --> Existing custom code?
|       |       +-- Run ATC CLOUD_READINESS check
|       |       +-- Level A findings? --> Already clean, maintain
|       |       +-- Level B findings? --> Stable but plan migration to released APIs
|       |       +-- Level C findings? --> Monitor via Simplification Database, plan remediation
|       |       +-- Level D findings? --> Remediate immediately (highest risk)
|
+-- What type of extension?
|   +-- Simple configuration (fields, validations)
|   |   --> Key User Extensibility (Level A, no coding)
|   +-- Complex business logic, tight ERP coupling
|   |   --> ABAP Cloud on-stack (Level A) -- use released APIs/BAdIs only
|   |   --> If released API missing: use wrapper (Level B) + log gap for SAP
|   +-- Independent application, UI, or process
|   |   --> BTP side-by-side with CAP (Level A)
|   +-- AI/ML, advanced analytics, cross-system orchestration
|   |   --> BTP side-by-side (Level A) + SAP AI Core / HANA Cloud
|   +-- Legacy interface maintenance
|       --> Classify with ATC, plan migration path, target Level A
|
+-- Custom code migration (ECC or classic S/4HANA)?
    +-- Step 1: Run Custom Code Migration app (Fiori) against ECC/S/4HANA source
    +-- Step 2: Analyze ATC findings by clean core level (A/B/C/D)
    +-- Step 3: Prioritize -- eliminate Level D first, then C, then B
    +-- Step 4: For each finding, decide: keep + wrap (Level B) vs. rewrite (Level A) vs. retire
    +-- Step 5: New development in ABAP Cloud only
```

[src1, src2, src3, src4]

## Quick Reference

### Clean Core Levels at a Glance

| Level | Compliance | Technologies | ATC Finding | Upgrade Risk | Cloud Public? | Recommended? |
|---|---|---|---|---|---|---|
| **A** | Fully compliant | ABAP Cloud, BTP/CAP, SAP Build, Key User Tools | None | None | Yes | Yes -- target for all new development |
| **B** | Conditionally compliant | BAPIs, IDocs, RFCs, released-but-classic APIs | Informational | Low | No | Acceptable for existing code, plan migration |
| **C** | Partially compliant | Unreleased SAP objects, archiving (ADK/ILM), TAANA | Warnings | Medium | No | Monitor via SDB, remediate within 12 months |
| **D** | Non-compliant | Modifications, direct table writes, implicit enhancements, NoAPI | Errors (blocking) | High | No | Eliminate immediately |

[src2]

### Old 3-Tier to New A-D Mapping

| Old Model | New Model | What Changed |
|---|---|---|
| Tier 1 (ABAP Cloud on-stack + BTP side-by-side) | Level A | Same scope, renamed for clarity |
| Tier 2 (wrapper for unreleased APIs) | Level B | Downgraded -- wrappers are no longer "clean" |
| Tier 3 (classic ABAP) | Level C + D | Split into two: C (risky but manageable) vs D (prohibited) |
| No equivalent | Level B also covers | Classic APIs (BAPIs, RFCs) that are stable but not cloud-ready |

[src1, src2]

### Key User vs Developer vs Side-by-Side Extensibility

| Dimension | Key User (on-stack) | Developer (on-stack) | Side-by-Side (BTP) |
|---|---|---|---|
| **Skill required** | Business analyst | ABAP developer | Full-stack developer (Node.js/Java) |
| **Tools** | Custom Fields & Logic app, SAP Build | ABAP Development Tools (Eclipse), RAP | SAP Business Application Studio, CAP |
| **Language** | No-code / low-code | ABAP Cloud (restricted) | Node.js, Java, Python |
| **Deployment** | S/4HANA tenant | S/4HANA tenant | BTP Cloud Foundry or Kyma |
| **Data access** | Predefined extension points | Released APIs, CDS views | S/4HANA APIs via Destination Service |
| **Lifecycle** | Managed by S/4HANA upgrades | Managed by developer, ATC-validated | Independent lifecycle |
| **Best for** | Custom fields, simple validations, UI adaptations | Complex business logic, custom entities, reports | Independent apps, AI/ML, cross-system processes |
| **Clean Core Level** | A | A (if released APIs only) | A |

[src3, src6]

## Step-by-Step Integration Guide

### 1. Assess existing custom code with ATC

Run the ABAP Test Cockpit with the CLOUD_READINESS check variant to classify all custom code objects by clean core level. [src5]

```abap
" In SAP GUI: transaction ATC or SE80 > ATC
" Or via BTP ABAP Environment for remote analysis:
" 1. Configure central ATC on BTP (recommended by SAP)
" 2. Connect source S/4HANA system via RFC
" 3. Run check variant CLOUD_READINESS against Z* / Y* namespaces
" 4. Export findings report (Excel or ALV)

" ATC Check Variant setup (transaction ATC):
" - Check Variant: CLOUD_READINESS (or import from GitHub SAP/abap-atc-cr-cv-s4hc)
" - Object Provider: select custom code packages (Z*, Y*)
" - Execute and review findings by severity
```

**Verify**: ATC results show findings categorized as Informational (Level B), Warning (Level C), or Error (Level D). No findings = Level A compliant.

### 2. Build an on-stack ABAP Cloud extension (Level A)

Create a new development object using ABAP Cloud language version. Only released APIs are accessible. [src1]

```abap
" In ABAP Development Tools (Eclipse):
" 1. Create a new ABAP Package with language version "ABAP for Cloud Development"
" 2. All objects in this package are restricted to ABAP Cloud syntax

" Example: Custom CDS view consuming released API
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Custom Sales Order View'
define view entity ZI_SalesOrderCustom
  as select from I_SalesOrder  " <-- released CDS view (Level A)
{
  key SalesOrder,
      SalesOrganization,
      SoldToParty,
      TotalNetAmount,
      TransactionCurrency
}
where SalesOrganization = '1000'

" NOTE: I_SalesOrder is a released CDS view.
" If you try to access a non-released object, ATC will flag it.
```

**Verify**: ATC run on the new object shows zero findings. Object deploys without transport errors.

### 3. Create a wrapper for an unreleased API (Level B, temporary)

When a released API does not exist for your use case, create a wrapper in Standard ABAP and release it for ABAP Cloud consumption. Plan to remove the wrapper once SAP releases the official API. [src1]

```abap
" Step 1: Create wrapper class in Standard ABAP (language version: Standard)
CLASS zcl_wrapper_example DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    " Release this class for ABAP Cloud: Properties > API State > Released
    CLASS-METHODS get_material_data
      IMPORTING iv_matnr       TYPE matnr
      RETURNING VALUE(rs_data) TYPE mara.  " direct table type -- Level B
ENDCLASS.

CLASS zcl_wrapper_example IMPLEMENTATION.
  METHOD get_material_data.
    SELECT SINGLE * FROM mara INTO rs_data WHERE matnr = iv_matnr.
  ENDMETHOD.
ENDCLASS.

" Step 2: In ABAP Cloud code, consume the released wrapper:
" DATA(ls_material) = zcl_wrapper_example=>get_material_data( '000000001234' ).

" Step 3: Log the gap -- submit an SAP Influence request for the missing API
" Step 4: When SAP releases the API, replace wrapper with released API
```

**Verify**: ATC on the ABAP Cloud consumer shows Informational finding (Level B). The wrapper class shows no findings because it is Standard ABAP.

### 4. Build a BTP side-by-side extension with CAP

Create an independent application on SAP BTP that connects to S/4HANA via APIs. [src3, src6]

```bash
# Prerequisites: Node.js 18+, SAP BTP account, Cloud Foundry CLI

# 1. Scaffold a CAP project
npm init -y
npm add @sap/cds @sap/cds-dk
npx cds init my-extension --add hana,approuter

# 2. Define a service that consumes S/4HANA API
cd my-extension
# In srv/external/, import the S/4HANA OData service definition:
npx cds import API_SALES_ORDER_SRV.edmx --as external

# 3. Create a service definition (srv/service.cds)
cat > srv/service.cds << 'EOF'
using {API_SALES_ORDER_SRV as S4} from './external/API_SALES_ORDER_SRV';

service MyExtensionService {
  entity SalesOrders as projection on S4.A_SalesOrder {
    SalesOrder, SalesOrganization, SoldToParty, TotalNetAmount
  };
}
EOF

# 4. Configure destination in package.json for local testing
# In production: configure SAP BTP Destination Service pointing to S/4HANA

# 5. Deploy to Cloud Foundry
cf login -a https://api.cf.<region>.hana.ondemand.com
npx cds build --production
cf push
```

**Verify**: `cf apps` shows the application running. `curl https://<app-url>/odata/v4/my-extension/SalesOrders` returns sales order data from S/4HANA.

## Code Examples

### Python: Check released APIs via Cloudification Repository

```python
# Input:  GitHub Cloudification Repository JSON
# Output: List of released objects matching a search term
import requests  # requests==2.31.0

CLOUDIFICATION_REPO_URL = (
    "https://raw.githubusercontent.com/SAP/abap-atc-cr-cv-s4hc/"
    "main/src/objectReleaseInfo_s4hc2408.json"
)

def search_released_objects(search_term: str, max_results: int = 20):
    """Search SAP Cloudification Repository for released objects."""
    resp = requests.get(CLOUDIFICATION_REPO_URL, timeout=30)
    resp.raise_for_status()
    data = resp.json()

    results = []
    term_lower = search_term.lower()
    for obj in data.get("objectReleaseInfo", []):
        obj_name = obj.get("objectName", "").lower()
        if term_lower in obj_name:
            results.append({
                "name": obj.get("objectName"),
                "type": obj.get("objectType"),
                "release_state": obj.get("releaseState"),
            })
            if len(results) >= max_results:
                break
    return results

# Example: find released sales order objects
released = search_released_objects("salesorder")
for obj in released:
    print(f"  {obj['type']:10s} {obj['name']:40s} [{obj['release_state']}]")
```

### ABAP: Check if an object is released for ABAP Cloud

```abap
" Input:  Object name (class, CDS view, etc.)
" Output: Release state (released / not released / deprecated)

" Method 1: Use XCO library (available in ABAP Cloud)
DATA(lo_class) = xco_cp_abap=>class( 'CL_SOME_SAP_CLASS' ).
DATA(lv_release_state) = lo_class->content( )->get_release_state( ).
" Returns: if_xco_ar_release_state=>co_released  (or co_not_released, co_deprecated)

" Method 2: Use Cloudification Repository Viewer (Fiori app)
" App ID: F5670 - ABAP Cloud Readiness
" Shows all released objects with their API state and stability contract

" Method 3: ATC Check (most comprehensive)
" Transaction ATC > Run with CLOUD_READINESS variant > Review findings
```

### Bash: Quick check custom code volume

```bash
# Input:  SAP system connection (RFC or HTTPS)
# Output: Custom code statistics for clean core planning

# Using SAP BTP CLI to check ATC results (if central ATC is configured)
# 1. List ATC runs
cf curl /sap/opu/odata/sap/MANAGE_ATC_RUNS/ATCRuns?$top=10

# Using the Custom Code Migration Fiori app API:
# GET /sap/opu/odata/sap/MANAGE_CCM_ANALYSIS/AnalysisResults
# Returns findings count by severity (Info/Warning/Error = B/C/D)
```

## Data Mapping

### Extension Pattern to Clean Core Level Mapping

| Extension Pattern | Old Model | New Level | Migration Path | Effort |
|---|---|---|---|---|
| Custom Fiori app using released OData | Tier 1 | A | None needed | - |
| CAP app on BTP calling S/4 APIs | Tier 1 | A | None needed | - |
| Key user custom fields via Custom Fields app | Tier 1 | A | None needed | - |
| BAdI implementation (released BAdI) | Tier 1 | A | None needed | - |
| BAPI wrapper in Standard ABAP, released for Cloud | Tier 2 | B | Replace with released API when available | Low-Medium |
| Classic report (WRITE statement) on Z-table | Tier 3 | C | Rewrite as RAP-based Fiori app | High |
| User exit / customer exit | Tier 3 | C-D | Replace with released BAdI | Medium-High |
| SAP standard modification (SMOD/CMOD) | Tier 3 | D | Eliminate, use BAdI or BTP extension | High |
| Direct MODIFY on SAP table | Tier 3 | D | Eliminate, use released API | Critical |
| Implicit enhancement point | Tier 3 | D | Eliminate, use released BAdI | High |

[src1, src2]

### Data Type Gotchas

- ABAP Cloud uses strict typing -- implicit type conversions common in classic ABAP (e.g., `MOVE` between incompatible types) are not allowed. [src1]
- CDS views in ABAP Cloud expose SAP HANA types (NVARCHAR, DECIMAL) differently than classic dictionary types (CHAR, CURR). Field length mismatches between CDS view projections and classic structures can cause silent truncation. [src1]
- Released APIs may return different field names than the underlying database table columns (e.g., released CDS `I_SalesOrder.SalesOrder` vs table `VBAK-VBELN`). Always use the released API field names, not table field names. [src7]

## Error Handling & Failure Points

### Common ATC / Clean Core Errors

| ATC Message | Level | Meaning | Resolution |
|---|---|---|---|
| Use of unreleased SAP object | C | Code accesses an internal SAP object not in Cloudification Repository | Replace with released equivalent or create wrapper (Level B) [src5] |
| Use of classic ABAP statement | C | Code uses dynpro, WRITE, CALL SCREEN, etc. | Rewrite using RAP/Fiori patterns [src1] |
| Direct access to SAP database table | C-D | SELECT/MODIFY on SAP tables (VBAK, MARA, etc.) | Use released CDS views or APIs [src1] |
| Modification of SAP standard object | D | SMOD/CMOD modification, implicit enhancement | Eliminate and use BAdI/BTP extension [src2] |
| Use of NoAPI object | D | Object explicitly flagged by SAP as "do not use" | Must be removed -- no workaround [src2] |
| Obsolete ABAP statement | B-C | Code uses obsolete syntax (MOVE, COMPUTE, etc.) | Replace with modern ABAP syntax [src5] |

[src2, src5]

### Failure Points in Production

- **Custom code migration underestimates scope**: ATC findings often multiply during detailed analysis -- a 500-object assessment can reveal 5,000+ individual findings. Budget 2-3x the initial estimate for remediation effort. Fix: `Run ATC early in project planning, not during build phase.` [src5]
- **Wrapper proliferation**: Creating too many Level B wrappers creates a "shadow API" layer that is expensive to maintain and track. Fix: `Maintain a wrapper registry with SAP Influence request numbers; set quarterly review cadence to check if SAP has released the official API.` [src1]
- **BTP extension loses connectivity to S/4HANA**: Destination Service tokens expire, Cloud Connector tunnels drop, or Communication Arrangement is deactivated during S/4HANA upgrade. Fix: `Implement health check endpoints in CAP services; set up BTP Alert Notification Service for destination failures.` [src3]
- **ATC variant mismatch between dev and CI/CD**: Development system uses a different ATC check variant than the CI/CD pipeline, causing findings to appear only at transport time. Fix: `Standardize on SAP-delivered CLOUD_READINESS variant across all systems; configure in central ATC on BTP.` [src5]
- **Key user extensions break after upgrade**: Custom fields using customer logic (BRFplus rules) can reference fields that change in new S/4HANA releases. Fix: `Test key user extensions in sandbox system before production upgrade; use SAP Readiness Check.` [src6]

## Anti-Patterns

### Wrong: Wrapping every unreleased object into Level B

```abap
" BAD -- creating hundreds of wrappers to make classic code "technically" compliant
" This creates unmanageable technical debt and a shadow API layer
CLASS zcl_wrap_mara DEFINITION PUBLIC CREATE PUBLIC.
  PUBLIC SECTION.
    CLASS-METHODS get IMPORTING iv TYPE matnr RETURNING VALUE(rs) TYPE mara.
ENDCLASS.
CLASS zcl_wrap_bseg DEFINITION PUBLIC CREATE PUBLIC.
  PUBLIC SECTION.
    CLASS-METHODS get IMPORTING iv TYPE belnr_d RETURNING VALUE(rs) TYPE bseg.
ENDCLASS.
" ... 200 more wrappers ...
```

### Correct: Evaluate each gap and choose the right strategy

```abap
" GOOD -- decision tree for each unreleased object:
" 1. Does a released API exist? --> Use it (Level A)
" 2. Is the functionality still needed? --> Maybe retire the custom code
" 3. Can it be rebuilt as a BTP extension? --> Side-by-side (Level A)
" 4. No alternative exists? --> Create ONE wrapper, log SAP Influence request,
"    set review date, and document in wrapper registry

" Wrapper registry (maintain in a custom table or SharePoint):
" | Wrapper Class        | Wrapped Object | SAP Influence # | Review Date |
" | zcl_wrap_pricing     | BAPI_PRICING   | 202500123       | 2026-06-01  |
```

### Wrong: Treating Level B as permanent solution

```
" BAD -- leaving Level B wrappers indefinitely
" "It works, it's stable, why change it?"
" Because: Level B prevents Cloud Public Edition migration,
"          blocks full ABAP Cloud adoption,
"          and SAP may change internal objects without notice
```

### Correct: Level B as temporary bridge with migration plan

```
" GOOD -- every Level B wrapper has an expiry plan:
" 1. Create wrapper with clear documentation
" 2. Submit SAP Influence request for released API
" 3. Set 6-month review cadence
" 4. When released API appears: refactor, test, replace wrapper
" 5. Track progress in Clean Core Dashboard (SAP for Me)
```

### Wrong: Building new classic ABAP without checking released alternatives

```abap
" BAD -- developer creates a classic report because "that's how we always did it"
REPORT zsd_order_list.
SELECT * FROM vbak INTO TABLE @DATA(lt_orders)
  WHERE erdat >= @sy-datum - 30.
LOOP AT lt_orders INTO DATA(ls_order).
  WRITE: / ls_order-vbeln, ls_order-erdat, ls_order-netwr.
ENDLOOP.
```

### Correct: Use ABAP Cloud with RAP and released CDS views

```abap
" GOOD -- same requirement, Level A compliant
" 1. Create a CDS view consuming released I_SalesOrder
" 2. Expose via RAP service binding (OData V4)
" 3. Build Fiori Elements list report (zero UI code)

@EndUserText.label: 'Recent Sales Orders'
define view entity ZC_RecentSalesOrders
  as select from I_SalesOrder
{
  key SalesOrder,
      CreationDate,
      TotalNetAmount,
      TransactionCurrency
}
where CreationDate >= $session.system_date - 30
```

[src1, src2, src4]

## Common Pitfalls

- **Confusing "clean" with "no custom code"**: Clean Core does not mean zero customization. It means all customizations use released APIs and sanctioned extension points. Organizations that interpret Clean Core as "no extensions" lose competitive advantage. Fix: `Use the extension decision tree: key user > ABAP Cloud > BTP side-by-side, in that order of simplicity.` [src4]
- **Skipping the ATC assessment**: Starting custom code migration without running ATC first leads to uncontrolled scope. Fix: `Run ATC with CLOUD_READINESS variant on all Z*/Y* objects as the first project activity. Use the findings report to size remediation effort.` [src5]
- **Assuming all BAPIs are Level B**: Some classic BAPIs access internal objects that make them Level C. Fix: `Check each BAPI against the Cloudification Repository -- only BAPIs with "released" state are Level B.` [src7]
- **Not accounting for BTP licensing costs**: Side-by-side extensions require BTP credits (CPEA or subscription) which can add 15-30% to the total project cost. Fix: `Include BTP licensing in the business case. Use SAP Discovery Center to estimate credit consumption.` [src3]
- **Ignoring the Simplification Database (SDB)**: The SDB tracks SAP internal object changes across releases. Level C objects that change in SDB will break during upgrades. Fix: `Subscribe to SDB notifications for all Level C objects in your landscape. Plan remediation before each upgrade cycle.` [src2]
- **Building complex extensions as key user config**: Key user extensibility is designed for simple fields, validations, and forms -- not complex business logic with external callouts. Fix: `If the extension requires ABAP code, external API calls, or complex data models, use developer extensibility (ABAP Cloud) or BTP side-by-side.` [src6]

## Diagnostic Commands

```abap
" Check ATC findings for a specific package
" Transaction: ATC
" 1. Create/select check variant: CLOUD_READINESS
" 2. Object scope: Package = Z_MY_PACKAGE (including subpackages)
" 3. Execute > Review findings by priority (Error > Warning > Info)

" Check released status of a specific object
" Transaction: SE80 or ADT (Eclipse)
" Navigate to object > Properties > API State
" Released = Level A compatible
" Not Released = Level B (wrapper needed) or Level C/D (remediate)

" Check Clean Core Dashboard metrics
" SAP for Me > Clean Core Dashboard (S/4HANA Cloud Private Edition)
" Shows: custom code volume, Level A/B/C/D distribution, trend over time

" Cloudification Repository (programmatic check)
" GitHub: https://github.com/SAP/abap-atc-cr-cv-s4hc
" Download objectReleaseInfo JSON for your S/4HANA version
" Search for specific object names to confirm release state
```

```bash
# Check Cloudification Repository for a specific object (command line)
curl -s "https://raw.githubusercontent.com/SAP/abap-atc-cr-cv-s4hc/main/src/objectReleaseInfo_s4hc2408.json" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
term = 'salesorder'
for obj in data.get('objectReleaseInfo', []):
    if term.lower() in obj.get('objectName', '').lower():
        print(f\"{obj['objectType']:10s} {obj['objectName']:40s} [{obj['releaseState']}]\")
"
```

## Version History & Compatibility

| Framework Version | Date | Status | Key Changes | Migration Notes |
|---|---|---|---|---|
| A-D Clean Core Levels | 2025-08 | Current | Replaced 3-tier model; 4 levels with ATC-based governance | All Tier 2 reclassified as Level B; Tier 3 split into C + D [src1] |
| 3-Tier Extensibility Model | 2022-2025 | Superseded | Tier 1 (clean), Tier 2 (wrapper), Tier 3 (classic) | Tier 1 = Level A; Tier 2 = Level B; Tier 3 = Level C/D [src2] |
| ABAP Cloud (introduction) | 2020 | GA | Restricted ABAP language version for cloud development | Required for all Level A on-stack extensions [src1] |
| RAP (RESTful ABAP Programming) | 2020 | GA | Application framework for ABAP Cloud | Standard pattern for Level A transactional apps [src1] |
| SAP BTP Extension Suite | 2019 | GA | Side-by-side extension platform | Required for Level A side-by-side extensions [src6] |

[src1, src2]

### Deprecation Policy

SAP does not deprecate clean core levels -- they are cumulative and backward-compatible. However, SAP is progressively increasing the number of released APIs in each S/4HANA release, which means Level B wrappers can be replaced over time. SAP commits to a 2-year deprecation notice for any released API that will be removed. The Cloudification Repository on GitHub is updated with each S/4HANA release (quarterly for Cloud, annually for on-premise). [src1, src7]

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| Planning S/4HANA cloud migration and need to assess custom code | Already on S/4HANA Cloud Public with no custom ABAP | Key user extensibility tools directly |
| Building new extensions for S/4HANA (any edition) | Working with SAP ECC (pre-S/4HANA) | Migrate to S/4HANA first, then apply clean core |
| Need to classify existing custom code by upgrade risk | Need specific API rate limits and endpoints | business/erp-integration/sap-s4hana-odata-api-capabilities/2026 |
| Evaluating BTP vs on-stack extension architecture | Need BAPI/RFC technical details for a specific interface | business/erp-integration/sap-bapi-rfc-integration/2026 |
| Setting up ATC governance and CI/CD transport controls | Need SAP Integration Suite (iPaaS) capabilities | business/erp-integration/sap-integration-suite-capabilities/2026 |
| Deciding between key user, developer, and side-by-side extension | Need authentication setup for a specific SAP connection | business/erp-integration/sap-authentication-methods/2026 |

## Important Caveats

- The A-D level concept was introduced in August 2025 and is still being adopted across SAP's own documentation. Some older SAP materials, training courses, and community posts still reference the 3-tier model (Tier 1/2/3). When in doubt, refer to the ABAP Extensibility Guide (August 2025 Update). [src1]
- Clean core compliance is a spectrum, not binary. Most large S/4HANA landscapes will have a mix of Level A, B, and C code. The goal is continuous improvement toward Level A, not immediate perfection. [src4]
- The Cloudification Repository coverage varies significantly by S/4HANA functional area. Finance and Sales have the most released APIs; Industry Solutions, Plant Maintenance, and Quality Management have significant gaps as of early 2026. [src7]
- BTP side-by-side extensions introduce operational complexity (separate deployment, monitoring, networking) that may not be justified for simple extensions. Key user extensibility or ABAP Cloud on-stack should be preferred when the extension is tightly coupled to ERP data. [src3]
- SAP's Clean Core Dashboard (in SAP for Me) is currently available only for S/4HANA Cloud Private Edition productive systems. On-premise customers must rely on local ATC reports for compliance tracking. [src2]

## Related Units

- [SAP S/4HANA OData API Capabilities](/business/erp-integration/sap-s4hana-odata-api-capabilities/2026) -- the released API surface for clean core Level A
- [SAP BAPI/RFC Integration](/business/erp-integration/sap-bapi-rfc-integration/2026) -- classic (Level B/C) extension approach
- [SAP IDoc/EDI Integration](/business/erp-integration/sap-idoc-edi-integration/2026) -- classic interface (Level B in new model)
- [SAP Integration Suite Capabilities](/business/erp-integration/sap-integration-suite-capabilities/2026) -- iPaaS for side-by-side integration
- [SAP Event Mesh Capabilities](/business/erp-integration/sap-event-mesh-capabilities/2026) -- async event-driven extensions on BTP
- [SAP Authentication Methods](/business/erp-integration/sap-authentication-methods/2026) -- required for BTP and API access
- [SAP ECC vs S/4HANA Integration](/business/erp-integration/sap-ecc-vs-s4hana-integration/2026) -- clean core applies only to S/4HANA