Clean Core Level-Konzept (A-D): Der moderne Weg zu ABAP Cloud

Kategorie

ABAP Cloud

Veröffentlicht

15. Feb. 2026

Autor

Das Clean Core Level-Konzept (A-D) ist SAPs neuester Ansatz zur Klassifizierung und Modernisierung von ABAP-Code. Es ersetzt das komplexere 3-Tier-Modell durch ein einfacheres, stufenbasiertes System. Dieser Artikel erklärt alle vier Levels, zeigt die ATC-Integration und bietet praktische Entscheidungshilfen für die Modernisierung.

Warum ein neues Level-Konzept?

Das 3-Tier-Modell hat sich in der Praxis als komplex erwiesen. Die klare Trennung in TIER-1, TIER-2 und TIER-3 war theoretisch sauber, aber in realen Projekten schwer durchzuhalten. SAP hat darauf reagiert und mit dem Level-Konzept einen pragmatischeren Ansatz eingeführt:

Einfachere Klassifizierung ohne strenge Schichtentrennung
Automatische Erkennung durch ATC-Checks
Fließende Übergänge zwischen den Levels
Fokus auf API-Nutzung statt Architekturschichten

Die vier Levels im Überblick

┌─────────────────────────────────────────────────────────────┐
│ Level A: Released APIs                                       │
│ ──────────────────────                                       │
│ • Nur freigegebene SAP-APIs (C1-Contract)                   │
│ • Volle Cloud-Kompatibilität                                │
│ • Zukunftssicher und upgradestabil                          │
│ • ✅ Clean Core konform                                     │
└──────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ Level B: Classic APIs                                        │
│ ──────────────────────                                       │
│ • Stabile klassische APIs (BAPIs, RFC)                      │
│ • Nicht für Cloud released, aber dokumentiert               │
│ • Upgrade-risiko moderat                                    │
│ • ⚠️ Modernisierung empfohlen                               │
└──────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ Level C: Unclassified                                        │
│ ──────────────────────                                       │
│ • Zugriff auf nicht-klassifizierte Objekte                  │
│ • Kein SAP-Contract, keine Stabilitätsgarantie              │
│ • Hohes Upgrade-Risiko                                      │
│ • ❌ Modernisierung erforderlich                            │
└──────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ Level D: noAPI (direkte Zugriffe)                            │
│ ──────────────────────                                       │
│ • Direkte Tabellenzugriffe (SELECT auf SAP-Tabellen)        │
│ • Nicht-öffentliche Funktionsbausteine                      │
│ • Maximales Upgrade-Risiko                                  │
│ • ❌ Sofortige Modernisierung notwendig                     │
└──────────────────────────────────────────────────────────────┘

Level A: Released APIs

Level A ist das Ziel jeder Modernisierung. Code auf diesem Level nutzt ausschließlich freigegebene SAP-APIs mit stabilem Contract (C1).

Merkmale von Level A

API-Contract: C1 (Released for Cloud Development)
Upgrade-Stabilität: Garantiert durch SAP
Cloud-Readiness: Vollständig kompatibel
Dokumentation: Offizielle SAP-Dokumentation verfügbar

Beispiel: Level A Code

CLASS zcl_flight_booking_a DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS get_user_info
      RETURNING VALUE(rs_user) TYPE cl_abap_context_info=>ty_context_info.

    METHODS get_current_date
      RETURNING VALUE(rv_date) TYPE d.

    METHODS read_flights
      RETURNING VALUE(rt_flights) TYPE zt_flights.

ENDCLASS.

CLASS zcl_flight_booking_a IMPLEMENTATION.
  METHOD get_user_info.
    " ✅ Level A: Released API für Benutzerinfo
    rs_user-user_id = cl_abap_context_info=>get_user_technical_name( ).
    rs_user-user_alias = cl_abap_context_info=>get_user_alias( ).
    rs_user-system_date = cl_abap_context_info=>get_system_date( ).
  ENDMETHOD.

  METHOD get_current_date.
    " ✅ Level A: Released API für Datum
    rv_date = cl_abap_context_info=>get_system_date( ).
  ENDMETHOD.

  METHOD read_flights.
    " ✅ Level A: Zugriff auf eigene Z-Tabelle (immer erlaubt)
    SELECT * FROM zflight_book INTO TABLE @rt_flights.
  ENDMETHOD.
ENDCLASS.

Häufig genutzte Level A APIs

Klasse/Interface	Zweck
`CL_ABAP_CONTEXT_INFO`	Benutzer- und Systeminformationen
`XCO_CP_*`	Extension Components (DDIC, CDS, Repository)
`CL_ABAP_RANDOM_*`	Zufallszahlen
`CL_ABAP_CONV_*`	Zeichensatz-Konvertierung
`IF_ABAP_BEHV_MESSAGE`	RAP-Nachrichten

