056: Fiori Elements for ABAP Developers

Inhaltsverzeichnis

• Einleitung
• Fiori Elements
• Basics
• Demo
• Zusammenfassung

In dieser Folge wollen wir dem Thema nachgehen: Was benötigt eigentlich ein ABAP-Entwickler, um Fiori Elements als Full-Stack-Developer entwickeln zu können? Dazu werden wir in die verschiedenen Punkte der Agenda eintauchen. Im ersten Schritt schauen wir einmal darauf, was es eigentlich für Herausforderungen gibt und wo das Gap heutzutage liegt. Dann schauen wir uns Fiori Elements an, wieso wir es verwenden wollen und was es dabei zu entdecken gibt. Im dritten Punkt schauen wir uns die Grundlagen der Modellierung von modernen Anwendungen an und wie wir diese am besten vereinfacht durchführen können. Danach schauen wir im vierten Punkt noch einmal in ein Hands-on und erklären direkt am System einige Schritte. Zum Schluss fassen wir das Ganze noch einmal zusammen.

 

Einleitung

Wie wir heutzutage also moderne Anwendungen entwickeln: Auf der einen Seite haben wir den ABAP-Stack, auf dem der ABAP-Entwickler auch in der Vergangenheit bereits unterwegs war. Dieser baut seine Anwendungen auf klassischen Tabellen oder Table Entities auf und setzt darüber Core Data Services, mit denen er die Daten nach außen projiziert und zusätzliche Daten dazu liest. Mit RAP baut er dann das Verhalten und den OData-Service am Ende auf, der die Anwendung zur Verfügung stellen soll. Das Ganze passiert dann meist in den ABAP Development Tools für Eclipse. Wer ganz modern ist, ist schon in VS Code unterwegs. Das heißt, am Ende wird vor allem die Anwendung über das Service Binding getestet und die verschiedenen Annotationen validiert. Hier hört aber für viele Entwickler bereits der Standard auf, und sie begeben sich in ein unbekanntes Gewässer, um zum nächsten Schritt zu kommen.

Dabei beginnt nun der eigentlich letzte und wichtigste Schritt, nämlich die Erzeugung der Anwendung. Hierbei gibt es noch verschiedene Punkte zu beachten, die relevant sind, um später die Anwendung abzulegen, das Deployment durchzuführen oder Anpassungen vorzunehmen, um die Fiori-Anwendung zum vollen Potenzial zu bringen. Dies passiert heutzutage vor allem im Business Application Studio, einer Standardumgebung, die auf der BTP zur Verfügung gestellt wird und ein containerisiertes VS Code ist. Grundsätzlich kannst du aber auch ein lokales VS Code verwenden, um deine Fiori-Artefakte zu generieren. Hier herrscht dann meistens auch das größte Gap, denn die Entwickler fühlen sich in der Entwicklungsumgebung und den Tools nicht so zu Hause wie in ihrer ABAP-Umgebung. Dabei sind beide Umgebungen relevant für die effiziente Entwicklung von Fiori-Anwendungen für den Endanwender.

Noch ein kleiner Seitenvermerk: Aktuell stellen wir auf dem Bild dar, dass wir in zwei verschiedenen Entwicklungsumgebungen unterwegs sind. Bereits heute ist es möglich, in VS Code beide Fälle zum Großteil über einen Editor abbilden zu können. Dies bedeutet aber immer noch eine lokale Installation aller nötigen Tools, um die Entwicklung durchführen zu können. Zudem gibt es gewisse Feature-Gaps, die immer noch vorhanden sein können, und Features, die nicht unterstützt werden. In Zukunft könnte es aber potenziell immer wichtiger werden, eine Entwicklungsumgebung für den kompletten Lifecycle zu haben.

 

Fiori Elements

