ABAP RAP Model

ABAP RESTful Application Programming Model

Einleitung & erstes Beispiel

(C) Brandeis Consulting📁

Evolution der Programmiermodelle

Darstellung der verschiedenen Versionen und Ansätze der OData Entwicklung mit ABAP von Begin bis heute

(C) Brandeis Consulting📁

Ziele von RAP

  • Einfache Entwicklung mit Fokus auf der Anwendungslogik, Stichwort "Entwicklungseffizienz"
  • Alle Standardfeatures sollen eingebaut sein oder wenig manuellen Aufwand verursachen:
    • CRUD Operatoren
    • Oberflächen
    • Sperren
    • Berechtigungsprüfungen
    • DRAFT Handling
    • Nummernvergabe
  • Klarer Programmfluss, was wann passiert
  • Integration mit DDic und CDS
  • Erweiterbarkeit
  • Nutzung der SAP Technologien
    • SAP HANA
    • FIORI
    • BTP-Enabled
(C) Brandeis Consulting📁

REST

Zustandslose (Web-)Anwendungen. In einer Anfrage oder Antwort sind jeweils alle relevanten Informationen für Server bzw. Client enthalten.

Der Server speichert keine Session, wie das z.B. bei WebDynpro der Fall war

Damit kann man sich auch jede Navigation im Browser speichern, da alle Infos in der URL stecken.

(C) Brandeis Consulting📁

OData

Für die Übertragung von Anwendungsdaten werden von RAP Services definiert, die das OData Protokoll nutzen.

Wir haben als RAP Entwickler eigentlich nichts direkt mit dem OData Protokoll zu tun!

Unterschiede zwischen OData V2 und OData V4

Merkmal OData V2 OData V4
Standardisierung Weniger strikte Standardisierung. Bessere Standardisierung, konform mit Open Data Protocol.
JSON-Format Verwendet ein redundanteres JSON-Format. Kompakteres JSON-Format für höhere Effizienz.
Batch-Verarbeitung Begrenzte Flexibilität und Funktionalität. Verbesserte Batch-Verarbeitung.
Filterfunktionen Grundlegende Filterlogik. Erweiterte Filterfunktionen (z. B. $filter mit komplexeren Ausdrücken).
Asynchrone Verarbeitung Eingeschränkt möglich. Besser für asynchrone Vorgänge geeignet.
Versionierung Keine Versionierung innerhalb eines Services. Unterstützung von Versionierung innerhalb eines OData-Service.
(C) Brandeis Consulting📁

Fiori Elements

Aus dem Backend mit Annotationen steuerbare Oberflächen. Entweder mit wenigen Floorplans in eigenen Anwendungen, wie im RAP. Oder als Komponenten in von Hand gebauten UI5 Anwendungen.

  • Generiert UIs auf Basis von OData-Services und Metadaten (z. B. CDS-Annotationen).
  • Fokus auf Wiederverwendbarkeit und konsistentes UX-Design.

Typische Floorplans:

List Report

List Report

Object Page

List Report

(C) Brandeis Consulting📁

SAP LUW (Logical Unit of Work)

Transactional Model and the SAP LUW

  • Definition: Eine logische Einheit von Transaktionen, die vollständig erfolgreich sein muss oder vollständig rückgängig gemacht wird.
    • Verhindert inkonsistente Daten in der Datenbank.
    • Unterstützt das Prinzip der ACID-Eigenschaften:
      • Atomicity: Alles oder nichts.
      • Consistency: Datenintegrität wird gewährleistet.
      • Isolation: Gleichzeitige Transaktionen stören sich nicht.
      • Durability: Erfolgreich abgeschlossene Änderungen bleiben bestehen.
(C) Brandeis Consulting📁

RAP Transaktionsmodell

Innerhalb eines Serveraufrufes gibt es immer die folgenden Verarbeitungsphasen:

Interaktionsphase

Änderungen werden im Arbeitsspeicher (Transactional Buffer) gehalten.

  • Ändern
  • Anlegen
  • Löschen
  • Aktionen

Speichersequenz

Datenänderungen werden in einer konsistenten Reihenfolge gespeichert.

  • Finalize
  • Prüfungen
  • Speichern
  • Commiten
(C) Brandeis Consulting📁

Integration: SAP LUW und RAP

  • RAP orientiert sich am klassischen SAP LUW, automatisiert jedoch viele Schritte:
    • Verteilte Steuerung: SAP LUW bleibt bestehen, aber RAP übernimmt die Transaktionslogik.
    • Consistency: RAP validiert und speichert Daten gemäß den SAP LUW-Prinzipien.
    • Flexibilität: Entwickler definieren Verhalten in der Behavior Implementation (z. B. Validierungen, Autorisierungen).
(C) Brandeis Consulting📁

Architekturübersicht

(C) Brandeis Consulting📁

Was ist ein Business Object (BO)

Business Object

  • Definition:
    • Ein Business Object (BO) ist eine zentrale Einheit im SAP Restful ABAP Programming Model (RAP), die ein Geschäftskonzept oder einen Prozess (z. B. Verkaufsauftrag, Anfrage) abbildet.
  • Bestandteile:
    • Datenmodell: Struktur der Daten, z. B. Tabellen und Views.
    • Verhalten (Behavior): Geschäftslogik, z. B. Aktionen, Validierungen und Berechtigungsprüfungen.
    • Service: Bindet das BO an ein Protokoll und definiert welche Teile des BO freigegeben werden
    • Transaktionsmanagement: Verwaltung von Änderungen im Kontext des SAP LUW.

Business Object