Level B: Classic APIs

Level B umfasst stabile klassische APIs wie BAPIs und RFC-fähige Funktionsbausteine. Diese sind dokumentiert und relativ stabil, aber nicht für die Cloud freigegeben.

Merkmale von Level B

API-Contract: Stabil, aber nicht C1
Upgrade-Stabilität: Meist gegeben, aber nicht garantiert
Cloud-Readiness: Nicht direkt, Wrapper erforderlich
Dokumentation: Vorhanden (BAPI Explorer, Function Module Doku)

Beispiel: Level B Code

" ⚠️ Level B: BAPI - stabil aber nicht released
DATA: lt_return TYPE TABLE OF bapiret2.

CALL FUNCTION 'BAPI_CUSTOMER_GETDETAIL2'
  EXPORTING
    customerno   = lv_customer_id
  IMPORTING
    customerdata = ls_customer
  TABLES
    return       = lt_return.

" ⚠️ Level B: Klassischer Währungs-Funktionsbaustein
CALL FUNCTION 'CONVERT_TO_LOCAL_CURRENCY'
  EXPORTING
    date             = sy-datum
    foreign_amount   = lv_amount
    foreign_currency = 'USD'
    local_currency   = 'EUR'
  IMPORTING
    local_amount     = lv_result.

Typische Level B Objekte

BAPIs (BAPI_* Funktionsbausteine)
RFC-fähige Funktionsbausteine
Dokumentierte Datenelemente und Domänen

Level C: Unclassified

Level C enthält Zugriffe auf nicht-klassifizierte SAP-Objekte. Diese haben keinen API-Contract und können sich bei Upgrades ändern.

Merkmale von Level C

API-Contract: Keiner
Upgrade-Stabilität: Nicht garantiert
Cloud-Readiness: Nicht gegeben
Dokumentation: Oft nur intern vorhanden

Beispiel: Level C Code

" ❌ Level C: Nicht-released Klasse
DATA(lo_flight_srv) = NEW cl_flight_service( ).
DATA(lt_schedule) = lo_flight_srv->get_connections( lv_carrier ).

" ❌ Level C: Verwendung von GUI-Klassen (nicht Cloud-fähig)
DATA(lo_alv) = NEW cl_gui_alv_grid( i_parent = lo_container ).
lo_alv->set_table_for_first_display( CHANGING it_outtab = lt_data ).

Level D: noAPI (direkte Zugriffe)

Level D ist die kritischste Stufe. Code auf diesem Level greift direkt auf SAP-interne Strukturen zu und hat das höchste Risiko bei Upgrades.

Merkmale von Level D

API-Contract: Keiner, interne Implementierung
Upgrade-Stabilität: Nicht gegeben
Cloud-Readiness: Ausgeschlossen
Dokumentation: Keine öffentliche

Beispiel: Level D Code

" ❌❌ Level D: Direkter Zugriff auf SAP-interne Tabelle
SELECT SINGLE *
  FROM mara
  WHERE matnr = @lv_matnr
  INTO @ls_material.

" ❌❌ Level D: Zugriff auf nicht-öffentlichen Funktionsbaustein
CALL FUNCTION 'SD_SALES_DOCUMENT_READ_INT'
  EXPORTING
    document_number = lv_vbeln
  IMPORTING
    sales_header    = ls_header.

Vergleich: Level-Konzept vs. 3-Tier-Modell

Aspekt	3-Tier-Modell	Level-Konzept (A-D)
Klassifizierung	Nach Architekturschicht	Nach API-Nutzung
Komplexität	Hoch (Wrapper erforderlich)	Niedrig (direkte Klassifizierung)
Automatisierung	Manuelle Einordnung	ATC-automatisiert
Übergänge	Streng getrennt	Fließend
Fokus	Kapselung	Modernisierung
Ziel	TIER-1 erreichen	Level A erreichen

Mapping zwischen den Modellen

3-Tier-Modell          Level-Konzept
─────────────────────────────────────
TIER-1 (ABAP Cloud)  → Level A
TIER-2 (API-Wrapper) → Level A + B (je nach Wrapper-Inhalt)
TIER-3 (Classic)     → Level B, C oder D (je nach API-Nutzung)

ATC-Integration zur Level-Überwachung

Der ATC (ABAP Test Cockpit) erkennt automatisch, welches Level ein Entwicklungsobjekt hat.

ATC-Check-Variante für Clean Core

