ABAP Cloud Implementierungs-Checkliste: Alles Wichtige auf einen Blick

Kategorie

ABAP Cloud

Veröffentlicht

15. Feb. 2026

Autor

Diese Implementierungs-Checkliste hilft Projektleitern und Entwicklern, bei ABAP Cloud Projekten nichts Wichtiges zu vergessen. Von der initialen Systemvorbereitung über die RAP-Entwicklung bis zum Go-Live sind alle kritischen Schritte abgedeckt.

Übersicht: Die fünf Phasen

┌─────────────────────────────────────────────────────────────┐
│ Phase 1: Projektvorbereitung                                 │
│ ────────────────────────────                                 │
│ • Systemlandschaft & Berechtigungen                         │
│ • Paketstruktur & Namenskonventionen                        │
│ • Entwicklungstools einrichten                              │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 2: Datenmodell                                         │
│ ────────────────────                                         │
│ • Tabellendesign & Datenelemente                            │
│ • CDS Views & Assoziationen                                 │
│ • Released APIs identifizieren                              │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 3: RAP-Entwicklung                                     │
│ ──────────────────────                                       │
│ • Behavior Definition & Implementation                       │
│ • Validierungen, Determinations, Actions                    │
│ • Authorization & Feature Control                           │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 4: Service & UI                                        │
│ ────────────────────                                         │
│ • Service Definition & Binding                              │
│ • UI-Annotationen                                           │
│ • Fiori Elements App                                        │
└──────────────────────────────────────────────────────────────┘
                              ▼
┌─────────────────────────────────────────────────────────────┐
│ Phase 5: Qualitätssicherung & Go-Live                        │
│ ───────────────────────────────────                          │
│ • Unit Tests & ATC                                          │
│ • Performance & Security                                    │
│ • Transport & Dokumentation                                 │
└──────────────────────────────────────────────────────────────┘

Phase 1: Projektvorbereitung

Systemlandschaft & Berechtigungen

Check	Beschreibung	Status
☐	ABAP Cloud Sprachversion im System aktiviert
☐	Entwicklerbenutzer haben S_ABPLNGVS für Cloud-Pakete
☐	Transportroute definiert (DEV → QAS → PRD)
☐	ADT/BAS Zugang für alle Entwickler eingerichtet
☐	Git-Repository erstellt (falls abapGit genutzt wird)

Paketstruktur anlegen

" Empfohlene Paketstruktur für ABAP Cloud Projekt
"
" $Z_PROJEKT (Superpaket)
" ├── Z_PROJEKT_MODEL
" │   ├── Tabellen (ZTAB_*)
" │   ├── CDS Views (ZI_*, ZC_*)
" │   └── Datenelemente
" │
" ├── Z_PROJEKT_BDEF
" │   ├── Behavior Definitions
" │   └── Behavior Implementations (ZBP_*)
" │
" ├── Z_PROJEKT_SERVICE
" │   ├── Service Definitions
" │   └── Service Bindings
" │
" └── Z_PROJEKT_TEST
"     └── Unit Test Klassen (ZTC_*)

Namenskonventionen festlegen

Objekttyp	Prefix	Beispiel
Datenbanktabelle	`ZTAB_`	`ZTAB_BOOKING`
Interface View (CDS)	`ZI_`	`ZI_Booking`
Consumption View	`ZC_`	`ZC_Booking`
Behavior Pool	`ZBP_`	`ZBP_I_Booking`
Service Definition	`ZSRV_`	`ZSRV_Booking`
Service Binding	`ZUI_`	`ZUI_Booking_O4`
Unit Test Klasse	`ZTC_`	`ZTC_Booking_Test`

Phase 2: Datenmodell

Tabellendesign-Checkliste