Werfen wir daher einen ersten Blick auf die wichtigen Tools innerhalb von Fiori Elements, die wir als Entwickler beherrschen müssen. Zuallererst wollen wir darauf hinweisen, wieso wir eigentlich Fiori Elements verwenden und auf die Freestyle-Entwicklung größtenteils verzichten wollen. Freestyle hat zwar eine gewisse Flexibilität und Freiheiten, die es mit sich bringt, aber auch sehr viel an Entwicklungsaufwand, welchen wir für ein einfaches UI investieren müssen. So bauen wir den Großteil immer von Grund auf neu, müssen uns um alle Themen innerhalb der Entwicklung selbst kümmern, wie die Navigation, die Verwaltung von Nachrichten, die aus dem Backend kommen, und so weiter. Ebenso sollten wir dann, da wir alles selbst gebaut haben, auch unseren Code und die ganze Applikation automatisiert testen können. Hier können wir uns nicht auf den Standard verlassen.

Und dies ist ein Grund, wieso wir auf Fiori Elements setzen: So bauen wir die Anwendung auf unseren Annotationen auf. Wir verwenden Standard-Floorplans, die einfach zu implementieren sind und keinen extra Aufwand haben. Unsere Tests finden größtenteils auf dem Backend-System statt, zusammen mit unserem Code. Das Frontend zeigt einfach nur noch alle Informationen aus dem Backend an. Damit reichen die zentralen Tests, die die SAP durchführt, wenn sie Fiori Elements testet, und wir müssen keine Tests mehr im Frontend zur Verfügung stellen, außer wir haben eine komplexe Logik, die wir selbst implementiert haben.

Dabei verwenden wir in Fiori Elements vor allem verschiedene Floorplans, die wir einsetzen können, um schnell Anwendungen zu implementieren. Der am häufigsten genutzte Floorplan ist der List Report zusammen mit der Object Page. Diese werden als Standard aus einem RAP-Service generiert und stellen von den Funktionen her den Großteil einer ALV-Liste zur Verfügung. So haben wir eine Filterbar, die einem Selektionsbild ähnelt, und eine Liste für die Ausgabe, die der ALV sehr ähnlich ist. Die Object Page ist dabei ein Zusatz, um mehr Daten im Detail auf einer separaten Seite genau für einen Datensatz darstellen zu können. Bei der Verwendung deckt der List Report ungefähr 80-90% der Anwendungsfälle ab, wird damit sehr, sehr häufig eingesetzt und sollte als Erstes gelernt werden. Für weitere, spezielle Szenarien gibt es andere Floorplans, wie zum Beispiel die Analytical List Page, wie im Screenshot dargestellt, oder die Overview Page, die aber auch etwas weniger verwendet wird. Weitere Floorplans findest du in der Dokumentation des Developer Portals. Außerdem gibt es die Custom Page, die eine leere Seite darstellt. Hier kannst du über Building Blocks und Freestyle Elemente deine eigenen Seiten und Ansichten erstellen, so wie du sie benötigst. Hier solltest du dich ebenfalls an die Fiori Design Guidelines halten, um deine Anwender nicht komplett zu verwirren. Im Screenshot siehst du das Clean Core Measurement Dashboard für die Systemübersicht, welches wir als Open-Source-Projekt zur Verfügung stellen.

Beim nächsten wichtigen Punkt, den du lernen solltest, handelt es sich um die Fiori Tools. Diese stellen verschiedene Anwendungen, Programme, Mechaniken und Methoden zur Verfügung. Dabei haben wir als ersten Punkt das Generieren von Anwendungen. Dafür gibt es den Wizard "Project from Template". Dazu sollten wir auch wissen, wie eine Applikation aufgebaut ist, also die eigentliche Struktur für eine Fiori-Anwendung, sowie Tools wie die Application Info kennen, die uns allgemeine Informationen über unsere Anwendung geben kann. Im zweiten Schritt haben wir das Anpassen von Anwendungen, wenn diese nicht unseren Wünschen entsprechen sollten. Dafür gibt es das Guided Development, um verschiedene Schritte an der Anwendung durchführen zu können ohne sie im Detail zu kennen, die Page Map, um den Aufbau der Anwendung und der verschiedenen Seiten anpassen zu können und zum Beispiel auch neue Aktionen hinzuzufügen, sowie den Fiori MCP Server mit den verschiedenen Skills, um auch über AI die eigene Anwendung erweitern zu können. Als letzten Schritt brauchen wir das Deployment, um unsere Anwendung dann im Fiori Launchpad zur Verfügung zu stellen. Hier gibt es auch die Deployment- und die Launchpad-Configuration, die wir dafür erstellen müssen. Und wir sollten wissen, wie wir mit Git arbeiten, um am Ende unsere Ressourcen abzulegen. Es ist wichtig zu wissen, dass diese Ressourcen nur auf unserem Rechner zur Verfügung stehen und nicht automatisch von unseren Kollegen mitgenutzt werden können. Dafür müssen sie in einem Git-Repository abgelegt werden und können von dort geladen werden um sie später erweitern zu können.

 

