Mit Einführung der Fiori-Apps lieferte die SAP® eine neue Kategorie von Anwendungen aus, mit denen Geschäftsprozesse durchgeführt und bearbeitet werden können. Die fortschreitende Migration der alten ERP-Systeme auf die aktuelle SAP S/4HANA®-Systemlandschaft, sowie Neueinführung von SAP S/4HANA® bei Unternemen führt zu einer immer häufigeren Verwendung der Fiori-Apps. Viele altbewährten Transaktionen werden sukzessive durch Apps abgelöst. Neue Funktionen werden größtenteils nur noch als Fiori-Anwendung entwickelt. Ebenso werden auf neuen SAP 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 Blogserie 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.
Welche Funktionen mit welchen Transaktionen durchgeführt werden können, ist altbekannt. Damit weiß der Prüfer auch, worauf er bei seiner Tätigkeit den Fokus legen muss. Im Regelfall gibt es aber keine 1:1-Mapping von Transaktion und einer App, welche sie ersetzen soll. Ebenso kann man als Prüfer leider auch nicht damit rechnen, stets ein detailliertes Konzept bezüglich der verwendeten Apps und den Katalogen und Rollen in welchen sie enthalten sind, vorzufinden. Daher werden in diesem Newsletter Ansätze vorgestellt, wie man Apps ermitteln kann, die für eine Prüfung interessant sein könnten.
Dokumentationen und Konzepte des Kunden bzw. Mandanten
Auch für Entwicklungen und Berechtigungen im Kontext von Fiori sollte es ein detailliertes Konzept geben. Einschlägig sind hier die bewährten Dokumente wie Entwicklerrichtlinien, Rollen- und Berechtigungskonzepte und dergleichen.
Aus den Entwicklerrichtlinien sollten zumindest Informationen über Namenskonzepte und Integrationsszenarien der Services in Technische Kataloge und ggf. Businesskataloge entnehmbar sein.
Entwicklerdokumentationen sollten ohnehin für jede Eigenentwicklung vorhanden sein. Dies schließt Anforderer, Prozessbeschreibungen und Freigaben ein. Damit sind auch die technischen App-IDs bzw. technischen Namen der Services, sowie deren Integration in Kataloge und Rollen eingeschlossen. Es ist technisch möglich – und auch gewünscht – eigenentwickelte Fiori-Apps mit Berechtigungsprüfungen und entsprechenden Vorschlagswerten hinsichtlich der Berechtigungen auszustatten. Auch dies sollte entsprechend dokumentiert sein.
Über die Rollen- und Berechtigungskonzepte gelangt man an Informationen, welche Fiori-Apps (inkl. deren technischer ID) für welche Fachbereiche und Stellen relevant sind und damit auch deren Zuordnung zu den Businesskatalogen. Weiterhin sollten hier die gleichen Informationen hinterlegt sein, wie sie auch für die Zuordnung von Transaktionen notwendig sind (Data Owner, Freigaben, etc.).
Sind diese Dokumente sauber gepflegt und geführt, so kann schnell ein individueller Prüfansatz für jeden Anwendungsfall erstellt werden. Leider zeigt die Erfahrung, dass Konzepte und Dokumentationen, wenn überhaupt vorhanden, oft nicht die Detailtiefe liefern, um damit einen Prüfungsansatz erstellen zu können.
Apps finden über die SAP Fiori Apps Reference Library und weitere SAP-Bordmittel
Stehen für eine Prüfung keine zufriedenstellenden Informationen vorab zur Verfügung, steht man als Prüfer vor zwei Herausforderungen. Zum einen benötigt man eine Idee, welche Apps für eine Prüfung relevant wären und zum anderen muss man dafür wissen, über welchen Benutzern sie zugeordnet sind.
Für die Apps aus dem SAP-Standard führt die SAP ein zentrales Verzeichnis – die SAP Fiori Apps Reference Library – nachfolgend „Fiori-App-Library“ genannt. Diese ist öffentlich zugänglich und über die URL https://fioriappslibrary.hana.ondemand.com/ erreichbar. In ihr sind sämtliche aktuellen und auf obsoleten Fiori-Apps mit dem jeweils relevanten Releasenummer des SAP-Systems gelistet. Sie wird permanent mit neuen und obsoleten Apps aktualisiert. Da alle weiteren Recheremöglichkeiten außerhalb eines SAP-Systems (beispielsweise der SAP S/4HANA®-Readyness-Check) auf diese Daten zurückgreifen, wird das Vorgehen nur anhand der Fiori-App-Library vorgestellt. Obwohl das Verzeichnis umfassend ist, bietet es leider einige Fallstricke, über welche man sich bewusst sein muss.
Nehmen wir folgenden Anwendungsfall:
Wir suchen im SAP-Standard eine App, mit der wir Rechnungsbelege anzeigen können. Wir suchen also eine App, mit der wir das gleiche machen können, wie mit der der Transaktion FB03.
Der naheliegendste Ansatz ist es, in der Fiori-App-Library nach dem Transaktionscode zu suchen.
Die Ergebnisliste zeigt bereits, dass es keine direkte Entsprechung gibt. Der Block Other SAP Fiori Apps listet Apps auf, welche thematisch mit der FB03 verwandt sind, aber dieser nicht komplett entsprechen. Dies ist auch erkennbar, wenn man die Namen der Apps betrachtet. Dort steht keine App, welche direkt die Anzeige von Buchungsbelegen beschreibt.
Im Bereich Other Apps steht ein direkt passender Eintrag, welcher sogar in Klammern die gesuchte Transaktion enthält. Das Problem hier ist aber, dass es sich nicht um eine eigene Fiori-App, sondern um eine Legacy-App handelt. Diese ist aber lediglich eine Ausführung der Transaktion in der WebGUI. Für unsere Intention eine reine Fiori-App zu finden, bringt uns das leider auch nicht weiter. Generell sei darauf hingewiesen, dass eine Suche über Transaktionscodes i.d.R. nicht auf entsprechende Apps verweist. Dieser Weg ist also für unseren Ansatz nicht praktikabel. Geht es um reine Recherche- zwecke, kann aber durchaus darauf zurückgegriffen werden.
Eine weitere Möglichkeit wäre, über die „Line of Business“ zu suchen.
In diese Kategorisierung nach Modulen kann man aus dem Hauptmenü in der Fiori-App-Library abspringen.
Die Zahl hinter dem Modul zeigt die Anzahl der Apps innerhalb dessen an. Springt man nun in ein Modul ab, erhält man leider eine sehr unübersichtliche sequenzielle Liste, die weder nach Fachbereich noch Alphabet geordnet ist. Es ist also auch sehr schwierig, sich hier in größeren Modulen zurecht zu finden.
Für uns führt also der Weg über die Freitextsuche. Unglücklicherweise gibt es hier auch einige Probleme. Diese kommen daher, dass bei der Beschreibung der Apps bestimmte Begrifflichkeiten, wie wir sie aus der alten SAP-Welt kennen, nicht mehr verwendet werden. Andererseits muss man auch berücksichtigen, dass man die genauen Termini aus der englischen SAP-Welt verwenden muss. Oft helfen einem hier auch Übersetzungstools nicht weiter, da diese nicht die genauen SAP-Begriffe als Übersetzung liefern. Die besten Ergebnisse in der Liste erreicht man, wenn man sich auch bewusst ist, in welchem Kontext sich die App bewegt und man die entsprechenden Fachbegriffe in der Suche verwendet.
Bleiben wir bei unserem Beispiel mit der Transaktion FB03. Wir haben gesehen, dass uns die Suche nach dem Transaktionscode nicht zum Ziel bringt. Versuchen wir nun die Freitextsuche mit „Show documents“. Auch hier sehen wir in der Ergebnisliste, dass zwar viele Apps aufgelistet werden, allerdings auch keine thematisch passenden Apps enthalten sind. Die Ergebnisse drehen sich eher um Dokumente und nicht um Belege.
Ersetzt man in der Suche nun „documents“ durch „gl documents“ („GL“ steht für „general ledger“, also Hauptbuch) oder „financial documents“, was thematisch schon deutlich passender ist, so ändert sich die Trefferliste deutlich. Allerdings sind auch noch keine passenden Einträge dabei.
Wir sind jetzt schon sehr konkret mit der Suchabfrage, aber warum kommen trotzdem noch keine passenden Einträge? Dies liegt daran, dass es im Fiori-Kontext für die Anzeige nicht mehr von „Show“ sondern von „Display“ spricht. Ersetzt man nun „Show“ durch „Display“, so ändert sich die Trefferliste erneut deutlich hin zu thematisch passenderen Ergebnissen.
Aber eine App, die zur Anzeige von Hauptbuchbelegen dient – und als solche auch aufgeführt ist – sehen wir noch immer nicht. Was läuft jetzt noch schief? Vielleicht muss man nochmal überdenken, was man denn anzeigen möchte. Was wäre denn ein Synonym für „gl document“ in der Geschäftssprache? Versuchen wir „journal entries“. Wir suchen also nach „Einträgen im Hauptbuch“.
Wir sehen in dieser Trefferliste, dass sich die Suchergebnisse wieder geändert haben und wieder ein Stück konkreter geworden sind. Damit können wir festhalten, dass wir mit „Display journal entries“ schon sehr nahe am Ziel sind, aber leider noch immer nichts wirklich Passendes gefunden haben.
Diese Suche hat uns aber einen weiteren, sehr interessanten Eintrag gebracht: „Manage Journal Entries – New Version“. Dies ist für uns nun sehr wichtig. Zum einen muss man wissen, dass im Fiori-Kontext so gut wie jedes Objekt „verwaltet“ werden kann; d.h. dass es eigentlich für jedes Objekt eine „Manage-App“ gibt.
Dies sind i.d.R. sehr mächtige Apps, mit denen sehr viele Funktionen möglich sind. Ob diese Funktionen zur Verfügung stehen bzw. ausgeführt werden können, hängt von den jeweiligen Berechtigungen des Anwenders ab. Eine Kernfunktion hierbei ist die Anzeige des jeweiligen Objekts.
Für uns bedeutet dies nun, dass wir – mangels einer „Display-App“ nach einer „Manage- App“ suchen müssen. Und da die Suche nach „journal entries“ schon sehr gute Ergebnisse gebracht hat, kombinieren wir diese beiden Suchbegriffe. Angemerkt sei, dass wir in der Suche in Abbildung 5 schon einen entsprechenden Eintrag als neue Version bekommen haben. Uns interessiert aber jetzt auch, ob es eine alte Version davon gibt.
Diese Trefferliste zeigt uns nun zwei Apps, die thematisch zu unserer Suche passen würden – eine alte und eine neue Version. Zum Thema neue und veraltete Apps später etwas mehr.
Wichtige Informationen aus der Fiori-App-Library
Schon am Anfang der Seite zur App erhalten wir in zwei Dropdowns erste wichtige Informationen bzw. müssen wir eine Auswahl treffen.
Im linken Dropdown wählen wir die Plattform und im rechten Dropdown die jeweilige Version. Diese kann man im zu prüfenden System aus der Version der Komponente S4CORE ableiten oder bei der Basisadministration nachfragen. Da sich teilweise für uns wichtige Informationen ändern können, ist es wichtig, die korrekte Version auszuwählen. Alle Informationen, die für uns relevant sind, finden wir im Reiter IMPLEMENTATION INFORMATION unter dem Abschnitt Configuration.
Dort finden wir u.a. die notwendigen OData-Services (welche mindestens über die Vorschlagswerte in die Rolle gezogen werden), die mögliche Zielzuordnungen mit Semantischen Objekten und Aktionen, Technische und Business-Kataloge und schließlich die Business Roles, in denen die App enthalten ist. Die für uns die wichtigsten Informationen sind, die App-ID und in welchen Katalogen und Rollen die App enthalten ist, und welche Zielzuordnungen sie hat.
Weitere Herausforderungen für die Prüfung
In unserem Anwendungsfall wollten wir „nur“ eine Fiori-App mit der man Rechnungsbelege anzeigen kann ermitteln, um dies beim Audit prüfen zu können. Das Resultat unserer Suche war nun, dass es einerseits keine App gibt, die nur diese Funktion bietet, wir dafür auf der anderen Seite eine immens mächtige App gefunden haben, welche die gewünschte Funktion neben vielen anderen bietet.
Für uns zeigen sich nun zwei Probleme, welchen Ansatz wir hinsichtlich der Prüfung weiterverfolgen sollen. Prüfen wir die Zuordnung dieser App reduziert auf die Anzeigeaktivität ‚03‘ oder prüfen wir, wer diese App ausführen kann und sämtliche Berechtigungen daraus hat?
Beide Ansätze sind sinnvoll und haben ihren Platz im Prüferportfolio. Letzten Endes kommt es auf den Fokus der Prüfung an und wie welche Apps vom Mandanten verwendet werden.
Neue und veraltete Apps
Wenn man in der Fiori-App-Library nach Apps sucht, können auch neue oder veraltete Apps in der Trefferliste angezeigt werden.
Veraltete Apps erkennt man, wie hier dargestellt, an dem Zusatz „deprecated“ erkennen.
Ist eine App als „deprecated“ gekennzeichnet, dann ist sie entweder bereits nicht mehr in den neureren Releases enthalten und durch eine neue Version ersetzt oder in neueren Releases noch im System vorhanden, aber als „veraltet“ gekennzeichnet.
Hier muss geprüft werden, ob die neueren Versionen bereits in den zu prüfenden Systemen laufen. Ist dies der Fall sollten in jedem Fall beide Apps hinsichtlich der Berechtigungen geprüft werden. Sollte die neue Version noch nicht im Release des Prüfsystems enthalten sein, kann diese ignoriert werden.
Neue Versionen von Apps sind auf den ersten Blick auf dreierlei Arten gekennzeichnet. Entweder haben sie das Suffix „New Version“, es steht ein Stern hinter dem Appnamen oder sie stehen unter der Rubrik „What’s New“ in der Trefferliste (vgl. Abbildung 6).
Da eine neue Version auch immer auf einer alten Version aufbaut, erkennt man auch einen Unterschied in der Fiori-App-ID. Die ursprüngliche, erste Version hat als App-ID i.d.R. immer ein „F“ gefolgt von einer vierstelligen Nummer. Neuere Versionen haben die identische App-ID der ursprünglichen App mit einem Buchstaben der Generation der Version dahinter. Ein Beispiel zeigt Tabelle 1.
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.
Aufgrund der hohen Komplexität des technischen Hintergrunds von Fiori-Apps und der Tatsache, dass es leider nicht möglich ist, ein direktes Mapping von Transaktion zu Fiori-App zu ziehen, ist man bei der Prüfung von Fiori-Apps mehr auf Dokumentationen und Konzept des Mandanten angewiesen als zuvor. Es ist sehr schwierig und zeitaufwändig, einzelne Apps passgenau aus der Fiori-App-Library zu ermitteln.
Das Licht am dunklen Horizont ist aber, dass man mit etwas detektivischem Fingerspitzengefühl in akzeptabler Zeit durchaus auf zentrale Apps der jeweiligen Fachbereiche stoßen kann (Stichwort „manage“) und man sich damit dann über die Abhängigkeiten im SAP-Standard weitere Ansatzpunkte erschließen kann.
