Das 3-Tier-Modell in ABAP Cloud: Strukturierte Migration von Classic ABAP

Kategorie

ABAP Cloud

Veröffentlicht

15. Feb. 2026

Autor

Das 3-Tier-Modell ist ein bewährtes Architekturmuster für die schrittweise Migration von Classic ABAP zu ABAP Cloud. Es ermöglicht eine strukturierte Koexistenz beider Welten und definiert klare Verantwortlichkeiten für jede Schicht. Dieser Artikel erklärt die drei Tiers, zeigt praktische Code-Beispiele mit dem Flugbuchungs-Szenario und gibt Tipps zur Paketorganisation.

Warum ein Tier-Modell?

Die Migration von Classic ABAP zu ABAP Cloud ist keine Aufgabe, die über Nacht erledigt werden kann. In den meisten Unternehmen gibt es Millionen Zeilen an Custom Code, der schrittweise modernisiert werden muss. Das 3-Tier-Modell bietet hierfür einen strukturierten Ansatz:

Klare Trennung zwischen Cloud-ready und Legacy-Code
Kontrollierte Migration ohne Big-Bang-Risiko
Wiederverwendbarkeit bestehender Funktionalität über Wrapper
ATC-Compliance durch saubere Schichtentrennung

Die drei Tiers im Überblick

┌─────────────────────────────────────────────────────────┐
│ TIER-1: ABAP Cloud                                      │
│ ───────────────────                                     │
│ • Neue Entwicklungen                                    │
│ • RAP Business Objects                                  │
│ • Nur Released APIs                                     │
│ • ABAP Cloud Sprachversion                              │
│ • Zukunftssicher & Cloud-ready                          │
└─────────────────────┬───────────────────────────────────┘
                      │ Aufrufe nur über Released APIs
                      ▼
┌─────────────────────────────────────────────────────────┐
│ TIER-2: API-Wrapper                                     │
│ ───────────────────                                     │
│ • Kapselt Classic ABAP Funktionalität                   │
│ • Stellt Released APIs bereit (C1-Contract)             │
│ • Brücke zwischen Cloud und Classic                     │
│ • Enthält Transformationslogik                          │
└─────────────────────┬───────────────────────────────────┘
                      │ Interne Aufrufe
                      ▼
┌─────────────────────────────────────────────────────────┐
│ TIER-3: Classic ABAP                                    │
│ ───────────────────                                     │
│ • Bestehender Legacy-Code                               │
│ • Nicht-Released APIs                                   │
│ • Direkte DB-Zugriffe                                   │
│ • Wird schrittweise migriert oder ausgemustert          │
└─────────────────────────────────────────────────────────┘

TIER-1: ABAP Cloud

TIER-1 ist die oberste Schicht und enthält ausschließlich ABAP Cloud-konformen Code. Hier werden alle neuen Entwicklungen durchgeführt, und es gelten strenge Regeln:

Merkmale von TIER-1

Sprachversion: ABAP for Cloud Development
APIs: Nur Released APIs (C1-Contract)
Programmiermodell: RAP (ABAP RESTful Application Programming Model)
Entwicklungsumgebung: ABAP Development Tools (ADT)

Flugbuchungs-Beispiel: RAP Business Object

" TIER-1: CDS View für Flugbuchungen (ABAP Cloud)
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Flugbuchung'
define root view entity ZI_FlightBooking
  as select from zflight_book
{
  key booking_id     as BookingId,
      flight_id      as FlightId,
      customer_id    as CustomerId,
      booking_date   as BookingDate,
      @Semantics.amount.currencyCode: 'CurrencyCode'
      price          as Price,
      currency_code  as CurrencyCode,
      booking_status as BookingStatus
}

Die zugehörige Behavior Definition definiert die Geschäftslogik:

" TIER-1: Behavior Definition
managed implementation in class zbp_i_flightbooking unique;
strict ( 2 );

define behavior for ZI_FlightBooking alias FlightBooking
persistent table zflight_book
lock master
authorization master ( instance )
{
  create;
  update;
  delete;

  " Action zum Bestätigen der Buchung
  action confirmBooking result [1] $self;

  " Validierung der Buchungsdaten
  validation validateCustomer on save
    { field CustomerId; }

  " Mapping für Legacy-Felder
  mapping for zflight_book
  {
    BookingId     = booking_id;
    FlightId      = flight_id;
    CustomerId    = customer_id;
    BookingDate   = booking_date;
    Price         = price;
    CurrencyCode  = currency_code;
    BookingStatus = booking_status;
  }
}