Check	Beschreibung
☐	Primärschlüssel definiert (CLIENT + Key-Felder)
☐	Technische Felder vorhanden (CREATED_BY, CREATED_AT, …)
☐	Datenelemente statt eingebaute Typen verwendet
☐	Fremdschlüssel-Beziehungen dokumentiert
☐	Delivery Class korrekt gesetzt (A, C, L, …)

Beispiel: Tabellendefinition

@EndUserText.label : 'Buchungen'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
define table ztab_booking {
  key client       : abap.clnt not null;
  key booking_uuid : sysuuid_x16 not null;
  booking_id       : ze_booking_id;
  customer_id      : ze_customer_id;
  flight_date      : abap.dats;
  @Semantics.amount.currencyCode : 'ztab_booking.currency_code'
  price            : abap.curr(15,2);
  currency_code    : abap.cuky;
  status           : ze_booking_status;

  " Technische Felder
  created_by       : abp_creation_user;
  created_at       : abp_creation_tstmpl;
  last_changed_by  : abp_locinst_lastchange_user;
  last_changed_at  : abp_locinst_lastchange_tstmpl;
}

CDS View Checkliste

Check	Beschreibung
☐	Root View Entity mit `define root view entity`
☐	Access Control definiert (`@AccessControl.authorizationCheck`)
☐	Semantische Annotationen (`@Semantics.amount`, `@Semantics.quantity`)
☐	Assoziationen zu abhängigen Entitäten
☐	Key-Felder korrekt markiert

Beispiel: CDS View Entity

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Buchung'
define root view entity ZI_Booking
  as select from ztab_booking
  composition [0..*] of ZI_BookingItem as _Items
  association [1..1] to ZI_Customer    as _Customer
    on $projection.CustomerId = _Customer.CustomerId
{
  key booking_uuid    as BookingUuid,
      booking_id      as BookingId,
      customer_id     as CustomerId,
      flight_date     as FlightDate,
      @Semantics.amount.currencyCode: 'CurrencyCode'
      price           as Price,
      currency_code   as CurrencyCode,
      status          as Status,

      " Admin-Felder
      @Semantics.user.createdBy: true
      created_by      as CreatedBy,
      @Semantics.systemDateTime.createdAt: true
      created_at      as CreatedAt,
      @Semantics.user.lastChangedBy: true
      last_changed_by as LastChangedBy,
      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at as LastChangedAt,

      " Assoziationen
      _Items,
      _Customer
}

Released APIs für SAP-Daten

SAP-Daten	Released API (Level A)	Nicht verwenden (Level D)
Material	`I_Product`	`MARA`, `MAKT`
Kunde	`I_Customer`	`KNA1`, `KNB1`
Lieferant	`I_Supplier`	`LFA1`, `LFB1`
Verkaufsbeleg	`I_SalesOrder`	`VBAK`, `VBAP`
Benutzerinfo	`CL_ABAP_CONTEXT_INFO`	`SY-UNAME`, `USR02`

Mehr zu Released APIs im Artikel Clean Core Level-Konzept.

Phase 3: RAP-Entwicklung

Behavior Definition Checkliste

Check	Beschreibung
☐	Implementation Type gewählt (`managed` oder `unmanaged`)
☐	`strict ( 2 )` für neuste RAP-Version
☐	Persistent Table oder Draft Table definiert
☐	Lock Master/Dependent korrekt gesetzt
☐	Authorization Master definiert
☐	Validierungen für Pflichtfelder
☐	Determinations für automatische Werte
☐	Actions für Geschäftsprozesse

Beispiel: Behavior Definition

managed implementation in class zbp_i_booking unique;
strict ( 2 );

