SAP Fiori und Micro Frontends
Seit einigen Jahren gestalten wir in Projekten den Weg von Monolithen zu Microservices. Bisher allerdings meist mit dem Fokus auf die Backend-Systeme und dem Ziel, dass Applikationslogik getrennt und in Container gepackt wird. Seit Anfang 2020 erleben wir einen ähnlichen Trend auf dem Frontend: Micro Frontends. Bereiche einer Frontendapplikation werden getrennt und unabhängig voneinander entwickelt. Das Endprodukt ist für den User weiterhin eine Frontendapplikation. Der Vorteil ist, dass eine Frontendapplikation mit unterschiedlichen Programmiersprachen entwickelt werden kann und dass die ausgelagerten Bereiche wiederverwendbar sind. Mit SAP Fiori Anwendungen sind wir an eine Programmiersprache gebunden, möchten aber dennoch den Vorteil der Wiederverwendbarkeit nutzen.
In einigen Projekten haben wir den Fall, dass Views mit ihrer Logik in mehreren Applikationen ausgeführt werden sollen. Dieser Blog Eintrag von QUANTO Solutions soll eine Möglichkeit aufzeigen, wie Bereiche einer SAP Fiori App oder einer SAP UI5 App ausgelagert und wiederverwendbar sein können. Dabei bleiben die Vorteile und die Features die SAP mit dem SAP Fiori Launchpad und den SAP Fiori Design Guidelines bietet, bestehen. Dazu zählt auch die Kompatibilität mit mobilen Endgeräten. Die SAP Fiori Apps oder SAP UI5 Apps müssen in einem SAP Fiori Launchpad laufen, unabhängig davon ob On-Premise oder in der SAP Cloud.
Das Ziel ist es, eine „Provider“ App in mehreren anderen „Consumer“ Apps nahtlos einzubinden. In unserem Beispiel wird für das User Interface das FlexibleColumnLayout von SAP Fiori mit den zwei Spalten „Master“ und „Detail“ genutzt. Dabei ist die Master-View unsere Consumer App und die Detail-View ist unsere Provider App. Beide Apps basieren auf SAP Fiori Elements.
Mit dieser Architektur haben wir den Vorteil, dass es nur eine App gibt die in mehreren anderen SAP Fiori Apps als Detail-View dargestellt wird. Änderungen und Erweiterungen der Detail-View müssen nur in eine App entwickelt werden. Die Provider App kann nämlich in mehreren Consumer Apps eingebunden werden.
How to
Wir benutzen für dieses Beispiel die SAP Web IDE. SAP bietet mit der Entwicklung in der SAP Cloud Platform viele Vorteile.
Unsere Apps entsprechen den Fiori Design Guidelines und wir benutzen für die Provider App eine Object Page, welches aus der Layoutsammlung von SAP Fiori Elements ist. Das Prinzip der Wiederverwendbarkeit kann aber genauso auch mit anderen IDE’s realisiert werden, wie z.B. Visual Studio Code.
Beide Apps müssen dabei in einem SAP Fiori Launchpad deployed sein. Ein Testen der Integration in der SAP Web IDE Testumgebung ist leider nicht möglich, da beide Apps deployed sein müssen.
Consumer-App
In der Consumer App muss die Provider App registriert und geladen werden. Das sollte direkt beim initialen Laden der App in der init Funktion der Component.js passieren:
init: function () {
jQuery.sap.registerModulePath("dokument","/sap/bc/ui5_ui5/sap/provider");
sap.ui.require("dokument.Component");
...
}
Code Beispiel Component.js
Beim Registrieren des Moduls wird der Pfad zur App angegeben. Wenn die Apps auf einem SAP Fiori Launchpad On-Premise laufen, lautet der Pfad z.B. „/sap/bc/ui5_ui5/sap/[AppName]“. In der SAP Cloud lautet der Pfad „../sap/fiori/[AppName]“.
Da wir das FlexibleColumnLayout nutzen, wird für den Aufruf der Detail-View das SAP UI5 Routing benutzt. Damit wir unsere Provider App als Detail-View einschleusen können, muss das Routing auf eine Detail-View in der manifest.json eingestellt werden. Damit können auch diverse Variablen übergeben werden. Die Detail View muss wissen welche Detaildaten geladen und angezeigt werden sollen. Durch das Übergeben von Variablen im Routing informieren wir die Detail View damit:
...
{
"pattern": "dokument/{var}/{layout}",
"name": "dokument",
"target": [
"TargetView1",
"dokument"
]
}
"targets": {
...
"dokument": {
"viewName": "Detail",
"viewId": "Detail",
"viewType": "XML",
"controlAggregation": "midColumnPages"
}
}
Code Beispiel manifest.json
Die Detail-View in der Consumer App muss jetzt nur noch die Provider App einbinden. Daten und Einstellung für die Provider App können über die Settings Property übergeben werden. In diesem Beispiel haben wir ein JSON-Model mit dem Namen „params“ erstellt und dem Component Container mitgegeben:
<core:ComponentContainer
width="100%"
name="provider"
component="provider"
settings="{params>/}">
</core:ComponentContainer>
Code Beispiel Detail.view.xml
Der Detail Controller kann nun das „params“ Model füllen und damit Einstellungen der Provider App bekannt machen oder einfach nur Daten übergeben.
Üblicherweise muss die Provider App Funktionen der Consumer App aufrufen. Das Maximieren, Minimieren und Schließen kann zum Beispiel nur von der Consumer App gesteuert werden, wird aber nach dem SAP Fiori Guidelines aus der Provider App vom Enduser aufgerufen. Da die Provider App keine Funktionen aus der Consumer App direkt aufrufen kann, wird ein Umweg benötigt. Über den Event-Bus können Funktionen registriert und von überall aus aufgerufen werden. Für die Funktionalitäten kann der Event-Bus verwendet werden. Weitere Informationen zum Event-Bus sind in diesem SAP Blog zu finden.
Die Funktionen für das Maximieren, Minimieren und das Schließen werden von der Consumer App im Event-Bus registriert:
onInit: function () {
…
const bus = sap.ui.getCore().getEventBus();
bus.subscribe("com.quanto.solutions.eventBus", "close", this.onClose, this);
},
…
onClose: function () {
this.getOwnerComponent().getRouter().navTo("master");
},
Code Beispiel Detail.controller.js
Und die Provider App kann diese Funktionen im Event-Bus ausführen:
onClose: function () {
sap.ui.getCore().getEventBus().publish("com.quanto.solutions.eventBus",
"close", {});
},
Code Beispiel Detail.controller.js
Dabei wird die ID „com.quanto.solutions.eventBus“ verwendet. Die ID sollte eindeutig sein und andere Apps sollten diese nicht verwenden.
Provider App in SAP Fiori oder SAP UI5
Die Provider App kann als normale SAP Fiori oder SAP UI5 App entwickelt werden. In unserem Beispiel nutzen wir das Object Page Layout und diese wird als Component in die Consumer App eingebunden. Es müssen keine sonstigen grundlegenden Einstellungen vorgenommen werden.
Die Provider App muss den Input der Consumer App verarbeiten können. Da wir in der Consumer App die Daten in die Settings der Component geschrieben haben (Siehe Kapitel Consumer App), können wir das einfach auslesen:
onInit: function () {
const params = this.getOwnerComponent().oContainer.getSettings();
const object = params.componentData.startupParameters;
},
Code Beispiel Provider.controller.js
In diesem Beispiel werden die Daten vom Consumer in der Objektstruktur „params.componentData.startupParameters“ geschrieben. Das ist optional und es kann auch eine andere Struktur gewählt werden. Im Provider können die Daten verarbeitet und an die View gebunden werden. Damit lässt sich die Provider App erstmal nicht mehr Standalone ausführen, weil nun die Settings der Component benötigt werden. Das kann umgangen werden, indem das Laden der Parameter optional gestaltet wird. Falls die Daten da sind, werden sie geladen. Ansonsten können die Daten zum Beispiel aus dem Routing geladen werden. Damit kann die Provider App auch völlig unabhängig vom Consumer agieren und das Testing und die Entwicklung in der SAP Web IDE wird vereinfacht.
Bei dem Deployment auf einem On-Premise System oder in der SAP Cloud muss für die Provider App kein Katalog, Gruppe oder Kachel angelegt werden. Damit ist die Provider App auch nicht als eigene Kachel sichtbar und ein Anwender kann die Provider App nicht ohne eine Consumer App aufrufen.
Fazit: SAP Fiori und Micro Frontends
Mit dem richtigen Know-How ist es sehr einfach, Fiori Apps technisch zu trennen und wieder zu verwenden. Die großen Vorteile sprechen für sich und macht die Entwicklung und die Pflege der SAP Fiori oder SAP UI5 Apps viel einfacher. Einer Änderung oder eine Erweiterung der Detail View (Provider App) muss nur einmal entwickelt werden. Die Entwicklung von SAP Fiori Apps kann zudem getrennt werden. Wenn die Detail-View sich aber je nach Consumer App anders verhalten soll, muss entschieden werden ob es sich lohnt die Detail-View zu vereinheitlichen. Sobald der Unterschied des Verhaltens zu groß wird, lohnt es sich meistens nicht den Provider auszulagern.
Die fusionierte App funktioniert nahtlos und der Enduser merkt nichts. Durch das Einhalten der SAP Fiori Design Guidelines werden auch keine Nachteile eingeholt. Das Backend ist völlig unabhängig und SAP HANA kann z.B. weiterhin verwendet werden.
Falls Sie ähnliche Anforderungen haben, einen qualifizierten Berater benötigen oder sich gerne austauschen möchten, kontaktieren Sie uns gerne.
Author: Martin Zaman
Weiterführende Links:
https://t3n.de/magazin/micro-frontends-modular-entwickeln-244415/