Check-Variante: Z_CLEAN_CORE_LEVELS
─────────────────────────────────────
Checks:
├── ABAP Cloud Readiness
│   ├── Released API Usage (Level A)
│   ├── Classic API Detection (Level B)
│   ├── Unclassified Objects (Level C)
│   └── Direct Table Access (Level D)
│
├── Prioritäten:
│   ├── Level D Findings: Priorität 1 (Fehler)
│   ├── Level C Findings: Priorität 2 (Warnung)
│   └── Level B Findings: Priorität 3 (Info)
│
└── Ausnahmen:
    └── Z-Tabellen: immer Level A (eigene Objekte)

ATC-Ergebnisse interpretieren

" ATC Finding: Level D - Direkter Tabellenzugriff
" ────────────────────────────────────────────────
" Objekt: ZCL_FLIGHT_LEGACY
" Zeile: 45
" Finding: SELECT FROM MARA (nicht-released Tabelle)
" Priorität: 1 (Fehler)
" Empfehlung: Verwende CDS View I_Product oder BAPI

" ATC Finding: Level C - Nicht-klassifiziertes Objekt
" ────────────────────────────────────────────────
" Objekt: ZCL_CUSTOMER_SERVICE
" Zeile: 78
" Finding: Verwendung von CL_GUI_ALV_GRID
" Priorität: 2 (Warnung)
" Empfehlung: Migriere zu Fiori/RAP

" ATC Finding: Level B - Classic API
" ────────────────────────────────────────────────
" Objekt: ZCL_ORDER_PROCESSOR
" Zeile: 112
" Finding: CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
" Priorität: 3 (Info)
" Empfehlung: Prüfe auf Released API Alternative

Praktische Modernisierungsstrategie

Phase 1: Bestandsaufnahme

ATC-Analyse mit Check-Variante für Clean Core durchführen
Level-Verteilung ermitteln und Objekte pro Level zählen
Kritische Level D Objekte identifizieren

Phase 2: Priorisierung

Priorität	Migration	Maßnahmen
1 (Hoch)	D → A/B	Direkte Tabellenzugriffe ersetzen
2 (Mittel)	C → A/B	Nicht-klassifizierte Objekte modernisieren
3 (Niedrig)	B → A	BAPIs durch Released APIs ersetzen

Phase 3: Umsetzung

" VORHER: Level D Code
SELECT SINGLE * FROM mara WHERE matnr = @lv_matnr INTO @ls_material.

" NACHHER: Level A Code
SELECT SINGLE Product, ProductType, BaseUnit
  FROM I_Product
  WHERE Product = @lv_matnr
  INTO @ls_material.

Entscheidungshilfe: Welches Level für welchen Use Case

Entscheidungsmatrix

Anforderung	Empfohlenes Level	Begründung
Neue RAP-Anwendung	Level A	Cloud-ready von Anfang an
Integration mit Standard	Level A/B	Je nach verfügbarer API
Legacy-Modernisierung	Level B → A	Schrittweise Migration
Quick Fix (temporär)	Level B	Mit Modernisierungs-Ticket
Kundenspezifische Logik	Level A	Eigene Objekte sind frei

Best Practices für Clean Core Level A

Do’s

✅ Nutze CL_ABAP_CONTEXT_INFO für System-/Benutzerinfos
✅ Verwende XCO-Libraries für Metadaten-Zugriff
✅ Setze auf CDS Views (I_*) für SAP-Daten
✅ Implementiere neue Logik in RAP Business Objects
✅ Nutze Released Exceptions (CX_*)

Don’ts

❌ Keine direkten SELECT auf SAP-Tabellen (MARA, VBAK, …)
❌ Kein SY-UNAME, SY-DATUM für Cloud-Code
❌ Keine Aufrufe nicht-released Funktionsbausteine
❌ Keine Verwendung von CL_GUI_* Klassen
❌ Kein CALL TRANSACTION oder SUBMIT REPORT

Fazit

Das Clean Core Level-Konzept (A-D) vereinfacht die Modernisierung von ABAP-Code erheblich:

Level A: Das Ziel - vollständig Cloud-ready
Level B: Akzeptable Übergangslösung mit klassischen APIs
Level C: Modernisierungsbedarf erkennbar
Level D: Sofortige Handlung erforderlich

Im Vergleich zum 3-Tier-Modell bietet das Level-Konzept einen pragmatischeren Ansatz, der durch ATC-Integration automatisiert überwacht werden kann. Der Fokus liegt auf der API-Nutzung statt auf starren Architekturschichten.

Für die praktische Umsetzung einer Clean Core Strategie siehe Clean Core Level-Strategie - Und jetzt?. Weitere Informationen zu Released APIs findest du unter ABAP Cloud Definition.