ABAP RESTful Programming Model
Inhaltsverzeichnis
Historie: SAPs „Freestyle ABAP Programming“-Ansatz
Viele Jahre hat SAP kein einheitliches Modell gefordert, nach dem Programmierer SAP-Anwendungen entwickeln mussten. Stattdessen galt „Best practice freestyle ABAP programming“. Das bedeutet, dass für Anwendungen auf Basis des SAP Netweaver Application Server ABAP auf Version 7.5 oder niedriger Technologien beliebig kombiniert werden konnten. Hierunter fallen: ABAP (ohne und mit ABAP OO), Dynpro, BRF+, WebDynpro, BSP, BDT etc.
Entwickler hatten somit eine große Freiheit, da sie Technologien nutzen konnten, die sie persönlich bevorzugten und gut beherrschten. Das vereinfachte die Arbeit zunächst, führte aber mittelfristig zu schweren Herausforderungen. Denn sobald neue Entwickler Veränderungen an einem bestehenden System vornehmen wollten, mussten sie sich erst intensiv einarbeiten, um sich in der heterogenen Technologielandschaft zurechtzufinden. Schließlich gab es keine Standards. Die Einarbeitung nahm Aufwand, Zeit und Kosten in Anspruch, die bei Verwendung eines einheitlichen Modells in die Entwicklung hätte fließen können.
SAPs erstes Programming Model
Mit Veröffentlichung des Netweaver 7.4 begann SAP seine ABAP Plattform für die HANA DB zu optimieren. In dem Zusammenhang wurden ABAP Core Data Services (CDS), BOPF und durch die Gateway-Komponente auch OData und damit SAPUI5 für Kunden verfügbar gemacht. Außerdem wurde die REST API zur Verbindung von Frontend und Backend eingeführt und SAP Fiori veröffentlicht. Die Technologievielfalt nahm also weiter zu.
Mit der Entscheidung, SAPUI5 und OData zu Kerntechnologien von SAP Fiori zu machen, entstanden neue Herausforderungen für die Entwicklung von Anwendungen, vor allem von transaktionalen Anwendungen.
Um weiterhin eine hohe Produktqualität und ein einfaches Lifecycle Management zu gewährleisten, führte SAP das „ABAP Programming Model for SAP Fiori“ ein. Damit können Anwendungen einfach skalieren, sind leicht zu warten und auch eine Erweiterung auf Cloud-Readiness-Level ist möglich. Außerdem konnte das Onboarding von neuen Entwicklern und die Effizienz der Programmierarbeit verbessert werden.
Abbildung 1: Entwicklung des ABAP Programming Models
Aufbau: ABAP Programming Model for SAP Fiori
Das ABAP Programming Model for SAP Fiori wurde spezifisch für die Entwicklung von SAP-HANA-optimierten, webbasierten Fiori-Anwendungen konzipiert. Sowohl transaktionale als auch analytische und Such-Anwendungen können Sie hiermit programmieren. Danach sollten Anwendungen wie folgt aufgebaut sein:
- Als Oberflächentechnologie dient SAPUI5 zur Nutzung von HTML5.
- Für wiederverwendbare UI-Komponenten werden SAP Fiori Elements und für die Anwendungen fertige Floorplans genutzt.
- OData wird als REST-basiertes Webprotokoll eingesetzt, sodass durch Metadaten ein modellgetriebener Entwicklungsansatz umgesetzt werden kann, bei dem Software-Bestandteile automatisch generiert werden.
- Für die Businesslogik kommt die ABAP Platform zum Einsatz, zum Beispiel erweitert um Frameworks wie BOPF und BRF+.
- Das Datenmodell wird über ABAP CDS Views auf der SAP HANA DB erstellt.
- Eclipse als Backendtechnologie nutzt ABAP Development Tools, die die Verwendung der neuen Technologien unterstützen und vereinfachen.
Die drei zentralen Säulen der Programmierung mit ABAP
Diejenigen, die seit Jahren mit dem ABAP Editor und mit ABAP-Prototyp-Entwurfsmustern programmieren, haben vielleicht schon vom ABAP RESTful Programming Modul gehört.
Die drei zentralen Säulen haben sich bei der Programmierung mit dem ABAP RESTful Programming Model nicht geändert: Es gibt immer noch eine klare Trennung zwischen der Datenbankschicht, der Geschäftslogikschicht und der UI-Schicht. Allerdings hat sich in jedem Fall die Art und Weise, wie Sie programmieren, mehr oder weniger stark verändert. Im Folgenden zeige ich die Änderungen in den Schichten Datenbank-, Business-Logik- und Benutzerschnittstellenschicht auf.
Datenbankschicht
Die wichtigste Änderung hier ist, dass Sie nicht mehr mit SELECT-Anweisungen auf Datenbanktabellen im ERP-Kernsystem wie KNA1 zugreifen können. Für Ihre eigenen Z-Tabellen können Sie weiterhin SELECT oder UPDATE verwenden, da diese in der gleichen Datenbank wie Ihr Cloud-ABAP-Coding leben.
Da Sie immer sowohl auf das Lesen von Daten aus dem ERP-System als auch auf deren Aktualisierung (wie bei einem Warenausgang) zugreifen wollen, muss es dafür einen Mechanismus geben.
Business-Logik-Schicht
Die Veränderungen in diesem Bereich sind etwas radikaler. Das bekannte BOPF gibt es nicht mehr, da es durch etwas konzeptionell identisch, aber technisch völlig anderes ersetzt wird. Falls Sie einen Herzinfarkt bekommen, wenn Sie lesen, dass sich das BOPF jetzt im “Wartungsmodus” befindet, obwohl Sie gerade die letzten drei Jahre damit verbracht haben, all Ihre neuen Anwendungen mit dem BOPF – wie von SAP empfohlen – zu schreiben, fürchten Sie sich nicht: SAP sagt, dass Ihre Investition sicher ist und dass es ab 2020 eine native Integration zwischen RAP und BOPF geben wird, obwohl es sagt, dass Sie das BOPF nicht mehr für Neuentwicklungen verwenden sollten, sobald Ihnen RAP zur Verfügung steht.
Benutzerschnittstellenschicht
Dieser Bereich hat sich kaum verändert. Die Idee war immer, dass sich die UI-Technologie so schnell ändert, dass man das Backend vom Frontend völlig entkoppeln muss, indem die UI-Schicht die vom Backend bereitgestellten OData-Dienste verbraucht. Im Moment hat SAP SAPUI5 als seine bevorzugte UI-Technologie, aber in der heutigen Zeit könnte jederzeit etwas Größeres und Besseres auftauchen.
Das traditionelle Modell deklariert Informationen, die in der Vergangenheit als Aufgabe der UI hätten angesehen werden können, wie z. B. die Reihenfolge der Felder, alternative Namen und im Grunde alle Informationen des ALV-Feldkatalogtyps.
In RAP wird dieses Verhalten in der Benutzeroberfläche vollständig durch Anmerkungen in den CDS-Ansichten gesteuert. Die UI-Schicht ist dumm und dient ausschließlich dazu, die Anwendung so schön wie möglich aussehen zu lassen. Die Idee dahinter ist, dass Sie, wenn es im Frontend überhaupt keine Smarts gibt, die Technologie per Knopfdruck wechseln können und das Backend überhaupt nicht wechseln müssen.
Vorteile von ABAP RAP
Das Programmiermodel bietet Ihnen u. a. folgende Vorteile:
- Effizienzsteigerung: Das Programmiermodell nimmt den Entwicklern viel Arbeit ab und stellt gleichzeitig sicher, dass eine hohe Produktqualität gewährleistet bleibt.
- Automatisierungen: Die Integration von verschiedenen Automatismen und/oder Frameworks wie BOPF und ABAP CDS Views ermöglicht es, OData Services ohne manuelles Zutun zu erzeugen. Auch viele Bausteine der Software können automatisch generiert werden.
- Einheitliche Oberflächen: Wer das Modell verwendet, nutzt die immer gleiche Technologieauswahl in der Kernanwendung, was eine einheitliche Oberfläche in SAPUI5 erzeugt. Die Entwicklung kann damit leicht personenunabhängig erfolgen.
Gründe für die Weiterentwicklung
Das Programming Model bietet jedoch nicht für jede Entwicklungsaufgabe die ideale Unterstützung. Logikschwere Business-Anwendungen können damit zum Beispiel nur schwer in moderne Fiori-Applikationen überführt werden. Wer das ABAP Programming Model verwendet, büßt zudem in der Entwicklung an Flexibilität ein, da hier viele Bausteine automatisch generiert werden. Spezifische Anforderungen lassen sich nur mit Workarounds abbilden und erfordern Zusatzaufwand.
Um die Total Cost of Development auch für solche Anwendungsfälle zu senken und den nächsten logischen Schritt in der Evolution der Technologie zu gehen, entschied SAP, die verschiedenen Konzepte, zum Beispiel die Transaktionsverwaltung in ABAP und die CDS-Technologie, zu integrieren. Ziel war es, ein Programming Model zu schaffen, mit dem die gesamte Entwicklung über die ABAP Development Tools in Eclipse durchgeführt werden kann. Aus diesen Anforderungen entstand das neuste SAP Programmiermodell: das ABAP RESTful Programming Model.
Aufbau ABAP RAP
Das ABAP RESTful Application Programming Model bietet eine standardisierte und effiziente Architektur, um SAP-HANA-optimierte OData-Dienste (z. B. Fiori Apps) im Umfeld der SAP ABAP Cloud Platform zu entwickeln. Die Architektur ist zugeschnitten auf das Programmierparadigma REST (Representational State Transfer) für verteilte Systeme. Dabei wird von einem Server über eine festgelegte Schnittstelle ein Service bereitgestellt, der von einem Client genutzt werden kann.
Das Modell besteht aus drei Schichten – von unten nach oben:
- Datenmodellierung und Verhalten (Data Modeling & Behavior): In der untersten Schicht werden Datenmodell und -verhalten mittels CDS festgelegt. Über eine neue Behavior Definition Language lässt sich das transaktionale Verhalten der Anwendung (Sperren, Speichern, Lesen usw.) definieren. Diese Behavior Definition löst das Framework BOPF aus dem ABAP Programmiermodell für SAP Fiori ab.
- Service-Bereitstellung für Geschäftsobjekte (Business Service Provisioning): Der Scope des Datenmodells wird in zwei Schritten in der Service-Definition festgelegt. Sie bildet die Basis, auf der die OData-Services anschließend im Service Binding an das Modell gebunden werden.
- Service-Aufruf (Service Consumption): Die SAP-Fiori-Anwendungen konsumieren die OData Services und stellen die Oberfläche bereit. Alternativ können, wie bisher, auch andere Webservices die OData API verwenden.
Technologisch ist das Modell verschlankt worden. Anders als zuvor müssen Sie komplexe Frameworks wie BOPF nicht mehr zusätzlich erlernen und verwenden.
Abbildung 2: Übersicht ABAP RESTful Programming Model.
Fazit
Mit dem ABAP RESTful Application Programming Model verfolgt SAP einen Cloud-First-Ansatz. Bisher steht das Modell nur in der SAP Cloud Platform ABAP Environment zur Verfügung. Eine On-Premises-Bereitstellung für SAP S/4HANA ist zwar geplant, der Veröffentlichungszeitpunkt steht jedoch noch nicht fest. Einsatzfähig ist das ABAP RESTful Programming Model für alle SAP-Anwender mit SAP Cloud Platform ABAP Environment ab Version 1808. Updates werden quartalsweise eingespielt.
Haben Sie Fragen zu dem Thema? Dann kontaktieren Sie uns gerne.
Websession: ABAP RESTful programming model
Haben Sie Fragen zu uns und unserer Arbeit oder konkret zu Umstellungsprojekten? Vereinbaren Sie gerne eine kostenlose Websession mit uns.
FAQ
Was ist ABAP RAP?
Das ABAP RESTful Application Programming Model (ABAP RAP bzw. SAP RAP) ist ein Programmiermodell für browserbasierte Anwendungen, die für die SAP HANA DB optimiert sind. Es ermöglicht eine effiziente Entwicklung und verringert die Total Cost of Development.
Was ist der Unterschied zwischen ABAP und HANA?
ABAP ist die proprietäre Programmiersprache von SAP, auf der ein Großteil der SAP-Anwendungen basiert. HANA dagegen ist eine Datenbanktechnologie von SAP für große Datenmengen.
