Mit der Einführung der Fiori-Apps lieferte die SAP® eine neue Kategorie Anwendungen aus, mit denen Geschäftsprozesse durchgeführt und bearbeitet werden können. Die fortschreitende Migration der alten ERP-Systeme auf die aktuelle S/4HANA-Systemlandschaft, sowie Neueinführung von S/4HANA bei den Kunden führt zu einer immer häufigeren Verwendung der Fiori-Apps. Viele bewährte Transaktionen werden sukzessive durch Apps abgelöst. Neue Funktionen werden größtenteils nur noch als Fiori-Anwendung entwickelt. Ebenso werden auf neuen S/4HANA-Systemen von Kunden und Beratungshäusern kundeneigene Programme nur noch für Fiori und nicht mehr auf Transaktionen implementiert. Daher rücken die Fiori-Apps auch immer mehr in den Fokus der SAP®-Systemprüfungen.
Diese neue Technologie hat hinsichtlich der Berechtigungen und Implementierung in Rollen einiges mit der alten Welt der Transaktionen gemein, unterscheidet sich aber auch in einigen Gesichtspunkten gravierend. Aus diesem Grund soll mit dieser Newsletterreihe ein Einblick in den technischen Hintergrund der Fiori-Berechtigungen gegeben werden, sowie auf die Besonderheiten bei einer Prüfung hingewiesen und mögliche Ansätze erläutert werden.
In diesem Artikel erläutern wir, wie Berechtigungen auf Fiori-Anwendungen funktionieren, wo die Unterschiede und Gemeinsamkeiten zu den Transaktionen liegen und wie der SAP-Standard die Eigenheiten der Fiori-Welt umsetzt.
Der Unterschied zwischen Berechtigungen für Transaktionen und Fiori-Apps
Wenn man eine Transaktion in eine Rolle aufnehmen möchte, so fügt man diese in das Rollenmenü hinzu. Im Startobjekt S_TCODE erscheint der entsprechende Eintrag und die Vorschlagswerte werden in die Berechtigungen übernommen. Über einen ‚*‘-Eintrag im Objekt S_TCODE hat man Zugriff auf alle Transaktionen im SAP-System und kann diese zumindest starten.
Fiori-Apps können im Gegensatz dazu nicht direkt Rollen zugeordnet werden. Die Startkachel der App muss vorher zunächst in einen Fiori-Launchpad-Katalog aufgenommen werden. Zusätzlich benötigt die Kachel bzw. die App wenigstens eine oder ggf. auch mehrere Zielzuordnungen auf sog. Semantische Objekte sowie auf je eine semantische Aktion dieses Objekts. Dadurch erfolgt im Hintergrund ein Mapping auf die relevanten Programme.
Ist der Katalog fertig erstellt, so muss dieser in das Rollenmenü der Berechtigungsrolle aufgenommen werden. Dadurch erfolgt eine Zuordnung der enthaltenen Anwendungen in die Rolle. Ebenso wird das Startobjekt (i.d.R. S_SERVICE) mit den entsprechenden Einträgen versorgt und die zugeordneten Vorschlagswerte in die Berechtigungen aufgenommen.
Wird das Startobjekt mit einem ‚*‘-Eintrag ausgeprägt oder sogar der User mit dem Sammelprofil SAP_ALL berechtigt, so hat dies nicht automatisch zur Folge, dass alle Fiori-Apps ausgeführt werden können. Damit wäre zwar von der Berechtigungsseite her die Möglichkeit gegeben, alle Apps starten bzw. ausführen zu können, der Benutzer hat aber faktisch keine Möglichkeit, die App tatsächlich zu starten, da ihm die Kachel zum Starten durch die erwähnte ‚*‘-Berechtigung noch nicht angezeigt wird. Hierfür ist zwingend ein Katalog mit den entsprechenden Kacheln der gewünschten Apps in den Rollen notwendig. Ansonsten sieht der Benutzer in seinem Fiori-Launchpad (FLP) keine einzige Kachel und kann somit auch keine App starten.
Auch das Sammelprofil SAP_ALL ist dadurch anders zu bewerten. Es liefert zwar weiterhin die umfassenden Start- und Anwendungsberechtigungen und ist daher genauso kritisch zu betrachten wie außerhalb des Fiori-Kontextes. Da es aber auf die eben angesprochenen für den Start zwingend notwendigen Kataloge keine vergleichbare ‚*‘-Berechtigung gibt, müssen diese immer separat im Rollenmenü zugeordnet werden, damit der Anwender die Kacheln zu Start der Apps sieht. Damit führt SAP_ALL nicht automatisch dazu, dass der Anwender sämtliche Apps starten kann, auch wenn er dazu berechtigt wäre.
Die Startobjekte für Apps – Neue App vs. Legacy-App
Für den Start von Anwendungen bietet SAP drei verschiedene Startobjekte an. Welches Objekt verwendet wird, hängt vom Typ der Anwendung ab.
Startobjekt | Anwendung |
S_TCODE | Start einer Transaktion |
S_START | Start einer Webdynpro-Anwendung |
S_SERVICE | Start einer Anwendung basierend auf OData-Services |
Tabelle 1: Startobjekte
Die meisten Fiori-Apps basieren auf OData-Services. Webdynpro-Apps sind ebenfalls weit verbreitet, jedoch in deutlich geringerer Anzahl vorhanden. Die Gemeinsamkeit dieser drei Anwendungstypen ist, dass sie für die „neuen“ Apps verwendet werden.
Verwendet eine Fiori-App als Startobjekt aber S_TCODE, spricht man von einer sog. „Legacy-App“. Dies bedeutet, dass in der WebGUI exakt das gleiche Programm aufgerufen wird, wie es in der Offline-GUI über den SAP-Logon der Fall ist. Der Zugriff erfolgt über die gleichen Einstellungen in der SE93 zur Transaktion und auch das identische Programm wird ausgeführt. Damit werden auch die identischen Berechtigungsprüfungen durchlaufen werden, wie in der alten SAP-Welt.
Frontend- und Backend-Services
Als das Konzept der Fiori-Apps eingeführt wurde, sollten diese auf zwei unterschiedlichen Servern installiert werden.
Auf dem Frontend-Server sollte alles erstellt werden und laufen, was mit der Bedienoberfläche zu tun hat. Die wichtigsten Punkte waren hier die Fiori-Kataloge, in welchen die Kacheln zum Start der Apps enthalten sind, alle visuellen Elemente wie FLP-Gruppen und natürlich die Berechtigungsrollen zum Zugriff auf diese Kataloge. Die OData-Services, welche für die Steuerung der Frontendkomponenten zuständig sind, sind vom Typ
IWSG – SAP Gateway: Service Groups Metadata.
Auf dem Backend-Server sollte die komplette Businesslogik und die Datenhaltung für Stamm- und Bewegungsdaten implementiert sein. Die Anbindung der jeweiligen Backend- Komponenten erfolgt über OData-Services vom Typ
IWSV – SAP Gateway Business Suite Enablement – Service.
Frontend- und Backendserver kommunizieren über Trusted-RFC-Verbindungen.
Leider hatte diese getrennte Architektur nach geraumer Zeit einige Schwächen und Probleme offenbart, sodass die SAP dazu übergegangen ist, die Installation und Einrichtung von Frontend- und Backendkomponenten auf einem einzigen Server zu empfehlen. Dies ist auch noch immer der herrschende Status quo.
Geblieben ist aber die Verwendung der beiden OData-Service-Typen IWSG und IWSV. Diese müssen von der Administration zusammen mit den gewünschten Apps zunächst aktiviert werden. Dabei bleiben die Backendservices im Standardnamensraum, die Frontendservices werden bei Aktivierung mit einem führenden „Z“ angelegt. Beide Services sind an die App gekoppelt und notwendig, damit diese funktioniert. Dadurch werden auch beim Hinzufügen von Katalogen in die Berechtigungsrollen zuallererst diese Services in die Rolle aufgenommen.
Zielzuordnungen, Semantische Objekte und Aktionen
Jede App benötigt wenigstens eine Zielzuordnung. Damit weiß die App, auf welche Services bzw. Programme beim Start der App bzw. einer bestimmten Aktion in der App zugegriffen werden soll. Dadurch wird auch die Zuordnung der implementierten Services zur jeweiligen App gesteuert.
Zielzuordnungen zeigen auf sog. „Semantische Objekte“ und deren „Semantische Aktionen“.
Semantische Objekte“ stellen wirklich die Objekte in der Geschäftslogik dar, auf denen in den Apps gearbeitet wird. Beispiele hierfür wären AccountingDocument, BillOfMaterial, MaterialBOM oder SalesInquiry.
„Semantische Aktionen“ sind die Aktivitäten, welche auf den semantischen Objekten ausgeführt werden können. Hierbei muss darauf hingewiesen werden, dass ein semantisches Objekt mehrere semantische Aktionen haben kann.
Semantisches Objekt | Sematische Aktion |
AccountingDocument | manage |
BillOfMaterial | displayFactSheet |
MaterialBOM | changeBOM |
SalesInquiry | manage displayFactSheet |
Tabelle 2: Semantische Objekte und Aktionen
In der Tabelle 2 sieht man, dass zum semantischen Objekt AccountingDocument die semantischen Aktionen manage und manageV2 aufgeführt sind. Der Grund hierfür ist, dass es mittlerweile manche Apps bereits in einer neuen Version gibt. Dies ist sowohl in der Beschreibung wie auch an der App-ID erkennbar. Auch die semantischen Aktionen haben dann, wie hier dargestellt, eine Versionsnummer.
Man sollte beachten, dass es nicht zwingend eine 1:1-Zuordnung zwischen App und Zielzuordnung gibt. Natürlich gibt es auch viele Apps, die „nur“ eine Zielzuordnung haben. Allerdings ist es meist so, dass es eine 1:n-Beziehung gibt. Dies ist immer dann der Fall, wenn eine App entweder mit mehreren Semantischen Objekten arbeiten kann oder aber aus der Einstiegs-App in eine andere abgesprungen wird.
Ein Beispiel hierfür wäre, dass aus der Pflege der Kundenaufträge in die Anzeige der Geschäftspartner abgesprungen werden kann. Der Effekt dieser Kopplung von mehreren Semantischen Objekten und deren Aktionen an eine App ist, dass man nur die eine Kachel der Einstiegs-App (z.B. “Kundenaufträge anlegen”) in seinem Fiori-Launchpad (FLP) sieht, aber nicht die Kachel für die Geschäftspartnerpflege. Denn diese soll der Benutzer ggf. nicht direkt aufrufen können.
SAP-Standard-Kataloge
Auch in der neuen Welt liefert die SAP eine umfangreiche Auswahl von Objekten, speziell an Fiori-Katalogen und Rollen, im SAP-Standard aus. Diese werden mit jedem Patch und Release laufend überarbeitet.
Hinsichtlich der Kataloge differenziert die SAP® zwischen technischen Katalogen und Businesskatalogen.
In den technischen Katalogen der Fiori-Entwicklung sind die eigentlichen Apps selbst hinterlegt. Ebenso sind alle für die App notwendigen Zielzuordnungen dort gepflegt. Sie stellen die direkte Abbildung der Programmlogik dar – also die „Original-Apps“. Dadurch dienen sie als Basis für die weitere Verwendung der Apps in den unterschiedlichen Business-Katalogen.
Da die technischen Kataloge die eigentliche Abbildung der Apps beinhalten, dienen sie als Referenzpunkt für die Apps, die in den Business-Katalogen enthalten sind. Als eigentlicher Einstiegspunkt der Apps in die Fiori-Welt, werden technische Kataloge nie in Berechtigungsrollen integriert und dadurch auch nie direkt an Benutzer zugeordnet. Sie stellen eine semantische Zusammenstellung von Fiori-Apps zu einem Geschäftsprozessfeld dar. Gemäß der SAP-Namenskonvention erkennt man technische SAP-Standardkataloge am Präfix „SAP_TC“.
Technische ID | Beschreibung |
SAP_TC_CEC_SD_COMMON | CEC: Customer Engagement und |
SAP_TC_PLM_COMMON | PLM: technischer Katalog |
SAP_TC_FIN_ACC_COMMON | SAP Financials – Rechnungswesen: SAP-Fiori-Apps |
Tabelle 3: Beispiele Technische Kataloge
Trotz der Funktion der technischen Kataloge als Einstiegspunkt der Apps, kann es durchaus vorkommen, dass eine App nicht nur in einem technischen Katalog enthalten ist. Dies ist immer dann der Fall, wenn die App laut Design der SAP auch in eine oder mehrere weitere semantische Gruppierungen von Geschäftsfeldprozessen passt. Sehr häufig ist dies beispielsweise bei allgemeinen Apps aus der Finanzbuchhaltung der Fall. Exemplarisch sei die App Manage Journal Entries (F0717) genannt. Sie ist in vier technischen Katalogen enthalten, welche alle dem Modul FI zugeordnet sind.
Die Businesskataloge unterscheiden sich funktional in drei wesentlichen Punkten von den technischen Katalogen.
1. Zum einen sind in ihnen keine „Original-Apps“ enthalten. Die dort dargestellten Apps bzw. Kacheln im FLP sind lediglich Referenzen auf die Originale in den technischen Katalogen. Ebenso verhält es sich mit den Zielzuordnungen in ihnen. Diese zeigen auf die gleichen semantischen Objekte und Aktionen, wie die im technischen Katalog. Aber auch die Zielzuordnungen wurden als Referenz in den Business-Katalog übernommen. Damit könnte die App oder Zielzuordnung aus einem Business-Katalog gelöscht werden, bliebe aber weiterhin im System erhalten, da das Original in einem oder mehreren technischen Katalogen abgelegt ist.
2. Die in Business-Katalogen enthaltenen Apps sind nicht mehr semantisch nach Geschäftsfeldprozessen zusammengefasst, sondern nach Stellen der Mitarbeiter bzw. speziellen Aufgaben. So gibt es z.B. Business-Kataloge für das länderabhängige Hauptbuchreporting, die Bankbuchhaltung, die Produktkonstruktion in der Fertigung oder die Kundenauftragsbearbeitung. Sie sind damit also deutlich spezialisierter als die technischen Kataloge und können auch Apps aus unterschiedlichen technischen Katalogen enthalten.
3. Aufgrund der beiden vorgenannten Punkte sind sie explizit dafür gedacht, an Benutzer zugeordnet zu werden.
Ein letzter zu erwähnender Unterschied besteht in der Namenskonvention für Businesskataloge. Diese beginnen mit dem Präfix „SAP_<Modul>_BC“, wobei im Platzhalter „<Modul>“ das jeweilige SAP-Modul steht, für welches der Business-Katalog vorgesehen ist.
Technische ID | Beschreibung |
SAP_SD_BC_SO_PROC_OP | Verkauf – Kundenauftragsbearbeitung |
SAP_FIN_BC_GL_REPORTING_TR | Hauptbuch – Reporting für Türkei |
SAP_SCM_BC_PROD_ENG | Fertigung – Produktkonstruktion |
Tabelle 4: Beispiele Businesskataloge
SAP-Standardrollen
Wie zu Beginn beschrieben, erfolgt die Integration von Apps in Berechtigungsrollen nicht direkt, sondern über die Kataloge – genauer über die Business-Kataloge. In diesem Abschnitt spreche ich der Einfachheit halber nur noch von „Katalogen“. Die SAP nennt in diesen Kontext die Berechtigungsrollen „Business Roles“.
Nimmt man Kataloge in Rollen auf, so werden die Anwendungen und damit die notwendigen Services, Webdynpro-Applikationen und Transaktionen der Apps in das Rollenmenü integriert. Ebenso werden die notwendigen Berechtigungsobjekte über die Vorschlagswerte in die Rolle eingefügt. In diesem Bereich unterscheiden sich Fiori-Apps nicht von der Arbeit mit Transaktionen.
Laut Empfehlung der SAP sollten die Business Roles direkt auf die jeweiligen Funktionen der Mitarbeiter zugeschnitten sein. Damit enthalten sie i.d.R. mehr als einen Katalog. In hybriden Szenarien, in denen neben Fiori-Apps auch Transaktionen über die SAP-GUI im Unternehmen im Einsatz sind, enthält das Rollenmenü zusätzlich zu den Katalogen auch Transaktionscodes.
Die Business Roles der SAP enthalten im Standard keine direkten Transaktionscodes. Falls Transaktionen verwendet werden, so sind diese als Legacy-Apps in den Katalogen enthalten.
Da der SAP-Standard die abgebildeten Funktionen sehr breit ansieht, sind in den überwiegenden Business Roles eine große Anzahl von Katalogen enthalten. Dies führt dazu, dass sehr viele Anwendungen – und damit Berechtigungen – in den SAP-Standard-Business- Rollen enthalten sind.
In der Namenskonvention des SAP-Standards ist bei Business Roles kein Modul hinterlegt, sondern lediglich die Beschreibung der Stelle. Allen Rollen ist hier das Präfix „SAP_BR“ gemein. In nachfolgender Tabelle sind Beispiele für Business Roles aufgeführt.
Technische ID | Beschreibung |
SAP_BR_GL_ACCOUNTANT | Hauptbuchhalter |
SAP_BR_DESIGN_ENGINEER | Konstrukteur |
SAP_BR_INTERNAL_SALES_REP | Vertriebsmitarbeiter im Innendienst |
Tabelle 5: Beispiele Business Roles
Fazit
In aktuellen SAP-Systemen trifft man immer häufiger auf die Verwendung von Fiori-Apps. Mit fortschreitender Zeit wird sich deren Anteil gegenüber den Transaktionen noch deutlich erhöhen. Damit rücken sie immer mehr in den Fokus von Prüfungen der SAP-Systeme.
Da es sich bei Fiori-Apps um eine neue Technologie handelt, unterscheiden sich die technischen Voraussetzungen z.T. deutlich von denen der Transaktionen. Um einen zielführenden Prüfansatz entwickeln zu können, muss der Prüfer die Unterschiede zwischen Transaktionen und Fiori-Apps kennen und sich dessen bewusst sein, wie der SAP-Standard mit dieser Thematik umgeht.