Basics

Schauen wir uns einmal die verschiedenen Grundlagen an, die wir benötigen, um überhaupt solche Fiori-Elements-Anwendungen anlegen zu können. Im ersten Schritt schauen wir daher auf das Backend, welches mit ABAP umgesetzt wird. Hier solltest du beachten, dass die UI-Annotationen immer die führenden Annotationen für deine Anwendung sind, um Felder einzublenden oder Bereiche zu erzeugen. Sobald du mit der Entwicklung fertig bist, solltest du den Service testen und über die Preview deine Anwendung anzeigen und anpassen, bis du soweit zufrieden bist. Damit ist bereits ein großer Schritt abgeschlossen.

Außerdem solltest du darauf achten, wenn du den Business Service erstellst, dass dort ein OData V4-Dienst genutzt wird, da dieser mittlerweile zum Standard gehört. Der Vorteil von OData V4 ist, dass wir auch das Flexible Programming Model verwenden können, um später Anpassungen in unserer Fiori-Anwendung ganz einfach durchführen zu können. Ebenso werden die aktuellsten Features nur noch für diese OData-Version geliefert. Das heißt, nur in Ausnahmefällen solltest du noch OData V2 nutzen, um Anwendungen darauf zu generieren.

Als letzten Punkt haben wir den Frontend-Bereich mit JavaScript. Hier solltest du darauf achten, dass innerhalb deines Projektes deine UI-Annotationen nicht überschrieben werden und keine lokale Annotationsdatei mit Inhalt des kompletten Service erstellt wird. Dies hat zur Folge, dass wir später Probleme haben, das UI über unsere Backend-Annotationen zu erweitern, da diese immer wieder von dem Annotation-File innerhalb des Projektes überschrieben werden. Das kann unschöne Seiteneffekte haben und auch dafür sorgen, dass wir unsere Anwendung immer wieder deployen müssen, um kleine Änderungen zu sehen. Wir sollten daher nur Anpassungen im Frontend-Projekt durchführen, wenn diese nicht über Backend-Annotationen möglich sind, um so zusätzliche Features zu implementieren.

 

Demo

Gehen wir dazu in eine Demo und schauen uns einige wichtige Tools innerhalb des Business Application Studios an, das wir hier verwenden. Dabei handelt es sich grundsätzlich um ein VS Code, welches in einem Container läuft, automatisch  aktualisiert wird und mit den richtigen Tools ausgestattet ist. Von daher gibt es keinen großen Unterschied zu einer lokalen Installation, nur das wir eben keine Installation benötigen. Auf der linken Seite findest du verschiedene Projekte, die wir bereits innerhalb unserer Instanz angelegt haben.

Wir würden nun damit beginnen, ein neues Projekt zu erstellen. Den Wizard dazu findest du im Menü. Hier können wir ein neues Template auswählen, rufen den Fiori Generator auf und wählen in diesem Fall den List Report aus, welcher, wie gesagt, das Standard-Template ist. Danach verbinden wir uns gegen ein System, in diesem Fall ein ABAP Environment in der BTP, und wählen dann den passenden Service aus. Hier verwenden wir einen Clean-Core-Measurement Service, den wir entwickelt haben, für die verschiedenen Objekte und Findings. Als Nächstes wählen wir unsere Hauptentität aus. Dies ist die Entität, über die wir in unserer Anwendung einsteigen wollen, wenn wir den List Report ausführen. Zusätzlich wählen wir noch die Nachrichten als Unterentität aus, über die wir navigieren können, wenn wir zum Beispiel auf die Object Page unserer Anwendung navigieren.

