Fiori für ABAP - Übersicht

Inhaltsverzeichnis

• Einleitung
• Annotationen
• Service
• Erstellung
• Erweiterung
• Sicherung
• JavaScript
• Fazit

In diesem Artikel gehen wir der Frage nach, wie viel Fiori-Wissen wir für die eigentliche Arbeit tatsächlich benötigen, wenn wir RAP-Anwendungen (ABAP RESTful Application Programming Model) zur Verfügung stellen wollen.

 

Einleitung

Vor einer Weile hatten wir uns mit der Frage beschäftigt, wie viel Fiori ein ABAP-Entwickler in seinem Alltag eigentlich benötigt. Dabei sind wir auf die verschiedenen Fragestellungen eingegangen, wieso wir eigentlich wieder Fullstack entwickeln sollten, um die komplette Kontrolle über unsere Anwendungen zu behalten. Daher empfehlen wir dir, zuerst diesen Artikel zu lesen, um die entsprechenden Hintergründe zu erhalten. In diesem aktuellen Beitrag werden wir uns die Grundbestandteile noch einmal anschauen, die wir benötigen, um ohne viel Aufwand eine Fiori-Anwendung zu erstellen und entsprechend erweitern zu können und was uns bereits der Standard zur Verfügung stellt.

 

Annotationen

RAP-Anwendungen werden vor allem annotationsgetrieben im Backend entwickelt. Dabei erzeugen wir eine Menge UI-Annotationen direkt im Datenmodell, was auf den ersten Blick nicht unbedingt für eine saubere Trennung spricht. Sie sind jedoch ein wichtiger Bestandteil, um Anwendungen schnell und einfach zu entwickeln und das UI-Verhalten sehr nah am ABAP und der eigentlichen Anwendung zu modellieren. Daher ist unsere erste Empfehlung immer, die UI-Annotationen im Backend zu halten (idealerweise in Metadata Extensions), damit entsprechende Anpassungen durchgeführt werden können, ohne die Anwendung noch einmal neu deployen zu müssen. Damit bist du am flexibelsten und sparst dir den zusätzlichen Schritt, ein neues Fiori-Artefakt zu deployen. Im einfachsten Fall handelt es sich dabei um eine klassische Fiori Elements-Anwendung, die keinerlei eigene Logik im Bauch hat, da der Großteil der Logik vollständig in unserem RAP-Stack liegt.

 

Service

Heutzutage sollten Services vor allem in der Version OData V4 generiert werden. Die Nutzung der Version V2 empfiehlt sich eigentlich kaum noch. Die meisten modernen Plugins, Erweiterungen und auch die Fiori Elements Extension API basieren mittlerweile primär auf OData V4. Damit hast du die größtmögliche Flexibilität und den vollen Funktionsumfang, den du für deine moderne Fiori-Entwicklung benötigst. Es mag zwar noch sehr seltene Ausnahmen geben, in denen ein OData V2 Service genutzt wird (etwa bei speziellen Legacy-Anforderungen), aber grundsätzlich solltest du darauf achten, die neueste Version mit OData V4 zu verwenden.

 

Erstellung

Haben wir dann all unsere UI-Annotationen definiert, können wir mit der eigentlichen Erstellung der Anwendung beginnen. Hier solltest du dir zuerst die Frage stellen: Mit welcher Software möchtest du eigentlich deine Fiori-Artefakte erzeugen? Dafür hast du aktuell zwei Tools zur Auswahl:

1. BAS - Das SAP Business Application Studio ist das Standard Produkt, dass mit der BTP ausgeliefert wird und ein VS Code in einem Cloud Container darstellt.
2. VS Code - Eine lokale Installation von VS Code mit den entsprechenden Plugins für die Fiori-Entwicklung (SAP Fiori Tools).

 

Hier empfiehlt sich die Arbeit mit dem Business Application Studio, da du ja eigentlich nur deine Fiori-Anwendung generieren willst und nicht allzu viel Zeit in der eigentlichen IDE verbringst. Der Nachteil von VS Code ist, dass die IDE und die Plugins immer aktuell gehalten werden müssen, wodurch viel Zeit verloren geht, nur um die Software zu aktualisieren, anstatt an der eigentlichen App zu arbeiten. Hier solltest du aber einfach auf deine persönlichen Präferenzen schauen.