Mehr zu RAP und Business Objects findest du im Artikel RAP Grundlagen.

TIER-2: API-Wrapper

TIER-2 ist die Brücke zwischen ABAP Cloud und Classic ABAP. Hier werden Wrapper-Klassen erstellt, die Classic-Funktionalität kapseln und als Released APIs bereitstellen.

Merkmale von TIER-2

Sprachversion: Standard ABAP (Classic)
API-Status: Released (C1-Contract)
Aufgabe: Kapselung und Transformation
ATC-Prüfung: Muss sauber sein für den Release

Flugbuchungs-Beispiel: API-Wrapper

" TIER-2: Wrapper-Klasse für Flugdaten-Zugriff
" API-Status: Released (C1-Contract)
CLASS zcl_flight_api DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    TYPES:
      BEGIN OF ty_flight_info,
        flight_id    TYPE zflight_id,
        carrier_id   TYPE s_carr_id,
        connection   TYPE s_conn_id,
        flight_date  TYPE s_date,
        seats_free   TYPE s_seatsocc,
        price        TYPE s_price,
        currency     TYPE s_currcode,
      END OF ty_flight_info,
      tt_flight_info TYPE STANDARD TABLE OF ty_flight_info WITH EMPTY KEY.

    " Released API für TIER-1
    CLASS-METHODS get_available_flights
      IMPORTING
        iv_carrier    TYPE s_carr_id OPTIONAL
        iv_date_from  TYPE s_date OPTIONAL
        iv_date_to    TYPE s_date OPTIONAL
      RETURNING
        VALUE(rt_flights) TYPE tt_flight_info
      RAISING
        cx_flight_not_found.

    CLASS-METHODS check_seat_availability
      IMPORTING
        iv_flight_id  TYPE zflight_id
        iv_seats      TYPE i
      RETURNING
        VALUE(rv_available) TYPE abap_bool.

  PRIVATE SECTION.
    " Interne Helper für TIER-3 Zugriff
    CLASS-METHODS _fetch_from_legacy
      IMPORTING
        iv_carrier   TYPE s_carr_id OPTIONAL
      RETURNING
        VALUE(rt_data) TYPE tt_flight_info.
ENDCLASS.

CLASS zcl_flight_api IMPLEMENTATION.
  METHOD get_available_flights.
    " Ruft TIER-3 Logik auf und transformiert Daten
    DATA(lt_legacy_data) = _fetch_from_legacy( iv_carrier ).

    " Filterung und Aufbereitung für Cloud-Konsumenten
    LOOP AT lt_legacy_data INTO DATA(ls_flight).
      IF ( iv_date_from IS INITIAL OR ls_flight-flight_date >= iv_date_from )
         AND ( iv_date_to IS INITIAL OR ls_flight-flight_date <= iv_date_to ).
        APPEND ls_flight TO rt_flights.
      ENDIF.
    ENDLOOP.

    IF rt_flights IS INITIAL.
      RAISE EXCEPTION TYPE cx_flight_not_found.
    ENDIF.
  ENDMETHOD.

  METHOD check_seat_availability.
    " Wrapper für Legacy-Verfügbarkeitsprüfung
    DATA(lo_legacy) = NEW zcl_flight_legacy( ).
    rv_available = lo_legacy->check_seats(
      iv_flight_id = iv_flight_id
      iv_seats     = iv_seats
    ).
  ENDMETHOD.

  METHOD _fetch_from_legacy.
    " TIER-3 Aufruf - nicht-released APIs gekapselt
    " Direkter Zugriff auf SFLIGHT (nicht released)
    SELECT flight_id, carrid, connid, fldate, seatsocc, price, currency
      FROM sflight
      WHERE carrid = @iv_carrier OR @iv_carrier IS INITIAL
      INTO CORRESPONDING FIELDS OF TABLE @rt_data.
  ENDMETHOD.
ENDCLASS.

TIER-3: Classic ABAP

TIER-3 enthält den bestehenden Legacy-Code, der schrittweise modernisiert oder ausgemustert wird. Dieser Code verwendet nicht-released APIs und direkte Datenbankzugriffe.

Merkmale von TIER-3

Sprachversion: Standard ABAP (Classic)
APIs: Nicht-released, interne SAP-Objekte
Zugriff: Direkte DB-Zugriffe, BAPIs, Function Modules
Ziel: Migration zu TIER-1 oder Kapselung durch TIER-2

Flugbuchungs-Beispiel: Legacy-Code

