Was ist RESTful Application Programming (RAP)?
Das von SAP entwickelte ABAP RESTful Application Programming Model baut vollständig auf der Sprache ABAP auf und folgt dem Framework des Representational State Transfer (REST), um Anwendungen in einer Client-Server-Architektur mit einer einheitlichen Schnittstelle für die Ressourcenmanipulation zu erstellen.
Der Hauptzweck von RAP besteht darin, Entwicklern die Möglichkeit zu geben, effizient Cloud-fähige Geschäftsanwendungen zu erstellen, die verschiedene Geschäftstransaktionen in Form von OData-Standarddiensten verwalten, oder Erweiterungen für bestehende Anwendungen zu entwickeln, ohne den bestehenden Standardcode ändern zu müssen. Dies ermöglicht die End-to-End-Entwicklung von der Datenmodellierung bis zur Service-Exposition und Kompaktheit mit SAP Fiori UX.
RAP unterstützt die Entwicklung für verschiedene SAP-Plattformen, darunter SAP BTP ABAP zur Erstellung von Cloud-nativen Anwendungen und Erweiterungen sowie SAP S/4HANA Cloud (Public und Private Editions), das kundenspezifische Entwicklungen ermöglicht, die mit den kontinuierlichen Innovationen und Upgrade-Zyklen der Cloud kompatibel sind. RAP ist seit dem Release 1909 für On-Premise-Implementierungen von SAP S/4HANA verfügbar und ermöglicht es Kunden, Anwendungen mit modernen Entwicklungspraktiken zu erstellen und zukunftssichere Anwendungen zu entwickeln.
RAP spielt eine zentrale Rolle im ABAP-Cloud-Entwicklungsmodell für transaktionale Anwendungen. Es nutzt Core Data Services (CDS) zur Definition von Datenstrukturen und Ansichten, stellt Mechanismen zur Implementierung von Geschäftslogiken bereit und gewährleistet die Datenintegrität während Transaktionen.
Warum RESTful-Anwendungsprogrammierung lernen?
Entwicklung der Anforderungen an Geschäftsanwendungen
RAP ist nicht nur ein neues Entwicklungsframework, sondern auch das strategische Programmiermodell von SAP, mit dem das moderne Paradigma zur Entwicklung von Unternehmensanwendungen innerhalb des SAP-Ökosystems umgesetzt wird.
Moderne Geschäftsanwendungen benötigen unmittelbare Einblicke in ihre Betriebsdaten, um die Entscheidungsfindung zu unterstützen. Infolgedessen werden analytische Funktionen in transaktionale Anwendungen eingebettet, um Erkenntnisse zu gewinnen, ohne den Kontext zu wechseln. RAP ermöglicht die direkte Integration von Daten in das Training und die Analyse von KI-Modellen, wodurch der Bedarf an komplexer Datenreplikation und -verarbeitung reduziert wird.
RAP ist für die SAP HANA-Datenbank optimiert. Es nutzt das volle Potenzial der In-Memory-Verarbeitungsfunktionen und führt Operationen wie Verknüpfungen, Aggregationen und komplexe Berechnungen deutlich schneller aus, während sie bei herkömmlichen Datenbanken früher Leistungsengpässe darstellten.
Mit SAP Fiori wurde eine neue Designsprache und ein neues Paradigma für das Benutzererlebnis in SAP-Anwendungen eingeführt, die sich durch Einfachheit, Einheitlichkeit und rollenbasierten Zugriff auszeichnen. RAP ermöglicht es Entwicklern, Geschäftsobjekte als OData-Dienste darzustellen, was eine nahtlose Integration mit Fiori-Elementen und eine einheitliche Erfahrung über verschiedene Geräte hinweg ermöglicht.
RAP wurde unter Berücksichtigung von Cloud-Prinzipien entwickelt, und die Anwendungen sind von Haus aus für die BTP-ABAP-Umgebung von SAP optimiert, sodass sowohl In-App- als auch Side-by-Side-Erweiterungen möglich sind. Dies macht es ideal für Cloud-native und hybride Implementierungen.
Erwartungen der Endnutzer
Fiori UX nutzt direkt RAP-OData-Dienste und bietet so eine einheitliche Benutzererfahrung über verschiedene Geräte hinweg, wobei der Kontext erhalten bleibt. Das RAP zugrunde liegende Design fördert die Zustandslosigkeit, sodass die Sitzungen der Benutzer von jedem Gerät, auf dem sie zuletzt verlassen wurden, problemlos auf dem nächsten Gerät fortgesetzt werden können.
Produktqualitäten (sofort einsatzbereit)
Die RAP-Prinzipien ermöglichen es Entwicklern, mehrere kritische Eigenschaften standardmäßig hinzuzufügen, ohne dass zusätzlicher Aufwand nach der eigentlichen Entwicklung erforderlich ist:
- Skalierbarkeit: Die zustandslose Architektur von RAP und die optimierte Interaktion mit SAP HANA ermöglichen eine inhärente Skalierbarkeit, sodass Anwendungen verteilt eingesetzt und in Cloud-Umgebungen einfach skaliert werden können.
- Prüfbarkeit: RAP bietet integrierte Tools und Techniken zum Testen der Anwendungslogik und zur Trennung von Logikebenen, wodurch Einheitentests und Verhaltensdefinitionen wartbar werden.
- Erweiterbarkeit: RAP ermöglicht es Entwicklern, genau definierte Erweiterungspunkte in ihren Anwendungen zu erstellen, sodass Änderungen und neue Funktionen hinzugefügt werden können, ohne dass der Quellcode geändert werden muss.
- Support-Fähigkeit: Die entwickelten Anwendungen lassen sich nach der Bereitstellung leicht mit detaillierten Diagnose- und Debugging-Funktionen warten.
- Dokumentierbarkeit: Der deklarative Charakter von RAP, darunter die CDS-Definitionen und das strukturierte Programmiermodell, führt von Natur aus zu einer besseren Dokumentation.
RAP-Grundlagen
Was ist ein Geschäftsobjekt?
Ein Geschäftsobjekt in RAP stellt eine reale Geschäftseinheit oder ein Konzept innerhalb einer Geschäftsdomäne dar, also beispielsweise einen Kundenauftrag, einen Kunden, ein Produkt oder einen Mitarbeiter. Es beinhaltet alle zugehörigen Daten, Verhaltensweisen und Beziehungen. Das Geschäftsobjekt ist die zentrale Steuerungseinheit für einheitliche Datenmanipulation und Transaktionsintegrität, welche die Datenstruktur, die Regeln für die Datenmanipulation und den Lebenszyklus einer Geschäftseinheit definieren.
Was ist eine Abfrage?
Eine Abfrage ist die reine Leseschnittstelle, über die auf Daten zugegriffen werden kann. Sie baut auf Core Data Services (CDS) Views auf, die hauptsächlich zum Abrufen und Anzeigen von Geschäftsdaten verwendet werden. Diese bieten eine strukturierte Möglichkeit, Daten wiederherzustellen, zu filtern, zu sortieren und zu sammeln und dienen häufig als Datenquelle für analytische Dashboards, Suchfunktionen oder Objektlisten in der Benutzeroberfläche.
Was ist ein Geschäftsdienst?
Geschäftsdienste in RAP bieten eine externe Schnittstelle für den Lese- und Schreibzugriff auf die Funktionalitäten von Geschäftsobjekten, mit denen über die Fiori-Anwendungsoberfläche für Endbenutzer oder externe Systeme interagiert werden kann. Geschäftsdienste werden in der Regel mit einer Dienstdefinition bereitgestellt, der die Funktion des Dienstes beschreibt, und einer Dienstbindung, die angibt, wie der Dienst über ein bestimmtes Protokoll wie OData v2 oder v4, UI, Web API usw. bereitgestellt wird.
Was ist ein Geschäftsereignis?
Ein Geschäftsereignis in RAP stellt einen definierten Auslöser oder eine Benachrichtigung dar, der oder die eine signifikante Änderung oder Aktion innerhalb eines Geschäftsobjekts signalisiert. Dadurch können wiederum andere, möglicherweise miteinander verbundene Ereignisse in Anwendungen oder Diensten ausgelöst werden. So sind beispielsweise „Kundenauftrag erstellt“ oder „Produktpreis geändert“ spezifische Geschäftsereignisse, die von anderen Anwendungen oder Workflows zur weiteren Verarbeitung genutzt werden können. Für die asynchrone Integration zwischen Services über SAP Event Mesh oder eine benutzerdefinierte Logik werden Event Definitions und Event Bindings definiert und verwendet.
Datenmodellierung
Die Datenmodellierung in RAP erfolgt mit Hilfe von Core Data Services (CDS), die Entitäten wie Datenstrukturen, ihre Assoziationen (Beziehungen zu anderen Entitäten) und Projektionen mit benutzerdefinierten Ansichten für die Exposition definieren. Die Datenmodellierung ist der zentrale Punkt für die Definition der gesamten Anwendungsstruktur aus Sicht des Datenflusses.
ABAP-Sprache
Die moderne ABAP-Sprache dient als Grundlage für die Implementierung von Geschäftslogiken innerhalb von RAP, wobei ihre Funktionen, einschließlich der Entity Manipulation Language (EML), Anmerkungen und objektorientierte Konzepte, sowie ihre umfangreichen Bibliotheken und Fehlerbehandlungsfunktionen genutzt werden.
Tools
Die RAP-Entwicklung wird durch eine Reihe von Tools unterstützt, darunter der CDS-Editor, die ABAP-Quellcode-Editoren, die ADT-Assistenten und der Services Binding Editor, die in erster Linie in die ABAP Development Tools (ADT) in der Eclipse IDE (einer weit verbreiteten Open-Source-Entwicklungsplattform für die Softwareentwicklung) integriert sind.
Erweiterbarkeit
RAP bietet integrierte Erweiterungsmechanismen, die es Kunden und Partnern ermöglichen, standardmäßige Geschäftsobjekte und -dienste zu verbessern oder anzupassen, ohne die zentrale Codebasis zu verändern. Für beide Arten von Erweiterungen bietet RAP einen präzisen Mechanismus: Die In-App-Erweiterung ermöglicht das Hinzufügen von benutzerdefinierten Feldern, benutzerdefinierter Logik oder benutzerdefinierten Geschäftsobjekten direkt in bestehenden Anwendungen, während die Side-by-Side-Erweiterung die Erstellung separater Anwendungen oder Dienste zur Nutzung und Erweiterung von Standardgeschäftsobjekten beinhaltet.
3-Ebenen-Architektur des RAP-Modells
Das RAP-Modell besteht aus drei grundlegenden Ebenen, von denen jede eine bestimmte Rolle erfüllt. Zudem bietet es einen strukturierten Ansatz zur Entwicklung von SAP-Fiori-Anwendungen auf Unternehmensebene und die Bereitstellung von APIs für externe Interaktionen.
Datenmodellierung und -verhalten
Die erste Ebene bildet die Definition von Datenmodellierung und -verhalten. Diese definiert die Entitäten, die Geschäftsobjekte darstellen, sowie die Beziehungen zwischen diesen Entitäten.
Core Data Service Views (Ansichten der Kerndatendienste) werden verwendet, um wiederverwendbare Datenmodelle zu definieren und die Struktur von Entitäten, einschließlich ihrer Attribute und Assoziationen, festzulegen. Darüber hinaus lassen sich verschiedene Filter und Berechnungen sowie Anmerkungen zur Bereitstellung von Metadaten für die Nutzung der Benutzeroberfläche anwenden bzw. einbinden.
In der Verhaltensdefinition wird festgelegt, welche Aktionen mit einer Datenstruktur möglich sind, also beispielsweise Erstellen, Aktualisieren und Löschen.
Das Datenmodell und die verfügbaren Operationen werden in der Datenbank definiert. Die eigentliche Logik zur Ausführung dieser Operationen ist jedoch in ABAP-Klassen implementiert, welche die Geschäftslogik zum Anlegen, Aktualisieren und Löschen sowie für benutzerdefinierte Operationen an Geschäftsobjekten enthalten.
Geschäftsdienste
Auf der Ebene der Geschäftsdienste werden die auf der ersten Ebene definierte Datenstruktur und das Verhalten als konsumierbare Dienste dargestellt. Anhand der Definition eines Dienstes wird festgelegt, welche CDS-Entitäten und zugehöriges Verhalten offengelegt werden sollen, um den Umfang des Dienstes zu steuern.
Durch die Definition der Dienstbindung wird im zweiten Schritt das Protokoll festgelegt, das für die Kommunikation mit dem Dienst verwendet werden soll, also beispielsweise OData v2 oder OData v4.
Dienstnutzung
Die Dienstnutzung bezieht sich auf die Ebene, auf der Clients oder Anwendungen die angebotenen Dienste verwenden. Wenn ein Dienst für eine Anwendung mit SAP Fiori Elements bestimmt ist, wird er als UI-Dienst bezeichnet. Sein Zweck ist die Bereitstellung von Daten und Metadaten, die Fiori Elements zum automatischen Rendern von Bildschirmen, Tabellen und Formularen verwendet.
Der Dienst kann als Web API bereitgestellt werden, um von einem beliebigen OData-Client genutzt zu werden. Diese Art von Dienst enthält keine UI-spezifischen Metadaten. Solche Dienste eignen sich ideal für die Integration mit Nicht-SAP-Systemen, mobilen oder anderen benutzerdefinierten Anwendungen, die eine Interaktion mit Geschäftsdaten und -logik erfordern.
Entwicklung von ABAP-Modellen
ABAP hat sich von der Freestyle-Codierung zu einem RESTful-Anwendungsprogrammiermodell entwickelt, das sich an veränderliche technologische Paradigmen, architektonische Veränderungen und den Entwicklungsbedarf anpasst. Dies gilt insbesondere seit der Einführung von SAP Fiori und der Cloud-nativen Entwicklung.
Klassisches ABAP
In klassischen Modellen schrieben die Entwickler ABAP-Code in einem prozeduralen und imperativen Stil, griffen direkt auf Datenbanken zu und vermischten Geschäfts- und Benutzeroberflächenlogiken, was zu einer engen Kopplung führte und die Wartung der Codebasis erschwerte.
Die Benutzeroberfläche wurde mit Tools wie SAPscript, Smart Forms und Dialogprogrammierung (Dynpro) erstellt. Bildschirme wurden mit UI-Elementen erstellt und mit Modulen wie ABAP-Logiken, Process Before Output (PBO) und Process After Input (PAI) verknüpft. Dynpro war zwar für herkömmliche Desktop-Anwendungen geeignet, verfügte aber nicht über moderne Funktionen für responsives Design.
ABAP-Modell für SAP Fiori
Mit der Einführung von SAP Fiori entstand ein neues Programmiermodell, das den Anforderungen einer modernen responsiven Benutzererfahrung gerecht wird. Dieses Modell konzentriert sich auf die manuelle Erstellung von OData mit dem Tool SAP Gateway Service Builder (SEGW). Entwickler definieren Entitäten, Eigenschaften und Verknüpfungen manuell und implementieren CRUD-Vorgänge (Create, Read Update, Delete; Erstellen, Lesen, Aktualisieren, Löschen).
Mithilfe des OData.publish-Mechanismus wurden OData-Dienste registriert und zur Nutzung im SAP-Gateway veröffentlicht, das als Drehscheibe für die Bereitstellung und Verwaltung von OData-Diensten diente.
Mit dem Core Data Service können Entwickler semantisch umfangreiche Datenmodelle für die Erstellung von Entitäten, Verknüpfungen und Berechnungen auf Datenbankebene definieren. Das CDS-basierte Business Object Processing Framework (BOPF) wurde entwickelt, um die Implementierung von Geschäftsobjektlogiken wie Verhalten, Validierungen und CRUD-Operationen zu rationalisieren.
ABAP RESTful Application Programming Model
RAP ist die neueste Entwicklung für effiziente und cloudfähige Anwendungen für SAP S/4HANA und SAP BTP.
Es zentralisiert das Konzept des Business Service (Geschäftsdienst) und beinhaltet sowohl Daten- als auch Verhaltensaspekte, darunter welche Entitäten und Verhaltensweisen für Fiori oder eine externe Anwendung offengelegt werden und auf welchem Protokoll dies erfolgt.
Der Core Data Service bleibt auch in RAP zentral und ermöglicht die Definition von wiederverwendbaren Datenmodellen und Anmerkungen zur automatischen UI-Erstellung für Fiori Elements.
RAP trennt die Verhaltensdefinition von der Verhaltensimplementierung. Eine deklarative Spezifikation legt fest, welche Operationen möglich sind, während der ABAP-Code die Verhaltensimplementierung enthält, mit dem die Logik der definierten Verhaltensweisen implementiert wird.
Schritte im RAP-Entwicklungsprozess
Der Entwicklungsprozess von Anwendungen in RAP beginnt mit der Definition der zugrunde liegenden Datenstruktur mit ihren Beziehungen, ihrem Verhalten und ihren Metadaten. Dadurch wird der Dienst bereitgestellt, der von Fiori Elements oder externen Anwendungen genutzt werden kann.
1. Bereitstellung der Datenbanktabellen
Der erste Schritt besteht darin, die Tabellen auszuwählen, in denen die Geschäftsdaten gespeichert werden sollen. Diese können bestehende SAP-Standardtabellen oder benutzerdefinierte Tabellen sein. Sofern es sich nicht um CDS-basierte Tabellen handelt, fügen Sie Erklärungen zur Integration von Vererbungen sowie den Änderungen hinzu, die an den Tabellen vorgenommen wurden. Eine saubere und separate Implementierung kann auch dadurch gewährleistet werden, dass neue Tabellen mit anwendungsspezifischen Attributen erstellt werden.
2. Definition des Datenmodells
Im nächsten Schritt werden das Datenmodell definiert und CDS-Ansichten erstellt, die Geschäftsobjekte repräsentieren. Diese Ansichten können aus einer einzelnen Tabelle als einfache CDS-Ansicht bestehen oder mehrere Tabellen miteinander verbinden, um zusammengesetzte Ansichten mit über- und untergeordneten Definitionen für komplexe Geschäftsobjekte zu erstellen.
- Einfache Geschäftsobjekte bilden ein Produkt oder einen Kunden vollständig ab, wobei alle relevanten Attribute und Verhaltensweisen in einer CDS-Ansicht enthalten sind.
- Zusammengesetzte Geschäftsobjekte befassen sich mit komplexen Geschäftsszenarien, an denen mehrere Geschäftseinheiten beteiligt sind, beispielsweise eine Sales Order, die nicht unbedingt eine einzelne Entität ist und mit einem Sales Order Header und Sales Order Items verknüpft sein kann.
Die Beziehungen von unter- und übergeordneten Elementen definiert Assoziationen und Kompositionen im CDS, unterstützt transaktionales Verhalten und gewährleistet Einheitlichkeit.
3. Definition und Implementierung von Verhalten (nur transaktionale Anwendungen)
Das Datenmodell definiert die Struktur des Geschäftsobjekts. Im Gegensatz dazu legen die Verhaltensdefinition und die Implementierung fest, wie sie sich transaktional verhalten, einschließlich der unterstützten Operationen, wie beispielsweise Erstellen, Aktualisieren und Löschen. Hier werden benutzerdefinierte Operationen mit Validierungsprüfungen vor dem Speichern von Daten implementiert.
Der Behavior Pool, eine globale ABAP-Klasse, wird für die Verhaltensimplementierung verwendet, in welcher der eigentliche ABAP-Code geschrieben wird.
Die wichtigsten Merkmale von Transaktionsanwendungen sind:
- Speichern von Entwürfen: Ermöglichen Sie es Endbenutzern, unvollständige Geschäftsdaten als Entwurf zu speichern. Dadurch verbessern Sie die Benutzererfahrung, indem Nutzer ihre Arbeit unterbrechen und später wieder aufnehmen können.
- Automatische Nummerierung: Eindeutige und fortlaufende Generierung für Entitäten, die unverwechselbare Identitäten erfordern, zum Beispiel Kundenauftragsnummern.
- Validierungen: Mit diesen Prüfungen der Einheitlichkeit von Daten wird sichergestellt, dass das Eingabeformat und die erwarteten Werte der Geschäftslogik entsprechen, also beispielsweise ein Lieferdatum nicht in der Vergangenheit liegt sowie die Formate von Telefonnummern korrekt sind.
- Festlegungen: Einige Felder werden auf Grundlage von Eingaben in anderen Feldern berechnet. Beispielsweise geht der vollständige Name aus Vor- und Nachnamen hervor oder die Beschreibung und Preise werden automatisch eingetragen, sobald ein Produktname eingegeben wird.
Die Implementierung des Verhaltens kann vernachlässigt werden, wenn die Anwendung lediglich der Anzeige von Daten dient, beispielsweise bei Listen oder analytischen Berichten, und keine Änderungsvorgänge erforderlich sind.
4. Projektion von RAP-Geschäftsobjekten
Anstatt alle Felder der zugrunde liegenden CDS-Sicht offenzulegen, werden nur ausgewählte Felder mit CDS-Projektionsansichten für einen bestimmten Dienst dargestellt. Felder können umbenannt oder hinzugefügt werden. Zudem lassen sich im Voraus berechnete Felder spezifisch für die Benutzeroberfläche und Namenskonventionen wie ZC_
Ähnlich wie bei einem Datenprojektionsmodell ermöglicht die Verhaltensprojektion das Aktivieren oder Deaktivieren bestimmter Vorgänge auf Dienstebene, darunter beispielsweise das Erstellen, Löschen und Aktualisieren. Anstatt den Löschvorgang auf der CDS-Verhaltensebene zu entfernen, wird dieses Verhalten auf der Dienstebene nicht angezeigt.
Spezifische Anmerkungen in der Projektionsansicht definieren, wie Daten auf der Benutzeroberfläche von Fiori Elements angezeigt werden sollen, und steuern Aspekte wie Feldbeschriftungen, Suchfähigkeiten und analytische Funktionen.
5. Dienstdefinition
Die Dienstdefinition ist ein Repository-Objekt, das auf eine oder mehrere CDS-Projektionsansichten verweist und als Container für die Entitäten fungiert, die als Dienst bereitgestellt werden sollen.
In der Regel wird die
6. Dienstbindung und Tests
Auf der letzten Ebene wird die Dienstbindung definiert, indem die Verbrauchsmethoden, d. h. die Fiori-Benutzeroberfläche oder externe Anwendungen, und das Protokoll, wie OData v2 oder v4, beschrieben werden.
Für UI-Dienste können Entwickler die automatische Vorschau aktivieren, um Fiori-Elemente schnell zu testen, ohne die komplette Fiori-Anwendung erstellen zu müssen.
Für den UI-Dienst des OData-v4-Protokolls wird normalerweise die Namenskonvention ZUI_<service_Name>_04 verwendet.
Implementierung von Geschäftsobjekten
Zur Implementierung verschiedener Arten von Business Objects in RAP gibt es zwei Hauptansätze:
- Verwaltet
- Nicht verwaltet
Beide Methoden beruhen auf Datenmodellen, die durch CDS-Views-Entitäten definiert sind. Der Unterschied liegt in der Bereitstellung des transaktionalen Verhaltens des jeweiligen Geschäftsobjekts.
Verwaltete Geschäftsobjekte
Verwaltete Geschäftsobjekte werden vor allem dann implementiert, wenn eine Anwendung vollständig neu entwickelt wird. Darüber hinaus kann sie aber auch eine sofort einsatzbereite Unterstützung für die Transaktionsverarbeitung nutzen. Standardvalidierungen und -bestimmungen werden durch das Framework bereitgestellt.
Nicht verwaltete Geschäftsobjekte
Der Ansatz nicht verwaltete Geschäftsobjekte wird gewählt, um bei der Handhabung komplexer Geschäftslogiker und der Interaktion mit mehreren Systemen die vollständige Kontrolle über die Transaktionslogik, CRUD-Operationen und die Datenpersistenz zu übernehmen. Die Entwickler müssen wesentliche Komponenten des REST-Vertrags implementieren. Das Verhalten muss in der Verhaltensdefinition angegeben, aber manuell in ABAP-Klassen im Verhaltenspool implementiert werden.
Wenn die Geschäftslogik bereits in Funktionsmodulen eingefasst ist, hilft ein nicht verwalteter Ansatz den Entwicklern, die vorhandene Geschäftslogik in Geschäftsobjekten wiederzuverwenden. Dabei kann die standardisierte RAP-Laufzeitorchestrierung genutzt werden, um einen RAP-Dienst zu erstellen.
Dienste und Bibliotheken wiederverwenden
ABAP RAP bietet eine Sammlung vorgefertigter Funktionalitäten, APIs und Komponenten, die für den Einsatz in mehreren Anwendungen oder Diensten konzipiert sind. Durch die Wiederverwendung vorhandener Dienste und Bibliotheken können Entwickler bei Aufgaben wie standardisierten Berechtigungsprüfungen, Textermittlungen und redundantem Code Zeit und Aufwand einsparen, sodass sie sich auf die einzigartige, anwendungsspezifische Geschäftslogik konzentrieren können.
Vordefinierte Bibliotheken und Dienste bieten sofort einsetzbare generische Funktionen für verschiedene Geschäftsbereiche, darunter Entwurfsbearbeitung, Feldsteuerung und -validierung, Transaktionsverarbeitung, Datums- und Zeitfunktionen, Etag-Bearbeitung für die Kontrolle der Gleichzeitigkeit von Daten, standardisierte Protokollerstellung und Nachverfolgung von Fehlern oder Ereignissen.
RAP ermöglicht den Aufbau einer domänenspezifischen Logik für diese internen Dienste oder Bibliotheken, wobei diese benutzerdefinierten Dienste überall wiederverwendet werden können.
Die Wiederverwendung von Standard- oder kundenspezifischen Bibliotheken ermöglicht es Entwicklern, die Menge von Standardcode zu reduzieren. Dadurch wird nicht nur der Entwicklungsprozess beschleunigt, sondern auch die Wartbarkeit verbessert. Die Wiederverwendung von Diensten und Bibliotheken ist so konzipiert, dass sie sich in Anwendungen integrieren lässt und Entwicklern ermöglicht, externe Dienste aufzurufen oder Bibliotheksfunktionen direkt aus ihren Behavior-Implementierungen und Projektionsansichten aufzurufen.
Häufig gestellte Fragen
Das ABAP-RESTful-Programmiermodell wird zur Entwicklung neuer Fiori Applications, zur Erstellung von OData-Diensten zwecks Offenlegung von Geschäftslogiken, zur Modernisierung von bestehendem benutzerdefiniertem Code beim Upgrade auf S/4HANA und zur Entwicklung von Extensibility für S/4HANA verwendet.
In erster Linie wird das RAP-Modell zur Entwicklung von OData-Diensten verwendet, die Daten und Dienste innerhalb des SAP-Ökosystems bereitstellen und so Geschäftsvorgänge in der Benutzeroberfläche von SAP Fiori oder die Interaktion mit Anwendungen von Drittanbietern ermöglichen. Bei diesen Diensten kann es sich um OData-Dienste, APIs und Analytical-Dienste handeln, die reine Lesefunktionen bereitstellen.
Ein Business Object ist ein logisches Datenmodell, das einen realen Geschäftsvorgang oder eine Entität darstellt, darunter Sales_Order, Product_Name oder Employee, sowie Datenstruktur, Geschäftslogik, Validierungen und Verhalten beinhaltet. Gleichzeitig ist ein Geschäftsdienst eine Schnittstelle, über die Daten und das Verhalten eines Geschäftsobjekts anderen Anwendungen bereitgestellt werden, damit diese sie nutzen und für die Ausführung von Geschäftsvorgängen miteinander interagieren können.
