Der Weg zur ersten Fiori App

Jean-Francois Taté Tsiledze unterstützt derzeit als Praktikant das Team Portal Integration sowie UX. Eine seiner ersten Aufgaben bestand darin für unsere Blog-Leser einen Beitrag zur Erstellung einer Fiori App zu erstellen. Im folgenden Beitrag erfahren Sie Schritt für Schritt, wie Sie dabei vorgehen und worauf Sie aus Entwicklersicht achten sollten.

Für Einsteiger und Fortgeschrittene bietet SAP eine große Auswahl an Dokumentationen und Hilfsmitteln zur Erstellung einer Fiori App[1]. Zum Verständnis von Fiori-Implementierungs- und Designkonzepten stehen folgende Webseiten zur Verfügung:

• Fiori Guidelines: Design- und Implementierungsrichtlinien für Fiori Apps
• openSAP: Online-Kurse, u.a. auch für die Strategieentwicklung, Konzeption und Architektur von Fiori UX sowie die Implementierung von Fiori inklusive der Einrichtung der Entwicklungsumgebung sowie der Einführung von SAP Web IDE und SAPUI5 API
• SAPUI5 Demo Kit: API-Dokumentation und Code-Beispiele

[1] Im eigentlichen Sinne handelt es sich diesem Text um die Erstellung einer Fiori-Like-App (Eigenentwicklung auf Basis des SAPUI5-Framework unter Beachtung der SAP Fiori Design Guideline). Unter folgendem LINK (AppLibrary) finden Sie „echte“ (fertig entwickelte, durch die SAP zur Verfügung gestellte) SAP Fiori Apps.

Wie sieht nun der konkrete Weg zur ersten Fiori App aus?

Zunächst einmal wird ein Account für die HANA Cloud Platform (HCP) benötigt, um dadurch Zugang zu SAP Web IDE zu erhalten. Ein Zugang auf ein eigenes On-Premise SAP-System über den HCP ist hilfreich, aber technisch nicht notwendig. Neben der Frontend-Entwicklungsumgebung SAP Web IDE gibt es alternativ noch die Eclipse IDE mit SAPUI5-Entwicklungs-Tools. Diese wird allerdings von SAP nicht empfohlen und nicht mehr unterstützt, so dass der Beitrag sich im weiteren Verlauf nur auf die SAP Web IDE konzentrieren wird.

Als weitere Voraussetzung sollten Sie das SAP Launchpad als Software as a Service in der SAP HANA Cloud (SaaS) oder in dem SAP Gateway mit SAP NetWeaver Frontend Server einrichten. In beiden Fällen ist ein Gateway, das an HCP angeschlossen ist, notwendig. Das Gateway ist für die Bereitstellung der OData-Services zuständig, dient damit als Schnittstelle zwischen Frontend und Backend, und als Frontend Server für das Launchpad und die Fiori-Anwendungen. Außerdem übernimmt es die initiale Authentifizierung des Anwenders. Das SAP-System als Backend (ABAP Backend Server) beinhaltet und verwaltet die Daten sowie die Business-Logik, Rollen und Berechtigungen. Das Gateway sowie das Backend-System können in getrennten Systemen oder in einem System eingerichtet werden. Auf Basis unserer Erfahrungen sowie der Best Practices von SAP empfehlen wir allerdings die Einrichtung auf getrennten Systemen. (Mehr dazu im CONET-Blog)

[1] Im eigentlichen Sinne handelt es sich diesem Text um die Erstellung einer Fiori-Like-App (Eigenentwicklung auf Basis des SAPUI5-Framework unter Beachtung der SAP Fiori Design Guideline). Unter folgendem LINK (AppLibrary) finden Sie „echte“ (fertig entwickelte, durch die SAP zur Verfügung gestellte) SAP Fiori Apps.

Was ist aus Entwicklersicht zu berücksichtigen?

Eine Fiori App benötigt sowohl verschiedene technische Komponenten als auch verschiedene Entwicklungskompetenzen (BE und FE). Die technischen Komponenten bestehen aus einem Backend-Anteil, den GW Service und dem Frontend, implementiert mit SAPUI5. Als Entwickler sollten Sie vor allem darauf achten, dass Sie die Struktur der Daten im Backend kennen, was zu welchem Zweck angezeigt wird (Definition des OData-Modells) und welche Funktionsbausteine (FuBA) in SAP dadurch gesteuert bzw. angestoßen werden oder die Unterstützung von einem Fachkollegen bekommen. Dies ist wichtig, da die Abbildung des OData-Datenmodells als FuBA im SAP-Backend zur Generierung von OData-Services führt. Die OData-Services bilden die Schnittstelle zwischen dem Backend mit Logik und dem Frontend. Der Backend-Entwickler kümmert sich darum, die FuBA anzupassen und diese über die BAPI als Schnittstelle anzubieten. Der Frontend-Entwickler muss dann ein Datenmodell entwerfen, welches die ABAP-Felder von der BAPI repräsentiert. Dadurch entsteht das OData-Modell.

