About the complexity of authorization management in SAP Fiori

Open discussions and the exchange of experiences with many SAP customers clearly show that when implementing S/4HANA with SAP Fiori, special importance and significance must also be assigned to the user interface (UI) and the associated user experience (UX) in particular. Customers who have chosen SAP Fiori as their leading front-end technology can confirm from their own experience that deploying apps in the Fiori Launchpad (FLP) is more time-consuming and complex than authorizing transactions in SAPGui. For customers who are about to do so, we would like to provide appropriate explanations in this article why this is the case.

Why there is no way around SAP Fiori

Although SAP Fiori was available before SAP S/4HANA and its use is therefore not linked to SAP’s latest ERP solution, the modern front-end technology has tended to lead a shadowy existence for most customers. Often, SAP Fiori was only used in parallel to the classic SAPGui for certain business processes as an isolated solution (e.g., ESS/MSS scenarios), but not rolled out on a large scale for all users as a central entry point for using SAP. Such a project would also be too expensive for existing SAP ERP installations, since a technological front-end change from SAPGui to the browser would have to be made. Regardless of the limited availability of suitable apps, this would result in corresponding efforts on various levels that cannot be justified by UI/UX improvements alone. However, with the switch to the new technology platform S/4HANA, in addition to discussions about process changes, considerations are consequently also arising about new user interfaces and usability concepts as an alternative to SAPGui, which are state of the art in supporting mobile application scenarios and are intended to present the new workflows in SAP in a more uniform, modern, and intuitive manner, with SAP Fiori becoming increasingly important. Last but not least, any management will find it difficult to invest in a future-proof technology platform for ERP processes if it is visually from the last century. Consequently, SAP Fiori automatically comes into focus as a side effect for customers with regard to an upcoming S/4HANA implementation project, giving the topic significantly more traction and requiring a suitable front-end strategy. Because in heterogeneous and hybrid system landscapes with cloud solutions, only a front-end solution based on web technologies such as SAP Fiori can exist in the long term to provide a uniform as well as consistent UI.

Why SAP Fiori is more complicated

Accordingly, many customers finally choose a so-called Fiori-first/Fiori-only approach. Here, SAP users from the business departments should only have access to the Fiori Launchpad (FLP) in the course of the S/4HANA implementation in order to avoid switching between different front-end technologies within business processes in the sense of a media break and to create an improved user experience (UX) in a modern user interface (UI). However, the use of SAP Fiori comes with some consequences and basically corresponds to a paradigm shift with regard to the provision of SAP authorizations, which finally control the access to apps within the Fiori Launchpad (FLP). Experience shows that customers are often unprepared and surprised in this regard, as the associated implementation efforts are dramatically underestimated in the context of the S/4HANA implementation project. But how can this be? After all, with S/4HANA, SAP has set itself the task of making everything simpler, faster and better in the future (keyword: simplification). However, from the point of view of SAP authorization management, this is unfortunately not the case for the provision of Fiori apps compared to classic applications such as transactions or WebDynpros etc. Unfortunately, the assumption that Fiori apps can be released for use in a similarly uncomplicated manner does not correspond to reality, as the following infographic illustrates:

Development structure

While classic applications can still be used in S/4HANA and are structured and created client-independent by developers via packages, the first differences already become apparent here in the case of Fiori apps. This is because the Fiori apps, which are based on web technologies (JavaScript framework), and the associated target mappings (TM) are provided client-independent by developers via technical catalogs (TC) and assigned to a package before an authorization administrator references the apps and TM via client-specific business catalogs (BC). Thus, technical catalogs (TC) form the origin for the use of apps and are therefore at least to some extent comparable with the classic package structure of the ABAP Workbench, which is why developers are responsible for them. Business catalogs (BC), on the other hand, are managed by authorization administrators since they refer to existing app definitions and functions only.

Dependencies and prerequisites

When referencing apps from technical catalogs (TC) to business catalogs (BC) via the Fiori Launchpad Content Manager tool (transaction /UI2/FLPCM_CUST), it is important to note that certain dependencies and prerequisites exist that must be fulfilled. This is because, in part, the use of apps requires other apps in turn, which are documented as such in the Fiori Apps Library accordingly and must therefore be determined. On the other hand, technical components must first be activated and in some cases also transported in the SAP system so that an app can actually be used technically. These include, on the one hand, communication nodes in the Internet Communications Framework (ICF), which enable communication via web technologies in the first place, and, on the other hand, OData services, which contain the business logic and ensure data processing.

Default value maintenance

If classic applications have been defined in the SAP system via the ABAP Workbench, corresponding authorization default values can be maintained directly in SU24 for the implemented authorization checks. The application name and the associated application type are displayed transparently via the where-used list in the role profile as application context for an authorization instance if an authorization administrator has included a classic application via the menu of an authorization role. Although Fiori apps have a unique identifier (Fiori App-ID), this is rather irrelevant from a technical point of view, since Fiori apps communicate with the SAP system via associated OData services, which finally represent the application context. Consequently, it is not possible to draw a direct conclusion from the OData service to the Fiori app and, accordingly, the maintenance of default values for authorization checks for Fiori apps is carried out indirectly via the respective OData services and not via the Fiori app ID, which actually represents the entry point from the user’s perspective.

