BTP - Key User Extensibility (Rollenbasiert)
In diesem Aritkel wollen wir uns anschauen, wie wir über die Key User Extensibility eine rollenbasierte Sicht in einer Standard App zur Verfügung stellen und was du dabei mit der Arbeit beachten solltest.
Inhaltsverzeichnis
Heute schauen wir uns die Key User Extensibility für "Adapt UI" an, gehen die rollenbasierte Änderung an und prüfen auch die möglichen Herausforderungen bei so einer Lösung.
Einleitung
SAP ist bekannt dafür auch für die Erweiterbarkeit zu stehen. Damit kann jeder Kunde seine Software nach individuellen Gesichtspunkten anpassen und auf die eigenen Prozesse zuschneiden. Diese Flexibilität bei der Implementierung möchte SAP auch bei der Clean Core Strategie, ABAP Cloud und mit Fiori weiterverfolgen. Dafür gibt es zum Beispiel die Key User Extensibility, die für den Citizen Developer gedacht ist, der schnell und einfach den Standard erweitern möchte. Auch wenn heute zum Großteil Entwickler die Tools einsetzen, geben sie einfache und schnelle Möglichkeiten zur Erweiterung des Standards.
Adapt UI
Schauen wir uns einmal die Funktion "Adapt UI" an und gehen von einer kurzen Übersicht in die Details der Verwendung.
Übersicht
In diesem Artikel wollen wir näher auf "Adapt UI" eingehen. Hierbei kann eine Fiori Anwendung an verschiedenen Punkten erweitert und geändert werden. Dabei stehen einfache Änderungen im Fokus, wie ein Feld ausblenden, verschieben oder umbenennen, neue Bereiche anlegen und Aktionen ausblenden. Dabei verwenden wir alles, was der Standard-Service der Anwendung hergibt. Dahingehend sind Änderungen nicht möglich, wo wir auf neue Felder und Informationen zugreifen wollen, die es so nicht im Service gibt.
Berechtigungen
Nicht jeder User ist automatisch berechtigt diese Änderungen durchzuführen. Im ABAP Environment benötigen wir dazu den Business Catalog "SAP_CORE_BC_EXT_FLX_CUS_PC".
Funktionen
Hast du die entsprechenden Berechtigungen, können wir die eigentliche Anwendung aufrufen, die wir gleich im System anpassen wollen. Um den Anpassungsmodus zu starten, öffnest du dein persönliches Menü in der App, dort sollte nun der Punkt "Adapt UI" zu finden sein.
Schauen wir uns im nächsten Schritt einmal die verschiedenen Funktionen an, diese werden im oberen Teil der Anwendung verfügbar:
- Versionsmanagement - Hier können wir die verschiedenen Versionen und Änderungen sehen und auch wieder laden. So können wir zum Beispiel auch auf die Original-App zurückgehen. Über den "LKW" können wir dann die fertigen Konfigurationen transportieren.
- Bearbeitung - Aktuell stehen drei Bearbeitungsoptionen zur Verfügung, die wir für unterschiedliche Dinge verwenden können. Mit "UI Adaptation", sind wir im Modus, um Elemente auf dem aktuellen Bild anzupassen. Die Elemente und Buttons reagieren nun auf Rechts-Klick und führen nicht mehr die eigentliche Aktion aus. Mit "Navigation" funktionieren die ursprünglichen Elemente, wir können in der App navigieren oder eine Selektion ausführen. Durch "Visualization" sehen wir auf dem Bild in einem Blick, was wir geändert haben. Im Originalzustand der App wird nichts passieren, deshalb kann diese Option etwas verwirrend sein.
- Varianten - Hier haben wir die Möglichkeit die Variante zu speichern, andere Varianten zu laden oder zu löschen. Hier findest du auch die Optionen für Schritt vor und Schritt zurück.
Use-Case
In diesem Use-Case wollen wir einmal die Extensibility an der App "Manage Software Components" (F3562) verwenden. Wir möchten im UI den Großteil der ändernden Funktionen ausblenden und dem Entwickler die Aktion zum Exportieren von Commits lassen. Damit soll er später zwar keine Änderungen an der SWC machen können, aber die Logs der Importe sehen und auch Transporte in den Transport Service exportieren können.
Vorbereitung
Zur Vorbereitung benötigen wir zwei Testrollen, denen wir später die verschiedenen Sichten zuordnen können. Dazu legen wir über die Fiori App "Maintain Business Roles" (F1492) zwei neue Rollen im System an. Den beiden Rollen ordnen wir den Business Catalog SAP_A4C_BC_MSCL_PC (Lifecycle Management - Software Components) zu. Dieser berechtigt die App "Manage Software Components" für den User. Im ersten Schritt ordnen wir nun die Rolle ZBS_SWC_ADMIN unserem User zu.
Hinweis: Aktuell darf die Rolle nicht leer sein, sondern es sollte mindestens ein Objekt enthalten sein. Ansonsten wird der Kontext in der App nicht geladen.
Admin
Gehen wir nun als Admin in die App. Da wir vielleicht die Rolle des Admins und des Entwicklers haben, benötigen wir am besten eine Variante, die dem Admin zugeordnet ist und höher priorisiert ist, wenn die App geladen wird. Damit vermeiden wir, dass wir als Admin die Entwicklersicht bekommen und vielleicht keine Aktionen mehr ausführen können. Dazu wechseln wir in der App in den Adaptation Modus (siehe oben). Dann können wir ohne Anpassungen direkt eine Sicht speichern. Unter dem Punkt "Adapting for All Users" finden wir die Option eine neue Sicht zu speichern.
Im Dialog geben wir der Sicht einen neuen Namen und ordnen die entsprechenden Rollen mit der Priorität zu. Hierbei wollen wir zuerst die Admin Berechtigung erzeugen und verwenden daher die höchste Priorität. Über "Add Roles" können wir nun unsere Admin Rolle hinzufügen, für die die Sicht gelten soll. Zum Abschluss dann die neue Sicht speichern.
Developer
Nun können wir mit der Rolle des Entwicklers beginnen. Dazu arbeiten wir direkt in der Sicht weiter und beginnen die ersten Punkte im UI auszublenden. Dazu einfach auf die Elemente klicken, wie zum Beispiel der Create Button in der Liste zur Anlage einer neuen Software Komponente.
Dann wechseln wir von "UI Adaptation" zu "Navigation" und gehen in eine Software Komponente auf die Object Page. Dort können wir dann mit der Änderung fortfahren und die Aktionen im Header entfernen.
Auf Ebene der Liste bei den Branches können wir dann noch die eine Aktion entfernen und lassen "Export Commit" aktiv, da diese Funktion von den Entwicklern weiterhin benötigt wird.
Wir sind nun soweit mit den Anpassungen fertig und können die neue Sicht speichern. Dazu vergeben wir wieder einen Namen und ordnen die neue Sicht als zweite Priorität ein, damit sie nach dem Admin in der Reihenfolge kommt. Auch hier nicht vergessen, die neue Rolle zuzuweisen.
Um nun die Änderungen zu aktivieren, müssen wir im Bereich des Versionsmanagement den "Aktivieren" Button drücken und einen Namen für die neue Version geben. Damit sind nun alle Änderungen gespeichert und wir können im nächsten Schritt zum Test gehen.
Möchtest du später die Sichten transportieren, dann kannst du über den "LKW" die Version auf einen Transport aufzeichnen. Grundsätzlich kannst du Workbench und Customizing wählen, SAP empfiehlt aber den Transport per Customizing, wo du dann auch die Rollen mittransportieren kannst.
Test
Schauen wir uns nun einmal die UI an und gehen dazu auf die Object Page unserer Software Komponente ZBS_DMO aus einem älteren Artikel. Da wir aktuell noch die Admin Rolle haben, sehen wir weiterhin die verschiedenen Aktionen auf dem UI und können wie gewohnt damit arbeiten.
Wechseln wir nun im zweiten Schritt die Rolle, entfernen ZBS_SWC_ADMIN und geben uns ZBS_SWC_DEVELOPER. Gehen wir dann nach der Aktualisierung zurück in die Software Komponente, dann werden die Buttons nun ausgeblendet.
Über das Usermenü im rechten oberen Teil können wir über "About -> Application" den aktuell verwendeten Kontext finden. In diesem Fall wird der Developer gezogen.
Transport
Möchtest du die Änderungen auf das nächste System bringen, dann findest du im Adaptation Modus neben dem "Aktivieren" auch den Transport der Objekte. Damit werden die Änderungen auf einen Transport geschrieben.
Sicherheit
Du solltest allerdings beachten, dass in unserem Beispiel nur die Aktionen auf dem UI ausgeblendet sind. Die Funktionen sind weiterhin im Service aktiv und können auch immer noch verwendet werden, wenn du zum Beispiel den OData direkt aufrufst. Bei dem Beispiel ging es erst einmal nur um die Bereitstellung der Anwendung für die Entwickler und erfordert einen Vertrauensvorschuss, dass dann die anderen Funktionen nicht missbraucht werden. Den passenden Hinweis findest du auch noch einmal in der Dokumentation.
Fazit
Mit der neuen rollenbasierten Key User Extensibility müssen wir nicht mehr eine eigene App-Variante auf das System deployen, sondern können direkt die eigentliche App dem User zur Verfügung stellen. Je nach Rolle erhält dieser dann seine Sicht auf die Anwendung.
Weitere Informationen:
SAP Help - Adapting the UI for Specific Roles
