RAP Code-Generierung: ADT Generator und Fiori Tools nutzen

Kategorie

RAP

Veröffentlicht

15. Feb. 2026

Autor

Die manuelle Erstellung aller RAP-Artefakte ist zeitaufwändig: Tabellen, CDS Views, Behavior Definitions, Service Bindings - das summiert sich schnell auf ein Dutzend Objekte. Mit den RAP-Generatoren in ADT und dem Fiori Elements App Generator können Sie diesen Prozess drastisch beschleunigen.

Warum Code-Generierung?

Ein vollständiger RAP-Stack mit Draft-Handling umfasst typischerweise:

1. Datenbanktabelle
2. Draft-Tabelle
3. Interface CDS View
4. Projection CDS View
5. Metadata Extension
6. Behavior Definition
7. Behavior Implementation
8. Service Definition
9. Service Binding

Diese neun Objekte manuell zu erstellen und korrekt zu verknüpfen kostet Zeit - besonders bei konsistenten Namenskonventionen und korrekter Syntax. Der RAP Generator erstellt all dies in wenigen Klicks.

RAP Generator in ADT

Der RAP Generator ist direkt in die ABAP Development Tools (ADT) integriert und generiert vollständige RAP-Business-Objekte aus Tabellendefinitionen.

Voraussetzungen

SAP S/4HANA 2022 oder neuer
SAP BTP ABAP Environment
ABAP Development Tools (Eclipse)

Schritt 1: Generator starten

Rechtsklick auf Datenbanktabelle
→ Generate ABAP Repository Objects
→ Generate RAP BO

Alternativ:

Rechtsklick auf Paket
→ New → Other ABAP Repository Object
→ Business Services → Generate RAP BO

Schritt 2: Tabelle auswählen

Wählen Sie die Haupttabelle für Ihr Business Object. Für unser Flugbuchungs-Beispiel:

Tabelle: ZFLIGHT_BOOK

Der Generator erkennt automatisch:

Schlüsselfelder
Administrative Felder (created_by, last_changed_at, etc.)
Assoziationen zu anderen Tabellen

Schritt 3: Generierungsoptionen

Option	Beschreibung	Empfehlung
Implementation Type	Managed oder Unmanaged	Managed für Standardfälle
Draft Handling	Mit oder ohne Draft	Mit Draft für Bearbeitungs-Apps
Data Model	Single oder Hierarchie	Hierarchie bei Parent-Child
Projection	Mit Projection Layer	Ja für UI-Anwendungen

Für das Flugbuchungs-Szenario:

Implementation Type: Managed
Draft Handling: Yes
Data Model: Single BO
Projection: Yes

Schritt 4: Namen konfigurieren

Der Generator schlägt Namen basierend auf der Tabelle vor:

Tabelle:           ZFLIGHT_BOOK
Interface View:    ZI_FLIGHTBOOK
Projection View:   ZC_FLIGHTBOOK
Behavior Def:      ZI_FLIGHTBOOK
Service Definition: ZUI_FLIGHTBOOK
Service Binding:   ZUI_FLIGHTBOOK_O4

Anpassen nach Ihren Namenskonventionen - konsistente Präfixe sind wichtig:

I_ = Interface Layer
C_ = Consumption/Projection Layer
UI_ = UI Service
_O4 = OData V4

Schritt 5: Generierung ausführen

Nach Klick auf “Finish” werden alle Objekte erstellt:

┌─────────────────────────────────────────────────────────┐
│              Generierte Objekte                          │
├─────────────────────────────────────────────────────────┤
│ ✓ ZDRAFT_FLIGHT_BOOK    (Draft-Tabelle)                 │
│ ✓ ZI_FLIGHTBOOK         (Interface CDS View)            │
│ ✓ ZI_FLIGHTBOOK         (Behavior Definition)           │
│ ✓ ZBP_I_FLIGHTBOOK      (Behavior Implementation)       │
│ ✓ ZC_FLIGHTBOOK         (Projection CDS View)           │
│ ✓ ZC_FLIGHTBOOK         (Projection Behavior)           │
│ ✓ ZUI_FLIGHTBOOK        (Service Definition)            │
│ ✓ ZUI_FLIGHTBOOK_O4     (Service Binding)               │
└─────────────────────────────────────────────────────────┘