Deployment and front-end structure

The integration of classic applications in the menu of an authorization role is done directly and this is mandatory so that the required default values get into the role profile via SU24. The authorization administrator can optionally design the structure of the role menu, although SAP users often only work with a favorites structure or the SAP standard menu in the SAPGui. Since Fiori apps are referenced via business catalogs (BC), the business catalogs (BC) must consequently be included in the role menu, which means that the OData services associated with the apps are also added to the role menu by the PFCG. However, since the Fiori Launchpad (FLP) does not provide a standard menu per se, the creation of a frontend structure for navigation in coordination with the department via Spaces with Pages and Sections is almost mandatory. Otherwise, the Fiori Launchpad (FLP) appears without content when called up if no apps have been pinned as favorites on the personal start page. In this case, Fiori apps can only be listed and accessed via the navigation menu or the search function (App Finder) according to the catalog structure. Consequently, Spaces should also be included via the role menu to visualize process-related workflows in the Fiori Launchpad (FLP). Spaces/Pages/Sections were introduced with S/4HANA 2020 and are not only an alternative to Fiori Tile Groups, but according to SAP Help, SAP explicitly recommends their use instead of the Home Page Layout consisting of Groups, because the Home Page feature is deprecated.

By the way: in case of subsequent changes to Business Catalogs (BC), the affected roles must also be updated. This is because it is not sufficient to add a new app to a Business Catalog (BC) and make the app visible via a Space. It is necessary to check whether the role menu has to be extended with new OData services due to the new app ID, so that the call of a new app finally also works on the authorization side.

Transport

Whereas there are usually no special dependencies when transporting roles with classic applications, the transport of dependent Fiori objects must also be taken into account when using SAP Fiori, since they are not automatically recorded in the transport request when roles are transported via the PFCG. Because business catalogs (BC), Spaces and Pages are independent object types, the transport does not take place as a compact unit via the role definition but as distributed fragments. In addition, manual postprocessing is required within a transport route, since the activation status of required ICF nodes cannot be transported. Accordingly, the activation must always be reproduced in the subsequent systems to ensure the functionality of the Fiori apps in the end.

Error analysis

The gateway architecture of SAP Fiori consisting of app IDs, target mappings, catalogs and Spaces as well as ICF nodes and OData services increases the number of possible error sources. This increases the probability of inconsistencies and malfunctions caused by incorrect configurations or incomplete transports. The transparency of error analysis decreases significantly, since the original application context or entry point of the user (app ID) is no longer displayed in traces, but instead the OData services associated with the Fiori app, which are technically only presented as hash values. While authorization errors in test systems can be practically eliminated in classic applications by assigning SAP_ALL, this is only of limited use in SAP Fiori, as it cannot influence errors in the Fiori layer. With SAP Fiori, troubleshooting measures thus become more complicated and time-consuming overall.

Why authorization administrators should nevertheless not lose heart

In conclusion, it can be stated that the use of SAP Fiori has a significant effect on SAP authorization management and is associated with new challenges and an expanded range of activities for SAP authorization administrators. However, dealing with SAP Fiori does not require new conceptual approaches or separate Fiori roles, but rather integration into existing authorization structures. After all, SAP Fiori is a front-end technology, and as such it primarily changes the way users interact with the SAP system. It is true that architecture-related conditions and limited tracing options also change the general conditions as well as the rules and obligations for the supply of applications, as it is more than ever mandatory for departments to name the required functions or app IDs. In addition, these must be integrated into the Fiori Launchpad (FLP) in a meaningful way to ensure easy access to apps (keyword: SAP Easy Access). However, fundamental principles as well as tools of SAP authorization management remain the same and are supplemented by more tools. With SAP Fiori, the path to application provisioning and authorization is thus no longer straightforward, but our Xiting Authorizations Management Suite (XAMS) provides appropriate functions to make working with SAP Fiori more efficient. Contact us and let us inspire you with the many possibilities to simplify Fiori administration.

Download Xiting’s new infographic on Fiori app deployment

Download our new infographic by author and SAP Security Consultant Stefan Wohlschlag for a clear comparison of SAP Fiori apps versus classic SAP applications.

Just fill out the following form and you will get direct access:

How Xiting can support you with SAP Fiori

If you would like to learn more about SAP Fiori authorizations, the creation of a comprehensive SAP authorization concept or Fiori applications in general, our authorization experts are available to you at any time with their know-how. Xiting is your expert in the field of SAP Security!

Do you know our videos related to S/4HANA and Fiori? Just browse through our extensive YouTube library and watch our playlist “Deep-Dive into SAP Fiori”.