Modernes Programmiermodell speziell für die Entwicklung von Geschäftsanwendungen in SAP
RAP (ABAP RESTful Application Programming Model) ist ein Programmiermodell von SAP, das speziell für die Abbildung von Geschäftsanwendungen im SAP S/4HANA entwickelt wurde. Es ermöglicht die Erstellung von End-to-End-Anwendungen, die auf dem ABAP-Stack laufen und auf den Prinzipien wie RESTful Services und der Nutzung von SAP Fiori basieren.
RAP wird u.a. verwendet, um moderne Benutzeroberflächen mit SAP Fiori zu entwickeln, die eine verbesserte Benutzererfahrung bieten. RAP ist besonders nützlich für die Entwicklung von Anwendungen in der SAP Cloud Plattform, da es cloud-native Entwicklungsparadigmen unterstützt. Zudem wird bei RAP keine bis kaum SAPUI5 Erfahrung benötigt. Entwickler die bereits ABAP oder CDS-Views beherrschen haben somit einen vereinfachten Einstieg in die Entwicklung von Fiori Apps. Gleichzeitig kann man mit RAP unmanaged aber auch die Kontrolle behalten und alle Inhalte eigenständig entwickeln.
RAP: Vorteile und Nachteile
RAP (ABAP RESTful Application Programming Model) ist ein Programmiermodell von SAP, das speziell für die Abbildung von Geschäftsanwendungen im SAP S/4HANA entwickelt wurde. Es ermöglicht die Erstellung von End-to-End-Anwendungen, die auf dem ABAP-Stack laufen und auf den Prinzipien wie RESTful Services und der Nutzung von SAP Fiori basieren.
| Vorteile | Nachteile |
|---|---|
| RAP bietet Usability und Konsistenzprüfung an bei Prüfungen von Feldern und Sperrungen an, die in SAPUI5 Apps vom Entwickler per Hand entwickelt werden müssten | RAP App bieten die Möglichkeit List und Object Pages zu erstellen und haben dementsprechend ihre Grenzen. |
| Es bietet bei managed RAP Apps automatisierte CRUD-Methoden | Es sind nicht alle Controls verfügbar und es besteht keine Möglichkeit Custom Controls zu erstellen. |
| Leichte Erweiterbarkeit | Weniger Flexibilität |
| Einfache Lösung für die Backend-Entwicklung. | Nicht alle Funktionen sind auf allen Systemen verfügbar (cloud, on-premise) und schränkt somit den Einsatz stark ein, ohne eine Alternative zu bieten. |
| Durch die Nutzung von Core Data Services (CDS) und standardisierten Annotations können Entwickler konsistente und wiederverwendbare Geschäftslogik erstellen. | |
| Integrierte Sicherheitsmechanismen, wie Autorisierung und Authentifizierung, die es einfacher machen, sichere Anwendungen zu entwickeln. |
RAP nutzt moderne Entwicklungsparadigmen wie RESTful Services, die eine einfachere Integration und bessere Skalierbarkeit ermöglichen. Durch die Nutzung von Core Data Services (CDS) und standardisierten Annotations ermöglicht RAP eine konsistente und wiederverwendbare Datenmodellierung und Geschäftslogik. Es ist möglich mit UI Annotationen und RAP managed eine App mit simplen CRUD-Methoden innerhalb von kürzester Zeit hochzuziehen.
RAP bietet flexible Erweiterungsoptionen, die es Entwicklern ermöglichen, Anwendungen an spezifische Geschäftsanforderungen anzupassen, ohne den SAP Kern zu verändern.
RAP Unmanaged
In unmanaged Szenarien müssen die Methoden manuell implementiert werden, im Gegensatz zu managed RAP Apps, wo einige Methoden automatisch vom Framework bereitgestellt werden.
Der Entwickler ist verantwortlich für die Implementierung der gesamten Logik, einschließlich der Verwaltung des Transaktionspuffers und der Speichersequenz. Dies bietet mehr Flexibilität und Kontrolle, insbesondere bei der Migration bestehender ABAP-Codes und Funktionen.
Der Aufbau von mananged und unmanaged Apps ist im Prinzip gleich, jedoch gibt es für die Entwickler unterschiedliche Möglichkeiten:
Individuelle Logik: In unmanaged RAP schreiben Entwickler ihre eigene benutzerdefinierte Logik zur Datenabfrage, -manipulation und -persistenz. Dies bietet mehr Flexibilität bei der Verarbeitung und Speicherung von Daten.
Direkter Datenbankzugriff: Entwickler können direkt auf die Datenbanktabellen zugreifen und ihre eigenen Datenmodelle mithilfe von Core Data Services (CDS)-Views oder ABAP-Klassen definieren.
Explizite Service-Definition: Im Gegensatz zu managed RAP, mit der automatischen Generierung von Servicedefinitionen auf Basis von Annotationen, erfordert unmanaged RAP, dass Entwickler die Serviceimplementierungen und Verhaltensweisen explizit definieren.
Manuelle CRUD-Operationen: CRUD (Create, Read, Update, Delete)-Operationen müssen in unmanaged RAP explizit implementiert werden, was den Entwicklern vollständige Kontrolle darüber gibt, wie Daten verwaltet werden.
Integration mit bestehenden Systemen: Unmanaged RAP wird oft verwendet, wenn eine Integration mit bestehenden Systemen erforderlich ist oder wenn komplexe Geschäftslogik vorhanden ist, die mit dem managed Ansatz schwer umzusetzen ist.
Flexibilität: Entwickler haben mehr Freiheit, komplexe Validierungsregeln, Autorisierungsprüfungen und andere benutzerdefinierte Anforderungen direkt in der Anwendungslogik zu implementieren.
Aufbau: Damit die Funktionen Implementiert werden können, werden einige Methoden vom System gestellt. Diese sind in zwei Klassen aufgeteilt und im folgendem beschrieben.
- Handler Class: Handhabt Daten vom Frontend. Die Methoden: Bekannt als Interaktionsmethoden. Diese Methoden übergeben die Transaktionspufferdaten zur Verarbeitung an die Saver Class.
- CRUD: Create, Read, Update, Delete
- LOCK:
- RBA_<Name>: (Read by Association) Bereitet Daten basierend auf Assoziationen vor und liest sie.
- CBA_<Name>: (Create by Association) Bereitet Daten basierend auf Assoziationen vor und erstellt sie
- get_instance_authorizations
- Saver Class: Anschließender Umgang mit den Daten (nach dem Aufruf einer Method in der Handler Klasse)
- Finalize: Führt abschließende Berechnungen am Datenmodell durch und bietet die letzte Möglichkeit, Daten zu ändern.
- Check_Before_Save: Überprüft die Datenkonsistenz und kann zusätzliche Validierungen enthalten.
- Save: Speichert die Transaktionspufferdaten in der Datenbank.
- Cleanup: Löscht den Transaktionspuffer.
- Cleanup_Finalize: Wird nur aufgerufen, wenn bei Check_Before_Save Fehler auftreten.
Ablauf: Der Ablauf durch die Saver Class verläuft immer gleich:
Methodenreihenfolge in der Saver Class:
- Finalize: Wird ausgeführt, nachdem mindestens ein erfolgreicher Datensatz durchlaufen wurde.
- Check_Before_Save: Validiert die Daten vor dem Speichern.
- Save: Speichert die Daten nur, wenn die vorherigen Schritte erfolgreich waren.
- Cleanup: Löscht die Pufferdaten.
- Cleanup_Finalize: Optional, wird nur ausgeführt, wenn bei Check_Before_Save Fehler festgestellt wurden.
BOPF und RAP
Durch RAP sind viele Möglichkeiten von BOPF in den behavior Definition enthalten. Die Modulariät von Apps und eine Widerverwendbarkeit von Fiori Anwendungen ist damit möglich. Durch RAP unmanged gelingt deren individuelle Steuerung. In der Entwicklung hat man somit Entscheidung: möchte man die Entwicklung selber in die Hand oder sich die Methoden automatisieren lassen. RAP bietet eine umfassende Plattform für die Entwicklung von Geschäftsanwendungen, die früher durch BOPF unterstützt wurden, und ergänzt diese durch moderne Entwicklungspraktiken und Tools.
Haben Sie Fragen?
Nehmen Sie Kontakt zu uns auf