" TIER-3: Legacy-Klasse (wird nur von TIER-2 aufgerufen)
CLASS zcl_flight_legacy DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS check_seats
      IMPORTING
        iv_flight_id TYPE zflight_id
        iv_seats     TYPE i
      RETURNING
        VALUE(rv_available) TYPE abap_bool.

    METHODS book_flight_legacy
      IMPORTING
        iv_flight_id  TYPE zflight_id
        iv_customer   TYPE kunnr
        iv_seats      TYPE i
      EXPORTING
        ev_booking_id TYPE zbook_id
      RAISING
        cx_booking_failed.
ENDCLASS.

CLASS zcl_flight_legacy IMPLEMENTATION.
  METHOD check_seats.
    " Direkter Zugriff auf nicht-released Tabelle
    SELECT SINGLE seatsmax, seatsocc
      FROM sflight
      WHERE flight_id = @iv_flight_id
      INTO @DATA(ls_flight).

    IF sy-subrc = 0.
      rv_available = xsdbool( ls_flight-seatsmax - ls_flight-seatsocc >= iv_seats ).
    ENDIF.
  ENDMETHOD.

  METHOD book_flight_legacy.
    " Legacy BAPI-Aufruf
    CALL FUNCTION 'BAPI_FLIGHT_BOOKING_CREATE'
      EXPORTING
        flight_id      = iv_flight_id
        customer       = iv_customer
        seats_required = iv_seats
      IMPORTING
        booking_number = ev_booking_id
      EXCEPTIONS
        flight_full    = 1
        OTHERS         = 2.

    IF sy-subrc <> 0.
      RAISE EXCEPTION TYPE cx_booking_failed.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Für detaillierte Informationen zur Unterscheidung zwischen Classic und Cloud ABAP siehe ABAP Cloud vs Classic ABAP.

Das Berechtigungsobjekt S_ABPLNGVS

Ein zentrales Element für die Steuerung der Sprachversionen ist das Berechtigungsobjekt S_ABPLNGVS. Es kontrolliert, welche ABAP-Sprachversion ein Entwickler in welchen Paketen verwenden darf.

Felder des Berechtigungsobjekts

Feld	Bedeutung	Werte
`ACTIVITY`	Aktivität	`01` (Anlegen), `02` (Ändern), `03` (Anzeigen)
`DEVCLASS`	Paket	Paketname oder `*` für alle
`ABPLNGVS`	Sprachversion	`STANDARD`, `ABAP_FOR_CLOUD_DEVELOPMENT`

Beispielkonfiguration

Rolle: Z_ABAP_CLOUD_DEVELOPER
─────────────────────────────────
S_ABPLNGVS:
  ACTIVITY: 01, 02, 03
  DEVCLASS: ZT1_*
  ABPLNGVS: ABAP_FOR_CLOUD_DEVELOPMENT

S_ABPLNGVS:
  ACTIVITY: 01, 02, 03
  DEVCLASS: ZT2_*, ZT3_*
  ABPLNGVS: STANDARD

Diese Konfiguration erlaubt:

ABAP Cloud Entwicklung nur in Paketen mit Prefix ZT1_
Classic ABAP in Paketen mit Prefix ZT2_ und ZT3_

Praktische Tipps zur Paketorganisation

Eine durchdachte Paketstruktur ist entscheidend für die erfolgreiche Umsetzung des 3-Tier-Modells.

Empfohlene Namenskonvention

Z<PROJEKT>_<TIER>_<BEREICH>

Beispiele:
─────────────────────────────────────────────
ZFB_T1_BOOKING     → TIER-1, Flugbuchung (ABAP Cloud)
ZFB_T1_REPORTING   → TIER-1, Reporting (ABAP Cloud)
ZFB_T2_FLIGHT_API  → TIER-2, Flight API Wrapper
ZFB_T2_CUSTOMER    → TIER-2, Customer API Wrapper
ZFB_T3_LEGACY      → TIER-3, Legacy-Code
ZFB_T3_MIGRATION   → TIER-3, Zu migrierende Objekte

Paketstruktur für Flugbuchung