Generierte Artefakte verstehen

Interface CDS View

Der Generator erstellt eine vollständige Interface View:

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Flight Booking'
define root view entity ZI_FlightBook
  as select from zflight_book
{
  key booking_uuid,
      flight_id,
      customer_id,
      booking_date,
      seat_number,
      status,
      price,
      currency_code,
      @Semantics.user.createdBy: true
      created_by,
      @Semantics.systemDateTime.createdAt: true
      created_at,
      @Semantics.user.lastChangedBy: true
      last_changed_by,
      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at,
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      local_last_changed
}

Wichtig: Die @Semantics-Annotationen werden automatisch für bekannte Feldnamen gesetzt.

Behavior Definition

managed implementation in class zbp_i_flightbook unique;
strict ( 2 );
with draft;

define behavior for ZI_FlightBook alias FlightBook
persistent table zflight_book
draft table zdraft_flight_book
etag master LocalLastChanged
lock master total etag LastChangedAt
authorization master ( global )
{
  field ( readonly )
    BookingUUID,
    CreatedBy,
    CreatedAt,
    LastChangedBy,
    LastChangedAt,
    LocalLastChanged;

  field ( numbering : managed )
    BookingUUID;

  create;
  update;
  delete;

  draft action Activate optimized;
  draft action Discard;
  draft action Edit;
  draft action Resume;
  draft determine action Prepare;
}

Behavior Implementation

Die generierte Klasse enthält Grundgerüste für lokale Handler:

CLASS lhc_FlightBook DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS:
      get_global_authorizations FOR GLOBAL AUTHORIZATION
        IMPORTING REQUEST requested_authorizations FOR FlightBook
        RESULT result.
ENDCLASS.

CLASS lhc_FlightBook IMPLEMENTATION.
  METHOD get_global_authorizations.
    " Hier eigene Berechtigungsprüfungen implementieren
  ENDMETHOD.
ENDCLASS.

Generierte Objekte anpassen

Nach der Generierung müssen Sie die Objekte typischerweise erweitern:

1. UI-Annotationen hinzufügen

In der Projection View oder Metadata Extension:

@UI.headerInfo: {
  typeName: 'Flugbuchung',
  typeNamePlural: 'Flugbuchungen',
  title: { value: 'FlightID' }
}

@UI.lineItem: [{ position: 10 }]
@UI.identification: [{ position: 10 }]
FlightID;

@UI.lineItem: [{ position: 20 }]
@UI.selectionField: [{ position: 10 }]
BookingDate;

2. Validierungen ergänzen

In der Behavior Definition:

define behavior for ZI_FlightBook alias FlightBook
...
{
  validation validateBookingDate on save { field BookingDate; }
  validation validateSeat on save { field SeatNumber; }
}

In der Implementation:

METHOD validateBookingDate.
  READ ENTITIES OF zi_flightbook IN LOCAL MODE
    ENTITY FlightBook
    FIELDS ( BookingDate )
    WITH CORRESPONDING #( keys )
    RESULT DATA(bookings).

  LOOP AT bookings INTO DATA(booking).
    IF booking-BookingDate < cl_abap_context_info=>get_system_date( ).
      APPEND VALUE #( %tky = booking-%tky ) TO failed-flightbook.
      APPEND VALUE #( %tky = booking-%tky
                      %msg = new_message_with_text(
                        severity = if_abap_behv_message=>severity-error
                        text     = 'Buchungsdatum muss in der Zukunft liegen' )
                      %element-BookingDate = if_abap_behv=>mk-on
      ) TO reported-flightbook.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

3. Custom Actions hinzufügen

define behavior for ZI_FlightBook alias FlightBook
...
{
  action confirmBooking result [1] $self;
  action cancelBooking result [1] $self;
}

Fiori Elements App Generator

Nach dem RAP-Backend können Sie mit dem Fiori Elements App Generator das Frontend generieren.

Im Business Application Studio

1. Command Palette öffnen (F1)
2. "Fiori: Open Application Generator" eingeben
3. Template wählen: "List Report Page" oder "Worklist"
4. Datenquelle: OData V4 Service auswählen
5. Service Binding eingeben: ZUI_FLIGHTBOOK_O4
6. Hauptentität wählen: FlightBook
7. Projektnamen vergeben