define behavior for ZI_Booking alias Booking
persistent table ztab_booking
draft table ztab_book_d
lock master total etag LastChangedAt
authorization master ( instance )
etag master LastChangedAt
{
  create;
  update;
  delete;

  " Automatische Feldwerte
  field ( readonly ) BookingUuid, CreatedBy, CreatedAt,
                     LastChangedBy, LastChangedAt;
  field ( numbering : managed ) BookingUuid;

  " Draft-Unterstützung
  draft action Edit;
  draft action Activate optimized;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare;

  " Validierungen
  validation validateCustomer on save
    { field CustomerId; create; }
  validation validateFlightDate on save
    { field FlightDate; create; update; }

  " Determination für Booking-ID
  determination setBookingId on modify
    { field BookingUuid; create; }

  " Actions
  action ( features : instance ) confirm result [1] $self;
  action ( features : instance ) cancel result [1] $self;

  " Komposition
  association _Items { create; }

  mapping for ztab_booking
  {
    BookingUuid   = booking_uuid;
    BookingId     = booking_id;
    CustomerId    = customer_id;
    FlightDate    = flight_date;
    Price         = price;
    CurrencyCode  = currency_code;
    Status        = status;
    CreatedBy     = created_by;
    CreatedAt     = created_at;
    LastChangedBy = last_changed_by;
    LastChangedAt = last_changed_at;
  }
}

Behavior Implementation Checkliste

Check	Beschreibung
☐	Jede Validation hat `failed` und `reported` Handling
☐	Determinations füllen alle automatischen Felder
☐	Actions prüfen Vorbedingungen (`IF booking-Status = ...`)
☐	Feature Control für dynamische Action-Verfügbarkeit
☐	Messages nutzen `if_abap_behv_message` Interface

Beispiel: Validation

METHOD validateCustomer.
  " Alle relevanten Buchungen lesen
  READ ENTITIES OF ZI_Booking IN LOCAL MODE
    ENTITY Booking
      FIELDS ( CustomerId )
      WITH CORRESPONDING #( keys )
    RESULT DATA(lt_bookings).

  " Kundendaten prüfen
  SELECT CustomerId FROM ZI_Customer
    FOR ALL ENTRIES IN @lt_bookings
    WHERE CustomerId = @lt_bookings-CustomerId
    INTO TABLE @DATA(lt_valid_customers).

  LOOP AT lt_bookings INTO DATA(ls_booking).
    IF NOT line_exists( lt_valid_customers[ CustomerId = ls_booking-CustomerId ] ).
      APPEND VALUE #( %tky = ls_booking-%tky ) TO failed-booking.
      APPEND VALUE #( %tky = ls_booking-%tky
                      %msg = new_message_with_text(
                               severity = if_abap_behv_message=>severity-error
                               text     = |Kunde { ls_booking-CustomerId } nicht gefunden| )
                      %element-CustomerId = if_abap_behv=>mk-on
                    ) TO reported-booking.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

Authorization & Feature Control

METHOD get_instance_authorizations.
  READ ENTITIES OF ZI_Booking IN LOCAL MODE
    ENTITY Booking
      FIELDS ( Status )
      WITH CORRESPONDING #( keys )
    RESULT DATA(lt_bookings).

  LOOP AT lt_bookings INTO DATA(ls_booking).
    APPEND VALUE #(
      %tky = ls_booking-%tky
      %update = COND #( WHEN ls_booking-Status = 'CONFIRMED'
                        THEN if_abap_behv=>auth-unauthorized
                        ELSE if_abap_behv=>auth-allowed )
      %delete = COND #( WHEN ls_booking-Status = 'CONFIRMED'
                        THEN if_abap_behv=>auth-unauthorized
                        ELSE if_abap_behv=>auth-allowed )
      %action-confirm = COND #( WHEN ls_booking-Status = 'NEW'
                                THEN if_abap_behv=>auth-allowed
                                ELSE if_abap_behv=>auth-unauthorized )
      %action-cancel = COND #( WHEN ls_booking-Status <> 'CANCELLED'
                               THEN if_abap_behv=>auth-allowed
                               ELSE if_abap_behv=>auth-unauthorized )
    ) TO result.
  ENDLOOP.
ENDMETHOD.

Phase 4: Service & UI