Im unteren Teil können wir zum Beispiel auch den Table Type verändern. Hier ist standardmäßig die Responsive Table definiert, welche die Spaltenbreite dynamisch anpasst und so viele Spalten anzeigt, wie auf eine Seite passen. Hier könnten wir auch andere Tabellentypen wählen, wie z.B. die Analytical Table oder eine Grid Table, die unterschiedliche Ausgabeformate bieten.

Im nächsten Schritt können wir projektspezifische Informationen hinterlegen, wie zum Beispiel den Namen der Applikation und einen Namespace, um so eine eindeutige Kennung der Anwendung zu erreichen. Im unteren Teil findest du nun verschiedene Optionen, um weitere Konfigurationen mitzugenerieren, wie zum Beispiel eine Deployment-Configuration für das spätere Deployment oder eine Launchpad-Configuration, um später eine Kachel im Fiori Launchpad darstellen zu können. In diesem Fall machen wir keine weiteren Einstellungen und lassen uns das Projekt generieren.

Nach der Generierung können wir in das Projektverzeichnis schauen. Hier finden wir zwei Ordner und verschiedene Dateien, die unsere Anwendung darstellen. So findest du zum Beispiel im node-modules-Ordner die verschiedenen Module, die über NPM nachgeladen wurden. Grundsätzlich wird dies im Projekt definiert, muss aber dann nicht mehr geprüft werden. Daher können wir diesen Ordner ignorieren. Unter den Dateien sind dann verschiedene Informationen, die der Fiori Generator erzeugt, wie verschiedene Readme und UI5 Dateien oder die verschiedenen Abhängigkeiten, die wir für unser Projekt benötigen, genauso wie die UI5-Konfiguration.

Der wichtige Teil unserer Anwendung liegt im webapp-Folder. Dort liegen die verschiedenen Dateien, Übersetzungen und die Konfiguration der Anwendung, die wir später für den Betrieb benötigen. Dabei ist der zentrale Punkt die manifest.json, die viele Einstellungen zu unserer Anwendung definiert. Hier finden wir zum Beispiel den Projektnamen, verschiedene UI-Versionen und die Datenquellen für den Service, also welcher OData-Service verwendet wird. Aber auch Strukturen zur App, wie das Routing, welches den Pfad zu den unterschiedlichen Seiten definiert. Ebenso die Definition des List Reports und der Object Page, zum Beispiel mit einer zweiten Object Page für die Nachrichten.

Per Rechtsklick auf das Verzeichnis können wir weitere Optionen laden, die wir im Projekt einsetzen können. So haben wir die Application Info, den Preview, um die Anwendung überhaupt erst mal sehen zu können, das Guided Development für die Erweiterung und die Page Map zum Beispiel, um die Struktur unserer Anwendung in einer Übersicht zu erhalten.

Öffnen wir im ersten Schritt einmal die Application Info, erhalten wir größtenteils die Informationen zu unserer Anwendung wie den Generierungsstand, welche Seiten generiert wurden, aber auch ganz viele wichtige Links zu Tools, die wir später noch benötigen. So können wir uns zum Beispiel auch die Page Map anzeigen lassen. Hier sehen wir, dass wir einen List Report auf oberster Ebene haben, über diesen auf die Object Page navigieren und von dort aus theoretisch auf eine weitere Object Page für die verschiedenen Nachrichten navigieren können. Zusätzlich haben wir weitere Einstellungen, die die Anwendung betreffen, aber auch die verschiedenen Seiten.