$ZFB (Superpaket)
├── ZFB_T1 (TIER-1 Hauptpaket)
│   ├── ZFB_T1_BOOKING
│   │   ├── ZI_FlightBooking (CDS Entity)
│   │   ├── ZBP_I_FlightBooking (Behavior Impl.)
│   │   └── ZUI_FlightBooking_O4 (Service Binding)
│   ├── ZFB_T1_CUSTOMER
│   │   └── ... (Kundenverwaltung)
│   └── ZFB_T1_REPORTING
│       └── ... (Auswertungen)
│
├── ZFB_T2 (TIER-2 Hauptpaket)
│   ├── ZFB_T2_FLIGHT_API
│   │   ├── ZCL_FLIGHT_API (Released Wrapper)
│   │   └── ZIF_FLIGHT_API (Interface)
│   └── ZFB_T2_PRICING
│       └── ZCL_PRICING_API (Preisberechnung)
│
└── ZFB_T3 (TIER-3 Hauptpaket)
    ├── ZFB_T3_LEGACY
    │   ├── ZCL_FLIGHT_LEGACY
    │   └── ZFLIGHT_BOOKING_FORM (alter Report)
    └── ZFB_T3_DEPRECATED
        └── ... (ausgemusterte Objekte)

Sprachversion pro Paket setzen

In den Paketeigenschaften in ADT:

ZFB_T1_BOOKING:
  Eigenschaften → ABAP Language Version → "ABAP for Cloud Development"
  → Compiler erzwingt ABAP Cloud Regeln!

ZFB_T2_FLIGHT_API:
  Eigenschaften → ABAP Language Version → "Standard ABAP"
  → Erlaubt Classic ABAP, aber API muss released werden

ZFB_T3_LEGACY:
  Eigenschaften → ABAP Language Version → "Standard ABAP"
  → Volle Freiheit, aber nur intern genutzt

Softwarekomponenten-Struktur

Für größere Projekte empfiehlt sich die Organisation in Softwarekomponenten:

" Softwarekomponenten für Flugbuchungssystem
"
" Komponente: ZFLIGHTBOOKING
" ───────────────────────────────────────────
" Transport Layer: ZDEV
" Delivery Unit: ZFLIGHTBOOKING_DU
"
" Struktur:
" ├── Anwendungsschicht (TIER-1)
" │   └── Paket: ZFB_T1 (ABAP Cloud)
" │
" ├── API-Schicht (TIER-2)
" │   └── Paket: ZFB_T2 (Standard + Released)
" │
" └── Legacy-Schicht (TIER-3)
"     └── Paket: ZFB_T3 (Standard, nicht released)

Abhängigkeitsregeln

┌─────────────────────────────────────────────────────────┐
│                    Erlaubte Aufrufe                      │
├─────────────────────────────────────────────────────────┤
│ TIER-1 → TIER-2    ✅ (über Released APIs)              │
│ TIER-1 → TIER-3    ❌ (verboten - ATC-Fehler!)          │
│ TIER-2 → TIER-3    ✅ (interne Kapselung)               │
│ TIER-3 → TIER-2    ⚠️ (möglich, aber nicht empfohlen)   │
│ TIER-3 → TIER-1    ❌ (Zirkuläre Abhängigkeit)          │
└─────────────────────────────────────────────────────────┘

Migration-Strategie: Von TIER-3 zu TIER-1

Die langfristige Strategie ist die schrittweise Migration von TIER-3 zu TIER-1:

Phase 1: Identifikation
─────────────────────────
• TIER-3 Code analysieren
• ATC-Checks durchführen
• Abhängigkeiten dokumentieren

Phase 2: Wrapper (TIER-2)
─────────────────────────
• API-Wrapper für kritische Funktionen
• Released APIs definieren
• Tests schreiben

Phase 3: Migration (TIER-1)
─────────────────────────
• Neue RAP-Implementierung
• TIER-2 Wrapper ablösen
• Legacy-Code stilllegen

Phase 4: Cleanup
─────────────────────────
• TIER-3 Code löschen
• TIER-2 Wrapper entfernen
• Nur TIER-1 bleibt

Für einen detaillierten Migrations-Leitfaden siehe ABAP Cloud Migration Guide.

Fazit

Das 3-Tier-Modell bietet einen strukturierten Ansatz für die Migration zu ABAP Cloud:

TIER-1 (ABAP Cloud): Zukunftssichere Neuentwicklungen
TIER-2 (API-Wrapper): Brücke zur Legacy-Welt
TIER-3 (Classic ABAP): Zu migrierende Altlasten

Durch klare Paketorganisation mit T1/T2/T3-Prefixen, das Berechtigungsobjekt S_ABPLNGVS und konsequente API-Kapselung gelingt die schrittweise Modernisierung ohne Risiko.

Wichtig: SAP hat mittlerweile das Clean Core Level-Konzept (A-D) als vereinfachte Alternative eingeführt, das die Komplexität des 3-Tier-Modells reduziert. Prüfe beide Ansätze und wähle den passenden für dein Projekt.