Die Architektur von SAP RAP - Ein Blick auf die Schichten


Veröffentlichung:
Kategorie: Blog

Nach der Einführung in das RESTful Application Programming Model (RAP) widmen wir uns im zweiten Teil der Blogserie der Architektur von RAP. Diese basiert auf einem klar strukturierten Schichtenmodell, das die Entwicklung von cloud-fähigen, modularen und wartbaren Anwendungen erleichtert. Das Modell besteht aus drei Hauptschichten: der Persistenzschicht, der Geschäftslogikschicht und der Service-Expositionsschicht.

1. Die Persistenzschicht – Core Data Services (CDS)

Die Persistenzschicht bildet das Fundament jeder RAP-Anwendung. Hier werden die Datenmodelle definiert, die auf der SAP HANA-Datenbank gespeichert sind. Core Data Services (CDS) ermöglichen es, komplexe Datenstrukturen mit semantischen Anreicherungen, Assoziationen und Berechnungslogiken zu modellieren.

CDS definiert nicht nur die Struktur der Daten, sondern ermöglicht auch deren Verknüpfung und Aggregation über mehrere Tabellen hinweg.

Die wichtigsten Arten von CDS-Views sind:

  • Basis-Views (Interface-Views): Direkte Abbildung von Tabellen mit Rohdaten.

  • Composite-Views: Kombination mehrerer Basis-Views zur Erstellung komplexerer Datenmodelle.

  • Consumption-Views: Optimiert für die Service-Exposition mit speziellen Annotations für Fiori- oder OData-Services.

 

Beispiel für eine CDS-Definition:

define root view entity ZADV_I_FLIGHT

    as select from zadv_flight {

    key ID          : abap.int4,

    Name           : abap.string(50),

    Price          : abap.dec(10,2),

    Association [0..1] to ZADV_I_AIRLINE as _Airline on _Airline.AirlineID = zadv_flight.AirlineID

}

In diesem Beispiel wird nicht nur eine einfache Datenstruktur definiert, sondern auch eine Assoziation zu einer anderen Entität hergestellt. Dies ermöglicht es, zusammenhängende Daten effizient abzurufen.

2. Die Geschäftslogikschicht - Behavior Defininitions (BDEF) und Implementierungen (BIMP)

In der Geschäftslogikschicht wird definiert, wie mit den Daten gearbeitet wird. Behavior Definitions (BDEF) legen das Verhalten von Business-Objekten fest, während die eigentliche Implementierung in ABAP-Klassen (BIMP) erfolgt.

Wichtige Aspekte der Behavior Definitions:

  • CRUD-Operationen: Erstellen (Create), Lesen (Read), Aktualisieren (Update) und Löschen (Delete).

  • Validierungen: Sicherstellung der Datenintegrität vor dem Speichern.

  • Aktionen: Benutzerdefinierte Prozesse, z. B. Genehmigungsworkflows.

 

Beispiel einer CDS-Definition:

 

 define root view entity ZADV_I_FLIGHT
    as select from zadv_flight {
    key ID          : abap.int4,
    Name           : abap.string(50),
    Price          : abap.dec(10,2),
    Association [0..1] to ZADV_I_AIRLINE as _Airline on _Airline.AirlineID = zadv_flight.AirlineID
 }

 

In diesem Beispiel wird eine benutzerdefinierte Atkion confirmBlooking definiert, die beispielsweise eine Buchung bestätigen könnte.

3. Die Service-Expositionsschicht – Service Definitions & Service Bindings

Die oberste Schicht in RAP ist die Service-Expositionsschicht. Sie definiert, wie die Daten und Geschäftslogik nach außen bereitgestellt werden. Dies geschieht durch Service Definitions und Service Bindings, die OData-Services verfügbar machen.

 

Wichtige Konzepte:

  • Service Definition: Festlegung, welche Entitäten bereitgestellt werden.

  • Service Binding: Definition der Konsumierbarkeit (z. B. OData V2/V4).

  • OData-Anpassungen: Annotations zur Steuerung der Darstellung und Filteroptionen.

 

Beispiel einer Service Definition:

 

 define service ZADV_UI_FLIGHT {
    expose ZADV_I_FLIGHT;
 }

 

Durch ein entsprechendes Service Binding kann dieser Service für Fiori-Anwendungen oder andere Clients aktiviert werden.

Wie arbeiten die Schichten zusammen?

Der große Vorteil von RAP liegt in der klaren Trennung der Schichten:

  • CDS-Views modellieren die Datenstrukturen und definieren die logische Sicht auf die Daten.

  • Behavior Definitions steuern das Verhalten der Daten und implementieren die Geschäftslogik.

  • Service Definitions stellen die Daten über standardisierte Schnittstellen wie OData zur Verfügung.

Diese Architektur sorgt dafür, dass Änderungen an einer Schicht vorgenommen werden können, ohne die anderen zu beeinflussen. Dies erhöht die Wartbarkeit, Flexibilität und Skalierbarkeit von Anwendungen.

Vorteile des RAP-Schichtenmodells

  • Modularität: Jede Schicht kann unabhängig entwickelt und getestet werden.

  • Wartbarkeit: Klare Trennung von Daten, Logik und Service erleichtert die Pflege.

  • Wiederverwendbarkeit: Geschäftslogik und Datenmodelle können mehrfach genutzt werden.

  • Optimierte Performance: Direkte Verarbeitung von CDS auf der HANA-Datenbank.

  • Erweiterbarkeit: Anpassungen können mit minimalen Auswirkungen vorgenommen werden.

Fazit

Das Schichtenmodell von RAP bietet eine klare und strukturierte Grundlage für die Entwicklung moderner SAP-Anwendungen. Es ermöglicht nicht nur eine saubere Trennung von Verantwortlichkeiten, sondern auch eine hohe Flexibilität bei der Weiterentwicklung von Anwendungen.

In den kommenden Blogposts werden wir die einzelnen Komponenten von RAP und deren praktische Umsetzung detaillierter betrachten.

 

>> Jetzt Teil 3 "Best Practices und Stolpersteine in der RAP Entwicklung" lesen

Zurück