Von klassischem ABAP zu ABAP Cloud: Ein praktischer Leitfaden

Der Übergang von klassischem ABAP zu ABAP Cloud repräsentiert einen fundamentalen Wandel in den SAP-Entwicklungspraktiken. Während ABAP das Fundament bleibt, führt ABAP Cloud Einschränkungen und neue Muster ein, die Entwickler zu einer Anpassung ihres Ansatzes zwingen. Dieser praktische Leitfaden hilft Entwicklern, diesen Übergang zu navigieren, und bietet konkrete Anleitungen zur Konvertierung gängiger klassischer ABAP-Muster in ABAP Cloud-Äquivalente.

Den Übergang verstehen

ABAP Cloud ist keine neue Sprache, sondern eine eingeschränkte Version von ABAP, die für Cloud-Deployment und langfristige Wartbarkeit konzipiert ist.

Was sich ändert

Der Zugriff ist auf freigegebene APIs beschränkt, bestimmte ABAP-Statements sind nicht verfügbar, direkter Datenbanktabellenzugriff wird durch CDS-Views ersetzt, klassische Dynpros und Selektionsbildschirme werden nicht unterstützt, und einige Verarbeitungsmuster funktionieren anders.

Was gleich bleibt

Die Kern-ABAP-Syntax und Datentypen bleiben erhalten, ebenso das objektorientierte Programmiermodell, interne Tabellen und Datenverarbeitung, moderne ABAP-Features wie Ausdrücke und Inline-Deklarationen sowie das ABAP Unit-Test-Framework.

Der Entwickler-Mindset-Shift

Der Übergang zu ABAP Cloud erfordert einen Wechsel von "Ich kann auf alles zugreifen" zu "Ich nutze definierte Schnittstellen". Diese Einschränkung ermöglicht bessere Architektur, verbesserte Testbarkeit und nachhaltigen Code.

Transformation des Datenzugriffs

Datenzugriffsmuster erfordern die signifikantesten Änderungen.

Von Tabellen zu CDS-Views

Das klassische Muster des direkten SELECT von Datenbanktabellen wird im ABAP Cloud-Muster zu SELECT von freigegebenen CDS-Views. Statt SELECT von MARA mit Materialfilter nutzt man SELECT von I_Product mit dem Product-Feld. Anstelle komplexer JOINs über mehrere Tabellen wie KNA1 und KNVV verwendet man optimierte Views wie I_Customer, die die benötigten Daten bereits zusammenführen.

Die richtige CDS-View finden

Strategien zum Finden geeigneter Views umfassen die Nutzung des Released Objects Browser in ADT, die Suche nach Geschäftskonzept (Customer, Material, SalesOrder), das Suchen nach dem I_-Präfix für Interface Views für grundlegenden Datenzugriff und dem C_-Präfix für Consumption Views für spezifische Anwendungsfälle sowie die Konsultation der SAP-Dokumentation für empfohlene Views.

Umgang mit fehlenden Views

Wenn keine geeignete View existiert, erstellen Sie eigene CDS-Views, die freigegebene Views als Datenquellen nutzen, komponieren Sie mehrere Views durch Assoziationen, erstellen Sie niemals Views direkt auf Datenbanktabellen und fordern Sie API-Freigabe von SAP für kritische Lücken an.

Transformation der Geschäftslogik

Geschäftslogik-Muster erfordern ebenfalls Anpassung.

Von Funktionsbausteinen zu Klassen

Das klassische Muster CALL FUNCTION für BAPIs wird zum ABAP Cloud-Muster mit freigegebenen Klassen anstelle von Funktionsbausteinen. Suchen Sie nach freigegebenen Klassen mit CL_-Präfix und nutzen Sie RAP-Services für CRUD-Operationen.

Von User-Exits zu BAdIs

Das klassische Muster der Implementierung von SMOD/CMOD User-Exits wird zum ABAP Cloud-Muster mit freigegebenen BAdIs für Standard-Prozesserweiterung. Implementieren Sie über den ADT BAdI-Implementierungsassistenten und nutzen Sie filterbasierte Aktivierung für bedingte Ausführung.

Von FORM zu Methode

Das klassische Muster von FORM-Routinen mit PERFORM-Aufrufen wird zum ABAP Cloud-Muster mit Instanzmethoden in Klassen, statischen Methoden für Utility-Funktionen und ordnungsgemäßer Kapselung und Sichtbarkeit.

Transformation der Benutzeroberfläche

Die UI-Entwicklung ändert sich am dramatischsten.

Von Dynpros zu Fiori

Das klassische Muster mit Module-Pool-Programmen mit Screens und PAI/PBO-Modulen wird zum ABAP Cloud-Muster mit RAP-basierten Backend-Services, Fiori Elements für Standard-UI-Muster und benutzerdefiniertem SAPUI5 für spezialisierte Anforderungen.

Von Selektionsbildschirmen zu Fiori-Parametern

Das klassische Muster mit PARAMETERS und SELECT-OPTIONS auf Selektionsbildschirmen wird zum ABAP Cloud-Muster mit Filter Bar in Fiori List Report, Variantenmanagement für gespeicherte Selektionen und URL-Parametern für Initialwerte.

Von ALV zu Fiori-Tabellen

Das klassische Muster mit CL_SALV_TABLE oder Funktionsbaustein-ALV wird zum ABAP Cloud-Muster mit Fiori Elements List Report, RAP-Service als Datenquelle und Annotationen für Spaltenkonfiguration.

Gängige Statement-Transformationen

Viele spezifische Statements brauchen Transformation.

String-Operationen

Klassisches CONCATENATE a b INTO c wird zu c = a && b als String-Ausdruck. TRANSLATE text TO UPPER CASE wird zu text = to_upper( text ). CONDENSE text wird zu text = condense( text ).