Die meisten Tutorials werden wir mit dem BAS zeigen. Hier könnte sich jedoch in den nächsten Monaten etwas ändern, wenn das VS Code Plugin für die ABAP-Entwicklung (ADT) erscheint, kann grundsätzlich die Fullstack-Entwicklung auch komplett in VS Code durchgeführt werden. Dadurch spart man sich den Wechsel zwischen den verschiedenen Tools und kann in einem einzigen Werkzeug den kompletten Prozess modellieren. Dies könnte ein entscheidender Vorteil für VS Code in der Zukunft sein, je nachdem, wie gut das Plugin für die ABAP-Entwicklung letztlich funktioniert.

 

Erweiterung

Hast du deine Fiori Elements-Anwendung generiert, kann es vorkommen, dass du Erweiterungen an der Anwendung durchführen musst. Dazu stehen dir verschiedene Funktionen innerhalb deiner Entwicklungsumgebung zur Verfügung, wie zum Beispiel das Guided Development oder die entsprechenden Extension APIs. Weiterhin gibt es Tools wie die Page Map, die du verwenden kannst, um Entitäten und Mappings zu verwalten. Grundsätzlich und aus eigener Erfahrung empfiehlt es sich aber, so wenig Erweiterungen wie möglich direkt in der UI-Anwendung durchzuführen, es sei denn, es handelt sich wirklich um komplexe Use Cases. Du solltest immer bedenken: Je komplexer der Use Case und je mehr individuelle Erweiterungen du in deiner Fiori-Anwendung hast, desto mehr Wartungsaufwand musst du in der Zukunft einplanen. Daher empfiehlt es sich, erst einmal so nah wie möglich an den Standards und den Templates zu bleiben, wie die SAP sie ausliefert.

 

Sicherung

Hast du deine Anwendung fertig generiert und deployed? Ab hier geht es im Grunde nur noch um die Sicherung der eigentlichen Anwendungsdaten. Im Business Application Studio liegen die Dateien zwar in einem Cloud-Storage, sind dort aber nicht dauerhaft vor dem Löschen gesichert. Daher ist der letzte Schritt eigentlich immer die Ablage der gesamten Anwendung in einem Git-Repository. Dazu solltest du ein entsprechendes Git nutzen, welches in deinem Unternehmen eingesetzt wird. Aktuell kann hier ein Cloud-Provider genutzt werden oder ein Produkt, welches über den Cloud Connector erreichbar ist.

Warum wollen wir die eigentliche Anwendung sichern, obwohl wir kaum manuelle Änderungen am Code vorgenommen haben? Der Grund ist ganz einfach: Hier sind wichtige Konfigurationen vorhanden, wie zum Beispiel bestimmte Parameter, die wir für die Navigation im Fiori Launchpad benötigen. Diese Konfigurationen werden auch benötigt, wenn wir zum Beispiel ein Undeployment der eigentlichen Anwendung durchführen wollen. Weiterhin können Anpassungen an Texten (i18n-Dateien) oder andere Kleinigkeiten vorhanden sein. Damit der nächste Entwickler auf genau dem Stand aufsetzen kann, den wir im System deployed haben, sichern wir deshalb alle Ressourcen zentral.

 

JavaScript

Eine der großen Fragen bleibt eigentlich noch offen: Wie sieht es mit der Nutzung von JavaScript aus und wie viel davon brauchen wir als ABAP-Entwickler wirklich?

Die Frage ist nicht unbedingt leicht zu beantworten, aber grundsätzlich gibt es genug Infomaterial und Beispiele von SAP, um auch ohne JavaScript-Code auszukommen. Weiterhin sind wir mittlerweile im Zeitalter der KI angekommen. Das heißt, auch eine KI kann uns dabei helfen, JavaScript-Codeschnipsel zu erstellen oder fachliche Fragen zu beantworten. Aus persönlicher Erfahrung können wir sagen: Bei den Anwendungen, die wir bisher gebaut haben, haben wir eigentlich so gut wie kein JavaScript benötigt. Daher solltest du dir erst einmal nicht zu viele Gedanken darüber machen, JavaScript oder das komplette SAPUI5-Framework bis ins Detail zu lernen. Starte lieber erst einmal mit den RAP-Basics, baue deine Anwendungen und schaue dann punktuell, was du an der Oberfläche wirklich erweitern musst.

 

Fazit

Damit solltest du nun einen groben Überblick haben, was du eigentlich benötigst, um mit der Entwicklung im Kontext von RAP starten zu können, um deine ersten Anwendungen zu bauen und auch zu deployen. Grundsätzlich brauchst du dir keine Sorgen zu machen, dass du von UI5 und JavaScript überlastet wirst. Hier nehmen dir Fiori Elements und das RAP-Framework extrem viel Arbeit ab.