Generierte App-Struktur

flight-booking-app/
├── webapp/
│   ├── manifest.json       # App-Konfiguration
│   ├── Component.js        # UI5 Component
│   ├── index.html          # Startseite
│   └── localService/       # Mockdaten
├── package.json            # Dependencies
└── ui5.yaml               # Build-Konfiguration

manifest.json anpassen

Die wichtigsten Anpassungen:

{
  "sap.app": {
    "title": "{{appTitle}}",
    "description": "{{appDescription}}"
  },
  "sap.ui5": {
    "routing": {
      "targets": {
        "FlightBookList": {
          "options": {
            "settings": {
              "initialLoad": true,
              "variantManagement": "Page"
            }
          }
        }
      }
    }
  }
}

Generator vs. Manuell: Entscheidungshilfe

Szenario	Generator	Manuell
Neues Greenfield-Projekt	Empfohlen	Nein
Standard-CRUD-App	Empfohlen	Nein
Komplexe Hierarchien	Teilweise	Teils Anpassung nötig
Migration von Legacy	Nein	Ja, für Kontrolle
Unmanaged Szenario	Begrenzt	Meist manuell
Learning/Training	Nein	Ja, für Verständnis
Prototyping	Empfohlen	Nein

Wann Generator nutzen?

Empfohlen:

Neue Standardanwendungen
Managed Szenario mit Draft
Schnelle Prototypen
Konsistente Namenskonventionen wichtig

Manuell bevorzugen:

Unmanaged mit Legacy-Integration
Komplexe BO-Hierarchien
Spezielle Anforderungen an Struktur
Lernprojekte für RAP-Verständnis

Typische Anpassungen nach Generierung

Checkliste für generierte Objekte

Nach der Generierung anpassen:

□ Interface View
  □ @EndUserText.label für alle Felder
  □ Assoziationen zu anderen Entities
  □ @ObjectModel.text für Textfelder

□ Projection View
  □ @UI.headerInfo definieren
  □ @UI.lineItem für List Report
  □ @UI.identification für Object Page
  □ @UI.selectionField für Filter

□ Behavior Definition
  □ Validierungen hinzufügen
  □ Determinations für Defaultwerte
  □ Custom Actions definieren
  □ Berechtigungsprüfungen konfigurieren

□ Service Binding
  □ Publish aktivieren
  □ Preview im Browser testen

Best Practices

1. Generieren, dann Anpassen

Nutzen Sie den Generator als Startpunkt - nicht als fertiges Produkt:

Generator → Grundgerüst → Anpassung → Testing → Refinement

2. Namenskonventionen vorher festlegen

Bevor Sie generieren, definieren Sie Präfixe:

Z = Kundennamensraum
I_ = Interface Layer
C_ = Consumption Layer
A_ = Abstract Entity
UI_ = UI Service
_O4 = OData V4

3. Generator für Konsistenz

Auch bei manueller Entwicklung: Nutzen Sie den Generator einmal, um die erwartete Struktur zu sehen - dann können Sie konsistent nachbauen.

4. Versionskontrolle nutzen

Nach jeder Generierung direkt committen - so können Sie Änderungen nachverfolgen:

# Nach Generierung
git add .
git commit -m "feat: generated RAP BO for FlightBooking"

# Nach Anpassungen
git commit -m "feat: added validations and UI annotations"

Fazit

Die RAP-Generatoren sparen erheblich Zeit bei der Erstellung von Standardanwendungen. Der Schlüssel liegt im richtigen Einsatz:

Generator für Grundgerüst - Struktur und Boilerplate
Manuelle Anpassung - Business-Logik und UI-Feinschliff
Iteratives Vorgehen - Generieren, testen, anpassen

Für Einsteiger empfiehlt sich trotzdem, einmal alle Objekte manuell zu erstellen - so verstehen Sie, was der Generator im Hintergrund macht. Danach können Sie die Generatoren effektiv nutzen.

Weiterführende Artikel

RAP End-to-End Tutorial - Komplettes Tutorial mit manuellem Aufbau
SAP Fiori Elements UI - UI-Generierung aus Annotations
ADT Tipps & Tricks - Effiziente Entwicklung in Eclipse
RAP Managed vs Unmanaged - Die richtige Architekturentscheidung