Service Layer Checkliste

Check	Beschreibung
☐	Service Definition erstellt mit `define service`
☐	Alle benötigten Entitäten exponiert
☐	Service Binding für OData V4 (empfohlen)
☐	Service Binding aktiviert und getestet
☐	Fiori Preview funktioniert in ADT

Beispiel: Service Definition

@EndUserText.label: 'Booking Service'
define service ZSRV_Booking {
  expose ZC_Booking as Booking;
  expose ZC_BookingItem as BookingItem;
  expose ZI_Customer as Customer;
}

UI-Annotationen Checkliste

Check	Beschreibung
☐	`@UI.headerInfo` für Entity-Header
☐	`@UI.lineItem` für Listenansicht
☐	`@UI.facet` für Object Page Struktur
☐	`@UI.selectionField` für Filterkriterien
☐	`@UI.identification` für Object Page Felder
☐	`@UI.fieldGroup` für logische Gruppierung

Beispiel: Metadata Extension

@Metadata.layer: #CUSTOMER
annotate view ZC_Booking with
{
  @UI.facet: [
    { id: 'GeneralInfo',
      purpose: #STANDARD,
      type: #IDENTIFICATION_REFERENCE,
      label: 'Allgemein',
      position: 10 },
    { id: 'Items',
      purpose: #STANDARD,
      type: #LINEITEM_REFERENCE,
      label: 'Positionen',
      position: 20,
      targetElement: '_Items' }
  ]

  @UI.headerInfo: {
    typeName: 'Buchung',
    typeNamePlural: 'Buchungen',
    title: { value: 'BookingId' },
    description: { value: 'CustomerId' }
  }

  @UI: { lineItem: [{ position: 10 }],
         selectionField: [{ position: 10 }],
         identification: [{ position: 10 }] }
  BookingId;

  @UI: { lineItem: [{ position: 20 }],
         selectionField: [{ position: 20 }],
         identification: [{ position: 20 }] }
  CustomerId;

  @UI: { lineItem: [{ position: 30 }],
         identification: [{ position: 30 }] }
  FlightDate;

  @UI: { lineItem: [{ position: 40, criticality: 'StatusCriticality' }],
         identification: [{ position: 40, criticality: 'StatusCriticality' }] }
  Status;
}

Phase 5: Qualitätssicherung & Go-Live

Unit Tests Checkliste

Check	Beschreibung
☐	Test-Klasse mit `FOR TESTING` und `RISK LEVEL HARMLESS`
☐	Validierungen getestet (positive & negative Fälle)
☐	Determinations getestet
☐	Actions getestet mit Statusübergängen
☐	Mindestens 70% Code Coverage erreicht

Beispiel: Unit Test

CLASS ztc_booking_test DEFINITION
  FOR TESTING
  RISK LEVEL HARMLESS
  DURATION SHORT.

  PRIVATE SECTION.
    CLASS-DATA:
      environment TYPE REF TO if_cds_test_environment.

    CLASS-METHODS:
      class_setup,
      class_teardown.

    METHODS:
      setup,
      test_create_booking FOR TESTING,
      test_validate_customer_invalid FOR TESTING.
ENDCLASS.

