Fiori für ABAP - Application Log
Wie bekommen wir eigentlich die Daten unseres Application Logs in unsere Fiori Anwendung? Dazu erweitern die Anwendung durch eine Re-Use Komponente und schauen uns die Konfiguration an.
Inhaltsverzeichnis
In diesem Artikel implementieren wir die Re-Use Komponente um das Application Log in unserer Anwendung zu sehen. Dabei schauen wir uns die verschiedenen Vorraussetzungen an.
Einleitung
In einem älteren Artikel hatten wir auch unsere Sales App um das Application Log hinter einer Prüfaktion erweitert. Wie sieht es nun eigentlich aus, wenn wir das Application Log in unserer Anwendung anzeigen wollen? In diesem Artikel gehen wir auf das Thema „Anzeige des Application Logs“ und den Einbau in unsere Fiori Elements-Anwendung ein und schauen uns die verschiedenen Schritte und Techniken an. Dabei werden wir die Re-Use Komponenten im Fiori Elements Bereich kennenlernen.
Erweiterung
Beginnen wir im ersten Schritt mit der Erweiterung der Anwendung, da wir später noch einige Schritte im Deployment und in den Berechtigungen durchführen müssen. Damit ist der Einbau der Fiori-Komponente der kleinere Teil. Hier geht es vor allem später um das Thema Berechtigungen, die Bereitstellung der Daten und den entsprechenden Service. Dazu erweitern wir die Manifest Datei an bestimmten Punkten.
Bibliothek
In einem anderen Artikel haben wir uns den Aufbau der Manifest-Datei angeschaut. Dabei finden wir im SAPUI5-Bereich verschiedene Libraries, die durch unsere Anwendung verwendet werden. Hier müssen wir im ersten Schritt die Erweiterung durchführen und die Reuse-Komponente in die Libraries aufnehmen.
"libs": {
"sap.m": {},
"sap.ui.core": {},
"sap.fe.templates": {},
"sap.f": {},
"sap.nw.core.applogs.lib.reuse": {
"lazy": true
}
}
Du findest die neue Library im letzten Abschnitt des libs-Knotens. Bei den Dependencies wurde auch die Eigenschaft lazy auf true gesetzt. Damit wird das Lazy Loading aktiviert, sodass zuerst unsere Anwendung geladen und später die Komponente nachgeladen wird. Auf diese Weise startet unsere Anwendung schneller, und das Laden kann später parallel erfolgen, ohne die eigentliche Anzeige und Verfügbarkeit der Anwendung zu beeinflussen.
Custom Section
Im nächsten Abschnitt müssen wir eine Custom Section hinzufügen, und zwar direkt auf unserer Object Page. Laut Dokumentation werden aktuell nur Object Pages unterstützt, auf denen wir unser Segment einfügen können. Da wir bereits in einem anderen Artikel eine Erweiterung vorgenommen haben, besitzen wir schon den Part der Sections auf unserer Object Page und können den Code aus dem Beispiel einfach einfügen.
"ApplicationLogComponent": {
"title": "Data Validation",
"embeddedComponent": {
"name": "sap.nw.core.applogs.lib.reuse.applogs",
"settings": {
"logHandle": "{LoggingId}",
"tableType": "ResponsiveTable"
}
},
"position": {
"placement": "After",
"anchor": "idGeneral"
}
}
Nach dem Einfügen müssen wir bestimmte Punkte anpassen. So können wir zum Beispiel den Namen der Komponente frei vergeben, in diesem Fall haben wir "ApplicationLogComponent" verwendet. Dann vergeben wir einen Titel, der über dieser Section angezeigt wird und binden die Embedded Component ein. Im Bereich settings definieren wir unser eigentliches Feld, in dem die Log-ID enthalten ist, und müssen zum Abschluss noch die Position der eigenen Section definieren. In diesem Fall platzieren wir sie nach der General-Section, also nach der ersten Section auf unserer Object Page.
Anzeige
Damit wir nun die Anzeige des Application Logs testen können, müssen wir das Business Application Studio verlassen. Denn hier wird aktuell nur ein leerer Bereich angezeigt, und wir haben keine Möglichkeit, das Application Log richtig zu testen.
Vorbereitung
Dazu müssen wir im nächsten Schritt, nach der Anpassung unserer App, noch einmal in das ABAP Environment deployen. Dies können wir wieder über die Application Info machen oder über die Konsole, je nachdem, was du bevorzugst. Wie genau das Deployment funktioniert, ist in diesem Artikel beschrieben, dort findest du auch einiges mehr zur Konfiguration.
Ist das Deployment im ABAP Environment abgeschlossen, müssen wir noch einige Anpassungen an unserer IAM-App durchführen, damit wir die passenden Berechtigungen erhalten. Wir benötigen hier Berechtigungen für den Service, aber auch die Berechtigung für das eigentliche Application Log, um dieses lesen zu können und uns die Inhalte anzuzeigen. Wie in der Dokumentation unten beschrieben, müssen wir zuerst den allgemeinen Service hinzufügen, der für das Lesen des Application Logs benötigt wird. Dieser hat eine spezielle Anforderung, nämlich dass eine entsprechende Anzahl an Leerzeichen zwischen der Version und dem eigentlichen Servicenamen gesetzt ist. Dazu das folgende Template zum Kopieren:
APL_LOG_MANAGEMENT_SRV 0001
Der Eintrag des Services in der IAM App sollte nun wie folgt aussehen. Dabei haben wir einen Service der originär für die Bereitstellung der Anwendung zur Verfügung steht. Und nun einen zweiten Service, der die Informationen aus dem Application Log Der Komponente zur Verfügung stellt.
Damit unsere Anwender auch die Berechtigung auf das Application Log haben, müssen wir auf den Reiter "Authorizations" in der IAM-App wechseln. Dort müssen wir das Berechtigungsobjekt S_APPL_LOG hinzufügen und entsprechend die Werte ausprägen, damit wir uns die Werte für unser gespeichertes Application Log auch ansehen können.
Test
Haben wir die Berechtigungen entsprechend angepasst und die Anwendung deployt, können wir einen ersten Test im Launchpad durchführen. Dazu rufen wir unsere eigentliche Anwendung auf und öffnen eine Object Page, wo wir entweder schon ein Application Log erzeugt haben oder wo wir gleich ein Application Log erzeugen. Dazu einfach den Button "Check consistency" drücken, um die Prüfung zu starten und ein neues Application Log Handle zu erzeugen.
Damit funktioniert das Application Log Out-of-the-Box mit den Standardeinstellungen. Wir sehen die Typen von Meldungen, die eigentliche Meldung und das Erzeugungsdatum. Im oberen Bereich findest du verschiedene Einstellungen, wie den Filter nach den Typen und das Ausblenden der verschiedenen Filter. Im unteren Teil haben wir eine zusätzliche Suchoption und verschiedene Einstellungen für die Liste.
Einstellungen
Schauen wir uns einmal noch die möglichen Einstellungen an, die wir vornehmen können. Diese Einstellungen werden im Control in der manifest.json-Datei gemacht. Das heißt, wenn wir Einstellungen vornehmen, müssen wir immer wieder ein Deployment ins System machen, um die Änderungen in unserer Anwendung zu sehen. Für die Einstellungen gibt es im Controller einen eigenen Settings-Bereich, wo wir verschiedene Attribute hinzufügen können, die Sie auch in der Dokumentation noch einmal beschrieben finden. Testen wir einige Attribute aus.
Im Standard ist das Settings-Objekt bereits gesetzt. Hier finden wir das Log-Handling und den Tabellentyp als Standard definiert. Aus der Dokumentation sehen wir, dass wir zum Beispiel den Header ausschalten und die Filter-Bar deaktivieren können. Das machen wir, indem wir die Attribute auf "false" setzen. Was in der Dokumentation leider nicht sehr gut beschrieben ist, ist, dass uns hier true und false zur Verfügung stehen, welche als boolesche Werte definiert werden. Als dritten Testwert setzen wir den Titel der Tabelle, das ist der Punkt, der direkt über der Tabelle steht, als Text und fügen dort einfach "More ..." ein.
"settings": {
"logHandle": "{LoggingId}",
"tableType": "ResponsiveTable",
"showHeader": false,
"showFilterBar": false,
"tableTitle": "More ..."
}
Führe wir nun noch einmal das Deployment aus dem Business Application Studio durch und aktualisiere danach unsere Anwendung, um die Änderungen direkt sehen zu können. Sollte eine Konfiguration fehlen, empfiehlt sich ein Blick in die Konsole. In unserem Fall gab es beispielsweise Probleme mit den booleschen Werten. Hier kann es vorkommen, dass das Control gar nicht mehr lädt, weil die Einstellungen schlichtweg falsch sind. Wenn keine Fehler in der Konsole angezeigt werden, sollte das Control neu laden und entsprechend angepasst dargestellt werden.
Für die Filterung können wir auch den allgemeinen Textfilter im oberen Bereich der Tabelle nutzen. Wenn wir hier beispielsweise nach „Quota“ filtern, werden ausschließlich die Meldungen angezeigt, die diesen Text enthalten. Dadurch sind wir nicht zwingend auf die eigentliche FilterBar angewiesen und können stattdessen die einfache Suchfunktion nutzen.
Vollständiges Beispiel
Die gespeicherten Ressourcen zu unserer Anwendung findest du in unserem GitHub Repository. Damit kannst du in Zukunft alle Anpassungen an der Fiori App mit nachvollziehen oder die Ressourcen für ein Deployment nutzen. Die aktuellen Änderungen findest du in diesem Commit wieder.
Fazit
Die Implementierung des eigentlichen Application Logs und der Anzeige ist nicht unbedingt kompliziert, da es hierfür ein gutes Reuse-Control direkt von SAP für Fiori Elements gibt. Allerdings sind der Test und die Konfiguration etwas herausfordernd und könnten zu Problemen führen. Auch das Thema Berechtigungen könnte unter Umständen zu logischen Fehlern und Fehlersituationen führen.
Weitere Informationen:
SAP Help - Fiori Reuse Component
SAP Help - Integration OData v4