Typ-Konvertierungen

Klassisches MOVE source TO target wird zu target = source. WRITE number TO string wird zu string = |{ number }| als String-Template.

Interne Tabellen-Operationen

Klassisches READ TABLE itab WITH KEY field = value wird zu line = itab[ field = value ] als Table Expression. LOOP AT itab WHERE bleibt mit moderner Syntax LOOP AT itab INTO DATA(line) WHERE field = value.

Architekturmuster

ABAP Cloud fördert bessere Architektur.

Die RAP-Architektur

RESTful ABAP Programming model für Business Objects besteht aus CDS-Views für das Datenmodell, Behavior Definition für erlaubte Operationen, Behavior Implementation für Geschäftslogik, Service Definition für die Exposition und Service Binding für das Protokoll (OData).

Managed vs Unmanaged

RAP bietet zwei Implementierungsmuster. Managed: Das Framework handhabt CRUD-Operationen, weniger Code erforderlich, am besten für Standard-Persistenz-Szenarien. Unmanaged: Der Entwickler kontrolliert alle Operationen, mehr Flexibilität, am besten beim Wrapping existierender Logik.

Service-Layering

Ordnungsgemäßes Service-Layering in ABAP Cloud umfasst die Datenschicht mit CDS-Views mit Zugriffskontrollen, die Geschäftslogik-Schicht mit Behavior Implementations, die Service-Schicht mit OData oder API-Exposition und die Consumer-Schicht mit Fiori oder externen Systemen.

Migrations-Workflow

Ein systematischer Ansatz zur Code-Migration.

Schritt 1: Analyse

Führen Sie ATC aus, um nicht-compliant Code zu identifizieren, kategorisieren Sie Findings nach Typ, schätzen Sie Aufwand für jede Kategorie und priorisieren Sie basierend auf Geschäftswert.

Schritt 2: Design

Planen Sie die Zielarchitektur, identifizieren Sie erforderliche CDS-Views, designen Sie RAP-Services falls nötig und planen Sie den UI-Migrationsansatz.

Schritt 3: Implementierung

Erstellen Sie Infrastruktur (Views, Services), migrieren Sie Logik inkrementell, bewahren Sie Verhaltensäquivalenz und führen Sie kontinuierlich Tests aus.

Schritt 4: Validierung

Führen Sie ATC aus, um Compliance zu verifizieren, führen Sie Regressionstests aus, validieren Sie mit Geschäftsanwendern und deployen Sie über den Standardprozess.

Häufige Herausforderungen

Herausforderung: Komplexe Report-Programme

Lösungsansatz: Separieren Sie Datenabfrage von Präsentation, erstellen Sie CDS-Views für Datenselektion, implementieren Sie Berechnungslogik in ABAP-Klassen und präsentieren Sie über Fiori Analytical Apps.

Herausforderung: Schwere Datenbankverarbeitung

Lösungsansatz: Verlagern Sie Berechnungen wo möglich in die CDS-View-Schicht, nutzen Sie AMDP für komplexe Datenbanklogik, optimieren Sie durch CDS-Annotationen und erwägen Sie asynchrone Verarbeitung für schwere Operationen.

Herausforderung: Integration mit nicht freigegebenen APIs

Lösungsansatz: Erstellen Sie Wrapper-Klassen, die nicht freigegebene Aufrufe isolieren, designen Sie Interfaces, die verschiedene Implementierungen nutzen könnten, planen Sie Migration wenn freigegebene Alternativen eintreffen und dokumentieren Sie Abhängigkeiten zur Verfolgung.

Best Practices Zusammenfassung

Für Datenzugriff

Verwenden Sie immer CDS-Views, niemals Tabellen. Bevorzugen Sie freigegebene SAP-Views vor eigenen. Erstellen Sie eigene Views auf Basis freigegebener Views. Nutzen Sie Assoziationen für verwandten Datenzugriff.

Für Geschäftslogik

Nutzen Sie objektorientiertes Design. Bevorzugen Sie freigegebene Klassen vor Funktionsbausteinen. Implementieren Sie ordnungsgemäße Fehlerbehandlung. Designen Sie für Testbarkeit.

Für Benutzeroberfläche

Beginnen Sie mit Fiori Elements. Customizen Sie zuerst durch Annotationen. Nutzen Sie Custom Code nur wenn nötig. Befolgen Sie Fiori Design Guidelines.

Für den Entwicklungsprozess

Führen Sie häufig ATC-Prüfungen aus. Schreiben Sie Tests vor oder während der Entwicklung. Reviewen Sie Änderungen auf Compliance. Dokumentieren Sie Migrationsentscheidungen.

Fazit

Der Übergang von klassischem ABAP zu ABAP Cloud ist substanziell, aber machbar. Erfolg kommt durch das Verständnis der zugrundeliegenden Prinzipien - nutzen Sie definierte Schnittstellen, adoptieren Sie moderne Muster und designen Sie für Wartbarkeit.

Die Einschränkungen von ABAP Cloud, die sich initial limitierend anfühlen mögen, führen letztendlich zu besserem Code. Freigegebene APIs sind getestet und unterstützt. CDS-Views bieten optimierten Datenzugriff. RAP-Services ermöglichen moderne Anwendungen. Die von ABAP Cloud geforderte Disziplin produziert nachhaltigere Lösungen.

Gehen Sie den Übergang systematisch an, bauen Sie Fähigkeiten inkrementell auf und nutzen Sie die verfügbaren Tools. Die Investition in das Erlernen von ABAP Cloud zahlt sich durch Code aus, der Upgrades übersteht, moderne Anwendungen unterstützt und Ihre Organisation für SAPs Cloud-First-Zukunft positioniert.