Über die Komplexität der Berechtigungsverwaltung in SAP Fiori

Offene Gespräche und der Erfahrungsaustausch mit vielen SAP-Kunden zeigen deutlich, dass bei der Einführung von SAP S/4HANA mit SAP Fiori insbesondere auch dem User Interface (UI) und der damit einhergehenden User Experience (UX) eine besondere Bedeutung und Tragweite beizumessen sind. Kunden, die sich für SAP Fiori als führende Frontend-Technologie entschieden haben, können aus eigener Erfahrung bestätigen, dass die Bereitstellung von Apps im Fiori Launchpad (FLP) zeitintensiver und aufwändiger ist als Transaktionen in der SAPGui zu berechtigen. Kunden, denen das noch bevorsteht, möchten wir mit diesem Beitrag entsprechende Erklärungen liefern, warum dies so ist.

Warum an SAP Fiori kein Weg vorbei führt

Obwohl SAP Fiori schon vor SAP S/4HANA verfügbar war und der Einsatz somit nicht an die neueste ERP-Lösung von SAP gekoppelt ist, führte die moderne Frontend-Technologie bei den meisten Kunden bisher eher ein Schattendasein. Oftmals wurde SAP Fiori nur parallel zur klassischen SAPGui für bestimmte Unternehmensprozesse als Insellösung (bspw. ESS/MSS-Szenarien) eingesetzt, nicht jedoch großflächig für alle Anwender als zentraler Einstiegspunkt zur Bedienung von SAP ausgerollt. Für bestehende SAP ERP Installationen wäre ein solches Vorhaben auch zu kostspielig, da ein technologischer Frontend-Wechsel von der SAPGui hin zum Browser vollzogen werden muss. Dies hätte, unabhängig von der eingeschränkten Verfügbarkeit passender Apps, auf verschiedenen Ebenen entsprechende Aufwände zur Folge, die nur durch UI/UX-Verbesserungen allein nicht zu rechtfertigen sind. Mit dem Umstieg auf die neue Technologieplattform S/4HANA entstehen jedoch neben Diskussionen über Prozessveränderungen konsequenterweise auch Überlegungen zu neuen Benutzeroberflächen und Bedienkonzepten als Alternative zur SAPGui, die ganz zeitgemäß mobile Anwendungsszenarien unterstützen und die neuen Arbeitsabläufe in SAP einheitlicher, moderner und intuitiver präsentieren sollen, womit SAP Fiori zunehmend an Bedeutung gewinnt. Nicht zuletzt tut sich auch jedes Management schwer damit, in eine zukunftsfähige Technologieplattform für ERP-Prozesse zu investieren, wenn diese optisch aus dem letzten Jahrhundert stammt. Folglich rückt bei Kunden in Bezug auf ein bevorstehendes S/4HANA Einführungsprojekt auch SAP Fiori automatisch als Begleiterscheinung in den Fokus, womit das Thema deutlich mehr Auftrieb erhält, und eine passende Frontend-Strategie benötigt wird. Denn in heterogenen und hybriden Systemlandschaften mit Cloud-Lösungen kann langfristig nur eine auf Web-Technologien basierende Frontend-Lösung wie SAP Fiori bestehen, um ein einheitliches sowie konsistentes UI bereitzustellen.

Warum SAP Fiori komplizierter ist

Entsprechend entscheiden sich viele Kunden schlussendlich für einen sogenannten Fiori-first/Fiori-only Ansatz. Hierbei sollen SAP-Anwender aus den Fachbereichen im Zuge der SAP S/4HANA-Implementierung nur noch Zugriff auf das Fiori Launchpad (FLP) erhalten, um den Wechsel zwischen verschiedenen Frontend-Technologien innerhalb von Geschäftsprozessen im Sinne eines Medienbruchs zu vermeiden und ein verbessertes Benutzererlebnis (UX) in einer modernen Benutzeroberfläche (UI) zu schaffen. Der Einsatz von SAP Fiori geht jedoch mit einigen Konsequenzen einher und entspricht grundsätzlich einem Paradigmenwechsel im Hinblick auf die Bereitstellung von SAP-Berechtigungen, die letztlich den Zugriff auf Apps innerhalb des Fiori Launchpads (FLP) steuern. Erfahrungsgemäß sind Kunden diesbezüglich oftmals unvorbereitet und überrascht, da die damit einhergehenden Implementierungsaufwände im Zuge des S/4HANA Einführungsprojekts dramatisch unterschätzt werden. Doch wie kann das sein? Schließlich hat sich SAP mit S/4HANA doch zur Aufgabe gemacht, dass zukünftig alles einfacher, schneller und besser werden soll (Stichwort: Simplification). Genau das trifft allerdings aus Sicht der SAP-Berechtigungsverwaltung für die Bereitstellung von Fiori Apps im Vergleich zu klassischen Anwendungen wie Transaktionen oder WebDynpros etc. leider nicht zu. Denn die Annahme, dass Fiori Apps ähnlich unkompliziert zur Nutzung freigeschalten werden können, entspricht leider nicht der Realität wie nachfolgende Infografik veranschaulicht:

