Christoph Lordieck
 - 20. September 2019

ABAP RESTful Programming Model

Das ABAP RESTful Programming Model 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.

Historie: SAPs „Freestyle ABAP programming“-Ansatz

Viele Jahre hat SAP kein einheitliches Modell gefordert, nach dem SAP-Anwendungen entwickelt werden mussten. Stattdessen galt „Best practice freestyle ABAP programming“. Das bedeutet, für Anwendungen auf Basis des SAP Netweaver Application Server ABAP auf Version 7.5 oder niedriger konnten und können Technologien beliebig kombiniert werden: ABAP (ohne und mit ABAP OO), Dynpro, BRF+, WebDynpro, BSP, BDT etc.

E-Book: ABAP Entwicklungsrichtlinien

Richtlinien zur Programmierung und Praxistipps zum Thema ABAP-Entwicklung.

Unser E-Book zu den ABAP Entwicklungsrichtlinien

Für Entwickler bot das eine große Freiheit. Sie konnten Technologien nutzen, die sie persönlich bevorzugten und gut beherrschten. Das vereinfachte die Arbeit zunächst, führte aber mittelfristig zu gravierenden Nachteilen. 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 kostete Zeit und Geld, 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

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 hiermit programmiert werden.

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.

In diesem Webinar erfahren Sie alles rund um die SAP-Entwicklungsthemen.

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, also lassen Sie uns nacheinander über die Änderungen in jeder Schicht sprechen. 

Änderungen an der 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. 

Änderungen an der Business-Logik-Schicht

Die Veränderungen in diesem Bereich sind etwas radikaler. Das BOPF, das Sie kennen und lieben, gibt es nicht mehr. Es ist durch etwas ersetzt worden, das – obwohl konzeptionell identisch – technisch völlig anders umgesetzt 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. 

Änderungen an der 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 des ABAP Programming Models

Das Programmiermodell nimmt den Entwicklern viel Arbeit ab und stellt gleichzeitig sicher, dass eine hohe Produktqualität gewährleistet bleibt.

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.

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 RESTful Programming Model

Das ABAP RESTful 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 komplexe Frameworks wie BOPF nicht mehr zusätzlich erlernt und verwendet werden.

Abbildung 2 Übersicht ABAP RESTful Programming Model

Abbildung 2 Übersicht ABAP RESTful Programming Model

Fazit

Mit dem ABAP RESTful 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.

FAQ

Was ist das ABAP RESTful programming model?

Das ABAP RESTful Programming Model 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.

Christoph Lordieck

Christoph Lordieck

Mein Name ist Christoph Lordieck. Einige Jahre Projekt- und Umsetzungserfahrung hat meinen Wissenshunger noch nicht gestillt und ich suche ständig nach neuen Themen und technischen Entwicklungen im ABAP Umfeld. Ich freue mich auf Ihre Frage oder Anregung!

Sie haben Fragen? Kontaktieren Sie mich!


Das könnte Sie auch interessieren

Durchsucht man das Internet nach SAP ABAP Tutorials findet man eine Vielzahl von Möglichkeiten, um sich in die SAP ABAP Programmierung einzuarbeiten. Dieser Artikel zeigt die Wege, mit denen man sich ABAP-Grundlagen aneignen kann. Egal ob Azubis, Studenten, Berufseinsteiger- oder […]

weiterlesen

Mit SAP HANA wurden viele Konzepte der Unternehmenssoftware aus Walldorf vollständig überarbeitert und modernisiert. Eines dieser Neuerungen waren die CDS Views. Bestimmt sind Sie bereits auf die Begriffe "ABAP CDS Views" oder "HANA CDS Views" gestoßen. Wer jetzt denkt, dass beide […]

weiterlesen

Core Data Service Views sind eine zentrale Technologie im S/4HANA Technologiestack. Der View-to-View-Ansatz ist hier in gewisser Weise ein Divide- & Conquer-Ansatz, realisiert durch die ABAP Core Data Services. Es geht also darum, eine komplexere Aufgabenstellung in kleinere Teilprobleme zu zerlegen, […]

weiterlesen

Mehr von unseren Partnern


Unsere Produkte zu ABAP RESTful Programming Model

Was müssen ABAP Entwickler wissen, wenn sie Applikationen für die SAP HANA Datenbank vorbereiten, entwickeln und optimieren wollen?

Mehr Informationen

Sie wollen die ABAP-Entwicklung effizienter gestalten? In einem unverbindlichen Gespräch zeigen wir Ihnen gerne die Möglichkeiten auf, die das neue SAP BOPF Framework bietet.

Mehr Informationen

Als SAP ABAP Entwickler erarbeiten Sie sich über die Zeit einen eigenen Stil und lösen Probleme auf Ihre Weise. Aber was ist, wenn es die ganze Zeit einfacher oder anders geht? Was wäre, wenn es hilfreiche Tools gibt, die Sie […]

Mehr Informationen

Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.





Angebot anfordern
Preisliste herunterladen
Expert Session
Support