Das zentrale Werkzeug, um Services in SAP Gateway zu definieren und zu implementieren, ist der SAP Gateway Service Builder (Transaktion SEGW), über den das Datenmodell im Backend mit den benötigten BAPI-Komponenten gemappt wird, um letztlich die Kommunikation zwischen Frontend und Backend zu gewährleisten. Daraus entstehen die Services, die als Funktionalitäten einer Anwendung anzusehen sind. Danach müssen die Laufzeitartefakte des SEGW-Projekts generiert werden, um die Modelldefinition (Model-Provider-Klasse) sowie die zugehörigen Daten (Data-Provider-Klasse) im System zu hinterlegen. Anschließend wird der OData-Service im Gateway registriert und somit für den Client ansprechbar. Zur Kommunikation zwischen dem SAP Gateway und dem Frontend wird das OData-Protokoll verwendet. Dies ist ein REST-full Service (Webservice), der durch CRUD-Methoden (Create Read Detail und READ Query, Update, Delete) Daten bidirektional austauschen kann, um die Entitäten (z.B. Material) bzw. Entitätsmengen (z.B. alle Materialien) zu erstellen, zu aktualisieren, zu löschen oder auszugeben. Zusammenfassend lässt sich sagen, dass das OData-Protokoll die Kommunikation zwischen Client/Browser (der die Services nutzen will) ermöglicht und der Server (ABAP NW FES), welcher die HTTP-Methoden GET, POST, PUSH und DELETE bietet, Daten abfragt, erstellt, updated oder löscht.

Wie entsteht nun das Frontend der Fiori App?

Um ein Projekt zu erstellen, benötigen Sie SAP Web IDE. Web IDEs sind Werkzeugkästen, aus denen sich Web-Anwendungen einfach und ohne tiefgreifende Programmierkenntnisse zusammenstellen lassen. Mit dem Toolkit SAP Web IDE können Designer und Analysten über Vorlagen, Drag & Drop und mit detaillierten Anleitungen eigene Fiori Apps und andere Anwendungen erstellen, ohne selbst einen Code schreiben zu müssen. Die SAP WEB IDE ist eine neue, im Browser lauffähige Entwicklungsumgebung – bis vor kurzem unter dem Namen River RDE bekannt. Diese läuft lokal auf Einzelrechnern, On-Premise (also auf den Servern des eigenen Netzwerks) und in der Cloud. Die On-Premise-Version wird auf einem Rechner installiert und über einen Browser aus einem lokalen Server (localhost) oder zentral über die Unternehmensressource aufgerufen. Der Zugang zur Cloud-Version erfolgt über den HCP-Account. Allerdings ist die Verwendung der Cloud-Version zu empfehlen, da diese deutlich aktueller ist und mehr Funktionen bietet als die lokale und On-Premise-Version.

Im ersten Schritt wählen Sie nun ein Projekt-Template aus, welches Ihnen eine vorgefertigte Struktur mit Design und Konfiguration bietet. Während der Projekterstellung wird der Benutzer durch eine Anleitung (Wizard) geführt, die ihm zeigt, wie er das Template für das Projekt auswählt, einen Namen und Beschreibung vergibt und die primäre Entitätsmenge aus dem Service an die Oberfläche anbindet. Das Datenset aus dem OData-Service ist damit direkt mit der App verknüpft.

In Abhängigkeit von den Anforderungen werden die Views und Controller angepasst. Die Web IDE bietet mit dem Layout Editor eine Möglichkeit die UI-Komponente per Drag und Drop an die Views hinzufügen und direkt an den Modellen, die die Backend-Daten beinhalten, zu binden. Der Layout Editor dient der schnellen Anpassung und Erstellung von Oberflächen (WYSIWYG) und unterstützt die Funktionssteuerung des Controllers (Buttons, Suchfelder etc.). Zusätzlicher Codierungsaufwand entsteht je nach Projektumfang und erfordert Programmierkenntnisse in HTML5, CSS und vor allem in JavaScript. Sobald Sie diese Schritte abgeschlossen haben, ist das Projekt lauffähig und kann direkt mit

• echten Daten aus dem Backend
• oder mit Beispieldaten (Mock-Daten), die automatisch oder manuell generiert werden können,

Sind die Tests erfolgreich abgeschlossen, steht das Deployment bevor. Hierfür bietet SAP Web IDE folgende drei Möglichkeiten:

• Rollout der neuen Anwendung auf einen ABAP Frontend Server oder
• Rollout auf der HANA Cloud Platform
• Manueller Export aus der WebIDE und manueller Import auf das GW-System

Dabei wird die Web-Applikation versioniert und auf einen GIT Cloud Repository hinterlegt.

Das Deployment auf einem ABAP Repository geschieht über eine Anleitung in der Web IDE, in der das Zielsystem und das Service-Paket sowie der Name und die Beschreibung der Applikation abgefragt werden. Falls es sich nicht um ein lokales Paket handelt, wird ein Transportauftrag angegeben oder angefragt. Nach der Bestätigung wird das Ausrollen angestoßen und der Verlauf kann auf der integrierten Konsole beobachtet werden.

Einrichten der App

Sobald die App auf einem Gateway geladen ist und sich damit auf dem Frontend Server befindet, muss sie einer Launchpad-Rolle als Zusammenstellung von Links für spezifische Benutzer zugeordnet werden. Zudem wird ein semantisches Objekt erstellt, um das Launchpad mit der Applikation zu verknüpfen und ermöglicht somit die Navigation in den Launchpad. Über die URL http://<yourservername>:<port>/sap/bc/ui5_ui5/sap/arsrvc_upb_admn/main.html wird die administrative Seite des Launchpads aufgerufen. Hier wird die App einem Katalog und einer Gruppe zugeteilt, um diese für die User zu kategorisieren, die Zugriff auf den Launchpad-Katalog haben sollen. Eine Kachel als Zugangspunkt der Applikation wird ebenfalls mit Titel und Icon erstellt.

Nun haben Sie es geschafft: Jeder berechtigte Nutzer kann anschließend die Applikation über http://<yourservername>:<port>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html aufrufen und durch klicken auf eine Kachel, das semantische Objekt der darunter liegenden App am Ende der URL einfügen. Das Launchpad kann sich der Nutzer in Abhängigkeit seiner Wünsche gestalten.