Entwicklungsstruktur in SAP Fiori

Während klassische Anwendungen auch in SAP S/4HANA weiter nutzbar sind und durch Entwickler über Pakete mandantenübergreifend strukturiert und angelegt werden, zeigen sich bei Fiori Apps bereits hier erste Unterschiede. Denn die auf Web-Technologien (JavaScript Framework) basierenden Fiori Apps sowie die zugehörigen Zielzuordnungen bzw. Target Mappings (TM) werden durch Entwickler über technische Kataloge (TC) mandantenübergreifend bereitgestellt und einem Paket zugeordnet, bevor ein Berechtigungsadministrator die Apps und TM über mandantenspezifische Business Kataloge (BC) referenziert. Technische Kataloge (TC) bilden somit den Ursprung für die Verwendung von Apps und sind daher zumindest ansatzweise mit der klassischen Paketstruktur der ABAP Workbench vergleichbar, weshalb diese durch Entwickler verantwortet werden. Dagegen werden Business Kataloge (BC) durch Berechtigungsadministratoren verwaltet, da diese lediglich auf bestehende App-Definitionen und Funktionen verweisen.

Abhängigkeiten und Voraussetzungen

Beim Referenzieren von Apps aus technischen Katalogen (TC) in Business Kataloge (BC) über das Werkzeug Fiori Launchpad Content Manager (Transaktion /UI2/FLPCM_CUST) muss beachtet werden, dass gewisse Abhängigkeiten und Voraussetzungen existieren, die zwingend einzuhalten sind. Denn teils setzt die Nutzung von Apps wiederum andere Apps voraus, die in der Fiori Apps Library entsprechend als solche dokumentiert sind und daher ermittelt werden müssen. Zum anderen müssen im SAP-System technische Komponenten zunächst aktiviert und teils auch transportiert werden, damit eine App technisch auch tatsächlich verwendet werden kann. Dazu gehören einerseits Kommunikationsknoten im Internet Communications Framework (ICF), welche die Kommunikation über Web-Technologien überhaupt erst ermöglichen, und andererseits die OData-Services, welche die Geschäftslogik beinhalten und die Datenverarbeitung sicherstellen.

Vorschlagswertpflege

Wenn klassische Anwendungen über die ABAP Workbench im SAP-System definiert wurden, können für die implementierten Berechtigungsprüfungen entsprechende Berechtigungsvorschlagswerte direkt in der SU24 gepflegt werden. Der Anwendungsname und der zugehörige Anwendungstyp werden über den Verwendungsnachweis im Rollenprofil als Anwendungskontext zu einer Berechtigung transparent ausgewiesen, sofern ein Berechtigungsadministrator eine klassische Anwendung über das Menü einer Berechtigungsrolle eingebunden hat. Zwar haben Fiori Apps eine eindeutige Kennung (Fiori App-ID), jedoch ist diese aus technischer Sicht eher irrelevant, da Fiori Apps über zugehörige OData-Services mit dem SAP-System kommunizieren, welche letztlich den Anwendungskontext repräsentieren. Ein direkter Rückschluss vom OData Service zur Fiori App ist folglich nicht direkt möglich und entsprechend erfolgt die Pflege von Vorschlagswerten für Berechtigungsprüfungen bei Fiori Apps indirekt über die jeweiligen OData-Services und nicht über die Fiori App-ID, welche aus Anwendersicht eigentlich den Einstiegspunkt darstellt.

Bereitstellung und Frontend-Struktur