CLASS ztc_booking_test IMPLEMENTATION.
  METHOD class_setup.
    environment = cl_cds_test_environment=>create_for_multiple_cds(
      VALUE #( ( i_for_entity = 'ZI_BOOKING' )
               ( i_for_entity = 'ZI_CUSTOMER' ) ) ).
  ENDMETHOD.

  METHOD class_teardown.
    environment->destroy( ).
  ENDMETHOD.

  METHOD setup.
    environment->clear_doubles( ).
  ENDMETHOD.

  METHOD test_create_booking.
    " Testdaten vorbereiten
    DATA(lt_customers) = VALUE zt_customer( ( customer_id = 'CUST001' ) ).
    environment->insert_test_data( lt_customers ).

    " RAP Operation ausführen
    MODIFY ENTITIES OF ZI_Booking
      ENTITY Booking
        CREATE FIELDS ( CustomerId FlightDate Price CurrencyCode )
        WITH VALUE #( ( %cid = 'CID1'
                        CustomerId = 'CUST001'
                        FlightDate = sy-datum + 30
                        Price = '500.00'
                        CurrencyCode = 'EUR' ) )
      MAPPED DATA(mapped)
      FAILED DATA(failed)
      REPORTED DATA(reported).

    " Assertions
    cl_abap_unit_assert=>assert_initial( failed ).
    cl_abap_unit_assert=>assert_not_initial( mapped-booking ).
  ENDMETHOD.

  METHOD test_validate_customer_invalid.
    " RAP Operation mit ungültigem Kunden
    MODIFY ENTITIES OF ZI_Booking
      ENTITY Booking
        CREATE FIELDS ( CustomerId FlightDate )
        WITH VALUE #( ( %cid = 'CID1'
                        CustomerId = 'INVALID'
                        FlightDate = sy-datum + 30 ) )
      MAPPED DATA(mapped)
      FAILED DATA(failed)
      REPORTED DATA(reported).

    " Assertion: Validation muss fehlschlagen
    cl_abap_unit_assert=>assert_not_initial( failed-booking ).
  ENDMETHOD.
ENDCLASS.

ATC-Prüfung

Check	Beschreibung
☐	ATC ohne Priorität-1-Fehler
☐	Keine Level D Findings (direkte Tabellenzugriffe)
☐	Keine Level C Findings (nicht-klassifizierte Objekte)
☐	Check-Variante `ABAP_CLOUD_DEVELOPMENT` verwendet

Go-Live Checkliste

Check	Beschreibung
☐	Alle Unit Tests grün
☐	ATC ohne kritische Findings
☐	Performance-Tests durchgeführt
☐	End-to-End Test in QAS erfolgreich
☐	Fiori App funktional getestet
☐	Transport Request dokumentiert
☐	Rollback-Plan vorhanden
☐	Technische Dokumentation aktualisiert
☐	Anwender-Schulung durchgeführt

Schnellreferenz: Do’s & Don’ts

Do’s

✅ Nutze strict ( 2 ) in Behavior Definitions
✅ Setze @AccessControl.authorizationCheck: #CHECK
✅ Verwende Managed Scenario mit Draft wenn möglich
✅ Implementiere Feature Control für Actions
✅ Schreibe Unit Tests vor dem Transport
✅ Nutze Metadata Extensions für UI-Annotationen

Don’ts

❌ Keine direkten SELECTs auf SAP-Tabellen
❌ Kein SY-UNAME, nutze CL_ABAP_CONTEXT_INFO
❌ Keine CALL FUNCTION für Standard-BAPIs
❌ Keine COMMIT WORK im RAP-Kontext
❌ Keine hartcodierten Texte, nutze Message Classes
❌ Keine globalen Variablen in Behavior Classes

Fazit

Diese Checkliste deckt die wichtigsten Aspekte einer ABAP Cloud Implementierung ab. Nutze sie als Leitfaden für dein Projekt und passe sie bei Bedarf an deine spezifischen Anforderungen an.

Die fünf Phasen bieten einen klaren Ablauf:

Projektvorbereitung: Grundlagen schaffen
Datenmodell: Solide Basis mit CDS Views
RAP-Entwicklung: Geschäftslogik implementieren
Service & UI: Anwendung bereitstellen
Qualitätssicherung: Stabilität sicherstellen

Für vertiefende Informationen zu einzelnen Themen siehe:

3-Tier-Modell in ABAP Cloud - Architekturpattern
Clean Core Level-Konzept - API-Klassifizierung
RAP Grundlagen - RESTful Application Programming
ATC (ABAP Test Cockpit) - Statische Code-Analyse