Wollen wir die Navigation auf die Object Page für die Nachrichten verhindern, können wir diese Seite einfach aus dem Projekt löschen. Dementsprechend sehen wir zwar die Liste auf der Object Page für das einzelne Objekt, können dann aber nicht mehr weiter navigieren, da es die Object Page für die Nachrichten nicht mehr gibt. Mit dem Stift können wir dann zum Beispiel auch die nächste Seite editieren. Hier sehen wir die verschiedenen Details zum Aufbau und verschiedene Eigenschaften, die wir noch anpassen können. Alles in allem ist dies erst einmal ein grafischer Editor, um weitere Konfigurationen ganz einfach vornehmen zu können.

Weiterhin können wir auch aus der Application Info zusätzliche Konfigurationen anlegen, hier zum Beispiel für die Launchpad-Konfiguration, und dort werden dann auch die verschiedenen Felder vom System abgefragt, wie die Navigation Targets.

Hierbei wollen wir nicht auf alle Fiori Tools eingehen, sondern erst einmal anhand eines Beispiels zeigen, welche Punkte an einer Anwendung wichtig sind, wie sie grob strukturiert ist, wie man damit arbeiten kann und wie du weitere Informationen aus dem Projekt holen kannst.

 

Zusammenfassung

Fassen wir damit noch einmal die aktuelle Präsentation zusammen, bevor wir dann zum eigentlichen Ende kommen. Die Grundlagen sind besonders wichtig, um gute Anwendungen zu bauen. Wir sollten wissen, wie eine Anwendung aufgebaut und strukturiert ist, um später Erweiterungen durchzuführen, aber auch wissen, worauf wir dabei achten sollten. Die Annotationen kommen hierbei nicht aus der lokalen Anwendung, sondern werden immer wieder aus dem Backend geladen und sollten auch dort bleiben, um schnellere Anpassungen zu ermöglichen. Dies erlaubt uns die Erweiterung von Anwendungen, welche nötig wird, wenn wir allein über Backend-Annotationen nicht mehr in der Lage sind, die gewünschten Features umzusetzen.

Als Nächstes sollten wir auf unsere Tools schauen, die wir nutzen. Hier kannst du dich aktuell entscheiden, ob du VS Code lokal installieren möchtest oder das Business Application Studio verwendest. Dabei hat das Business Application Studio den Vorteil, dass es komplett fertig ausgeliefert und immer wieder aktualisiert wird, was bei einer lokalen Installation alles manuell gemacht werden muss, also die richtigen Tools suchen, die Updates einspielen und die Verwaltung der Anwendung durchführen. Wichtig ist hierbei, dass du deine Tools kennenlernst und auch zu nutzen weißt. Du solltest also wissen, wie du eine Anbindung an Git vornimmst, wie du mit den lokalen Dateien arbeitest, wie du den Wizard aufrufst oder auch die verschiedenen Fiori Tools nutzt.

Als Letztes geben wir dann noch den Hinweis, dass es mithilfe von AI auch möglich ist, im Pair Programming zu arbeiten. Das heißt, das LLM kann dich dabei unterstützen zu lernen, wie man Erweiterungen durchführt, und dir Tipps geben, wie du mit deiner Anwendung umgehst. Gleichzeitig kannst du noch Inspiration von den verschiedenen Designs bekommen, die das LLM nutzt und aufbaut. Und grundsätzlich kannst du natürlich alles fragen, was du lernen möchtest, sozusagen als bester Entwicklungsbuddy.

Damit sind wir wieder am Ende der heutigen Session. Auf der linken Seite findest du den Download der Präsentation und auch noch weitere Ressourcen, die dir helfen sollen, Fiori Elements für ABAP-Entwickler besser zu verstehen und zu lernen sowie die verschiedenen Tools kennenzulernen. Ein Blick in die Sammlung lohnt sich auf jeden Fall. Auf der rechten Seite findest du den QR-Code zu unserem LinkedIn-Profil, über den du dich mit uns verbinden kannst, wenn du noch weitere Informationen oder Lernmaterialien suchst. Bis dahin vielen Dank fürs Zuschauen und bis zum nächsten Mal!

 

YouTube
Video