Die Einbindung von klassischen Anwendungen im Menü einer Berechtigungsrolle erfolgt direkt und diese ist obligatorisch, damit über die SU24 die benötigten Vorschlagswerte in das Rollenprofil gelangen. Der Berechtigungsadministrator kann optional den Aufbau des Rollenmenüs gestalten, wobei SAP-Anwender in der SAPGui häufig nur mit einer Favoritenstruktur oder dem SAP-Standardmenü arbeiten. Da Fiori Apps über Business Kataloge (BC) referenziert werden, müssen die Business Kataloge (BC) konsequenterweise im Rollenmenü eingebunden werden, womit gleichzeitig auch die zu den Apps zugehörigen OData-Services im Rollenmenü durch die PFCG aufgeschlüsselt werden. Da das Fiori Launchpad (FLP) jedoch per se kein Standardmenü bereitstellt, ist der Aufbau einer Frontend-Struktur zur Navigation in Abstimmung mit dem Fachbereich über Bereiche (Spaces) mit Seiten (Pages) und Abschnitten (Sections) fast schon obligatorisch. Ansonsten erscheint das Fiori Launchpad (FLP) beim Aufruf ohne Inhalt, sofern auf der persönlichen Startseite keine Apps als Favoriten angepinnt wurden. In diesem Fall können Fiori Apps nur über das Navigationsmenü oder die Suchfunktion (App Finder) entsprechend der Katalogstruktur gelistet und aufgerufen werden. Folglich sollten über das Rollenmenü auch Bereiche (Spaces) eingebunden werden, um prozessbezogene Arbeitsabläufe im Fiori Launchpad (FLP) abzubilden. Bereiche/Seiten/Abschnitte (Spaces/Pages/Sections) wurden mit S/4HANA 2020 eingeführt und sind nicht nur eine Alternative zu den Fiori-Kachelgruppen, sondern SAP empfiehlt gemäss SAP-Help explizit deren Verwendung anstelle des Home Page Layouts bestehenden aus Gruppen, da dieses veraltet ist.

Übrigens: bei nachträglichen Änderungen an Business Katalogen (BC) müssen auch die betroffenen Rollen aktualisiert werden. Denn es ist nicht ausreichend, eine neue App zu einem Business Katalog (BC) hinzuzufügen und die App über einen Bereich sichtbar zu machen. Es muss zwingend überprüft werden, ob das Rollenmenü durch die neue App-ID mit neuen OData-Services erweitert werden muss, damit der Aufruf einer neuen App berechtigungsseitig schlussendlich auch funktioniert.

Transport

Wohingegen beim Transport von Rollen mit klassischen Anwendungen in der Regel keine besonderen Abhängigkeiten existieren, ist beim Einsatz von SAP Fiori zwingend auch der Transport abhängiger Fiori-Objekte zu berücksichtigen, da diese beim Rollentransport über die PFCG nicht automatisch im Transportauftrag aufgezeichnet werden. Weil Business Kataloge (BC), Bereiche (Spaces) und Seiten (Pages) eigenständige Objekttypen sind, erfolgt der Transport nicht als kompakte Einheit über die Rollendefinition, sondern als verteiltes Stückwerk. Zudem sind innerhalb einer Transportschiene manuelle Nacharbeiten erforderlich, da der Aktivierungsstatus von benötigten ICF-Knoten nicht transportiert werden kann. Entsprechend muss die Aktivierung in den Folgesystemen stets reproduziert werden, um die Funktionsfähigkeit der Fiori Apps letztlich sicherzustellen.

Fehleranalyse

Durch die Gateway-Architektur von SAP Fiori bestehend aus App-IDs, Target Mappings, Katalogen und Bereichen sowie ICF-Knoten und OData-Services erhöht sich die Anzahl möglicher Fehlerquellen. Dadurch steigt die Wahrscheinlichkeit für Inkonsistenzen und Fehlfunktionen bedingt durch fehlerhafte Konfigurationen oder unvollständige Transporte. Die Transparenz bei der Fehleranalyse nimmt dabei spürbar ab, da auch in Traces nicht mehr der ursprüngliche Anwendungskontext bzw. Einstiegspunkt des Anwenders (App-ID) angezeigt wird, sondern stattdessen die zur Fiori App zugehörigen OData-Services, welche technisch jedoch nur als Hash-Wert präsentiert werden. Während bei klassischen Anwendungen Berechtigungsfehler im Testsystem mit der Vergabe von SAP_ALL quasi eliminiert werden können, ist dies bei SAP Fiori nur noch bedingt zielführend, da hierdurch Fehler im Fiori-Layer nicht beeinflusst werden können. Mit SAP Fiori werden Troubleshooting-Maßnahmen somit insgesamt umständlicher und zeitintensiver.