(C) Brandeis Consulting📁

Projektionen

  • Definition:
    • Projektionen sind benutzerdefinierte Sichten auf Datenmodelle (Business Objects) im RAP.
    • ermöglichen die Anpassung und Darstellung von Daten je nach Anwendungsfall.
  • Ziele:
    • Vereinfachung von Datenmodellen für spezifische Szenarien.
    • Trennung von Backend-Logik und UI-spezifischen Anforderungen.
    • Wiederverwendbarkeit von Datenmodellen in unterschiedlichen Anwendungen.

Projektion

In den meisten Übungen verzichten wir auf die Projektionsschicht, damit alles übersichtlicher bleibt.
(C) Brandeis Consulting📁

Namenskonvention für mehrschichtige CDS Views

virtuelles Datenmodell

Im SAP RAP Model werden CDS Views und Behavior Definitions in verschiedene Layer unterteilt, um eine klare Trennung von Verantwortlichkeiten und eine bessere Wartbarkeit zu gewährleisten:

Untereste Ebene: I_ Interface-View

Der I-View enthält das eigentliche Geschäftsobjekt bestehend aus den genannten Artefakten.
Aufgaben dieser Schicht:

  • Umbenennung der Felder
  • Allgemeingültige Annotationen, z.B. Währungen, Semantics, ...

Mittlerer Ebene: R_ Reuse-View

  • RAP-spezifisch, Datenmodellierung des Business Objekt, Gesamtmenge aller Daten

Oberste Ebene: C_ Consumption-View

Der C-View ist eine spezialisierte Projektion des Geschäftsobjektes für einen Anwendungsfall. Sowohl CDS-View als auch zugehöriges Behavior müssen angelegt werden. Falls zusätzliche Logik definiert wird, muss auch eine passende Implementierung hinzugefügt werden.

(C) Brandeis Consulting📁

Datenmodell - Entitäten

Die Basis für alle RAP Anwendungen bildet das Datenmodell. Es basiert auf DB-Tabellen, die durch CDS Views gekapselt und verknüpft werden.

Wurzel-Entitäten

Bei Wurzel-Entitäten handelt es sich um Objekte, die eigenständig existieren können. Beispielsweise Kunden, Aufträge oder Materialien. Sie bestehen häufig auch aus

Kind-Entitäten

Kind-Entitäten sind Bestandteil einer Wurzel-Entität. Sie gehören als Teil dieser Entität fest dazu und können nicht ohne ihre Wurzel-Entität existieren. Häufig haben Sie in den Datenbanktabellen den gleichen Teil-Schlüssel oder eine Fremdschlüsselbeziehung.
Beispiele:

  • Positionen zu Aufträgen
  • Adressen zu Kunden
(C) Brandeis Consulting📁

Verhaltensdefinition (Behavior)

Behvior
Mit einer Verhaltensdefinition werden die Aktionen beschrieben, die das Objekt machen kann:

  • Lesen
  • Anlegen
  • Ändern
  • Löschen
  • Filtern
  • Suchen
  • Validierungen
  • Berechnungen

Es werden hier auch viele Standardimplementierungen des Managed-Szenarios gesteuert, z.B. die Sperren.

(C) Brandeis Consulting📁

Namenskonvention in diesem Training

Grundsätzlich gelten die Konventionen aus dem Buch Clean ABAP. Da im RAP Bereich viele Objekte aufeinander aufbauen, muss man einerseits einen durchgängigen Namen verwenden, im folgenden mit <Name> bezeichnet, andererseits die Objekte bzw. Objekttypen sauber und einheitlich unterscheiden. Das bringt uns wieder zur umstrittenen ungarischen Notation, die an dieser Stelle aber die beste Option ist. Die Notation orientiert sich an der SAP Dokumentation zu RAP.

Ein guter <Name>

Die Suffix _R,_M,_D,_U,_C, aus der SAP Doku sind in der echten Welt nicht notwendig, da hier die Szenarien (read-only, managed, ddraft, unmanaged, service consumption) auf den gleichen Tabellen implementiert wurden.

Falls Ihr einen Präfix-Namensraum verwendet, diesen statt dem führenden Z verwenden.

(C) Brandeis Consulting📁

Namenskonventionen - Objekttypen

Objekttyp Konvention Beschreibung
DB-Tabelle ZA_<Name> Aktive Daten
DB-Tabelle ZD_<Name> Draft Daten
CDS View ZI_<Name> Interface View
CDS View ZR_<Name> Basis View
CDS View ZC_<Name> Projection View für den Consumption layer
Behaviour Definition Wie der zugehörige CDS View
Service Defintion Z_<Name>
Service Binding ZUI_<Name> Für UI Services
Service Binding ZAPI_<Name> Für API Services
ABAP Klasse ZBP_<Name> Klasse für den Behaviour Pool
Lokale Klasse LHC_ Lokale Handler Klasse
Lokale Klasse LSC_ Lokale Saver Klasse
# Datenmodell für die Beispiele

(C) Brandeis Consulting📁

Links

(C) Brandeis Consulting📁

Fehlersituationen

  • Service nach Änderung nicht aktualisiert ==> Binding Version hochzählen oder neu anlegen
  • Assoziierter View nicht sichtbar ==> View in der Service-Definition exponieren
  • Keine Berechtigung im Browser, noch vor Anmeldung ==> Anderen Browser verwenden, z.B. Chrome
  • Navigation von User/Aufgabenliste zur einzelnen Aufgabe wurde nicht angezeigt bzw. war nicht möglich. ==> Browser neu starten hatte geholfen.
(C) Brandeis Consulting📁