Warum Administratoren für Fiori-Berechtigungen trotzdem nicht den Mut verlieren sollten

Abschließend bleibt festzuhalten, dass der Einsatz von SAP Fiori einen spürbaren Effekt auf die SAP-Berechtigungsverwaltung hat und mit neuen Herausforderungen und einem erweiterten Tätigkeitsspektrum für SAP-Berechtigungs-Administratoren einhergeht. Jedoch benötigt es für den Umgang mit SAP Fiori keine neuen konzeptionellen Ansätze oder separate SAP Fiori-Rollen, sondern vielmehr eine Integration in die bestehenden Berechtigungsstrukturen. Denn letztlich ist SAP Fiori eine Frontend-Technologie und als solche verändert sie vor allem die Art und Weise, wie Anwender mit dem SAP-System interagieren. Zwar verändern sich durch architekturbedingte Gegebenheiten und limitierte Tracing-Möglichkeiten auch Rahmenbedingungen sowie Spielregeln und Beistellpflichten bei der Bereitstellung von Anwendungen, da Fachbereiche mehr denn je die benötigten Funktionen bzw. App-IDs zwingend benennen müssen. Zudem sind diese im SAP Fiori Launchpad (FLP) entsprechend sinnvoll einzubinden, um den einfachen Zugriff auf Apps (Stichwort: SAP Easy Access) sicherzustellen. Jedoch bleiben fundamentale Grundsätze sowie Werkzeuge der SAP-Berechtigungsverwaltung erhalten und diese werden durch weitere Werkzeuge ergänzt. Mit SAP Fiori ist der Weg zur Bereitstellung und Berechtigung von Anwendungen somit nicht mehr geradlinig, aber unsere Xiting Authorizations Management Suite (XAMS) stellt entsprechende Funktionen bereit, um die Arbeit mit SAP Fiori effizienter zu gestalten. Kontaktieren Sie uns und lassen Sie sich von den vielen Möglichkeiten zur Vereinfachung der Fiori-Administration begeistern.

Neue Infografik zur Bereitstellung von Fiori-Applikationen zum Download

Laden Sie sich unsere neue Infografik unseres Autoren Stefan Wohlschlag herunter, um eine anschauliche Gegenüberstellung von SAP Fiori Apps im Vergleich zu den klassischen SAP-Anwendungen zu erhalten.

Füllen Sie dazu einfach folgendes Formular aus und Sie erhalten direkten Zugriff:

Wie Xiting Sie bei SAP Fiori unterstützen kann

Sie möchten mehr zum Thema SAP Fiori Berechtigungen, der Erstellung eines umfassenden SAP Berechtigungskonzepts oder Fiori-Applikationen im Allgemeinen erfahren, dann stehen Ihnen unsere Experten im Berechtigungswesen mit Ihrem Know-how jederzeit zur Verfügung. Xiting ist Ihr Experte im Umfeld von SAP Security!

Kennen Sie die Videoreihe unserer S/4HANA- und Fiori-Expertin Jennifer Schmider? Sie gibt in anschaulichen Tutorials wertvolle Einblicke zu folgenden Fragestellungen:

  • Was ist SAP Fiori? Die Grundlagen
  • Wie werden SAP Fiori Applikationen berechtigt?
  • Was ist der SAP Fiori Launchpad Designer?
  • Best Practices im Fiori Rollenbau
  • Spaces und Pages anlegen im neuen SAP Fiori Concept
  • Die Top Pain Points bei Fiori-Berechtigungen
Stefan Wohlschlag
Kontakt

Nehmen Sie Kontakt mit uns auf!

Haben Sie Fragen zu unseren Produkten?

+41 43 422 8803
[email protected]
+49 7656 8999 002
[email protected]
+1 855 594 84 64
[email protected]
+44 1454 838 785
[email protected]
Kontakt
Webinare

Besuchen Sie unsere Live-Webinare und lernen Sie von unseren Experten mehr zu SAP-Berechtigungen, XAMS, SAP IDM und zu vielen weiteren Themen im Kontext von SAP Security.

Hier anmelden