Top Pain Points in SAP Fiori Authorizations and Their Solutions – An Experience Report

SAP Fiori is a product, or more precisely, a user interface (UI) that has generated considerable awe, speculation, and discussions in the SAP world. Particularly with SAP S/4HANA, this UI has had a profound impact on everyday business operations. SAP Fiori aims to elevate user-friendliness when working with SAP S/4HANA to a new level, not only enhancing agility and flexibility but also comprehensively improving big data management and real-time analytics. Therefore, in today’s business world with SAP S/4HANA, the implementation of SAP Fiori Launchpad and SAP Fiori applications, known as Fiori Apps, is crucial to increase user productivity and enhance the user experience. While some may believe that this user interface only emerged with SAP S/4HANA, it has actually been in existence since 2013, with the 1.0 version. Nevertheless, it’s important to note that SAP Fiori is a frontend technology for new or established business processes, albeit a completely novel one since SAP Fiori 3.0.

Anyone facing the challenge of SAP S/4HANA migration has likely encountered the SAP Fiori Launchpad with its various tiles, integrated mobility concept, modern layout, and integral functions. This is intended to create a new “user experience” in the day-to-day work of end-users with SAP, as shown in Figure 1. Unfortunately, SAP Fiori is not technically and conceptually designed to quickly authorize SAP Fiori Apps as in the “old SAP GUI world.”

In this blog, I will primarily focus on the paradigm shift in authorization and the challenges in authorization design, implementation, and activation. For interested readers, this blog aims to provide a clearer picture of the fundamental authorization challenges that arise with the implementation of SAP S/4HANA with SAP Fiori.

One thing I can assure you right now is that authorization management will not only become more complex and time-consuming, but SAP Fiori will be a must with the latest SAP S/4HANA releases.

If you are facing an SAP S/4HANA migration and are looking for suitable reading material for your best practice authorization implementation for SAP S/4HANA with SAP Fiori, I recommend our SAP Press book “Authorizations in SAP S/4HANA and SAP Fiori” by my colleague Alessandro Banzer and me. In this book, we cover the basics, best practices for SAP S/4HANA authorization implementation, special cases, SAP Fiori authorizations, SAP GRC, CDS Views authorizations, authorization proposal values, and debugging—everything that will make your authorization heart leap.

Authorization Paradigm Shift in SAP Fiori UI

In our many successfully managed SAP S/4HANA migration projects, there have been numerous discussions and question marks regarding SAP Fiori and the associated authorization implementation. Therefore, I want to emphasize once again that SAP Fiori is:

• A frontend technology that must be integrated into the entire (existing) authorization concept.

• It does not require a separate or parallel authorization concept to be created.

In summary, many functions that were previously performed with SAP GUI using transactions or Web Dynpros are now accomplished through OData services via the SAP Fiori Launchpad frontend using SAP Fiori Apps.

In the “old SAP GUI world,” a standard SAP role had a transaction added via the role menu, and the SU24 authorization proposal values for the transaction were directly incorporated into the authorization profile (see Figure 2). These were then specified in the authorization profile, the role was generated, tested, and the user could then work in production via SAP GUI.

With SAP Fiori, the picture is now different and, above all, more complex, as you can probably see in Figure 3.

Now, not only have some components been added that can no longer be maintained directly as applications in the role menu, but you also need to activate technical entities for SAP Fiori Apps, such as ODATA services. Moreover, for full web interface usage, you may need to activate critical ICF nodes as needed. Please note that it is not possible to simply add a SAP Fiori App to the role menu as with a transaction. New authorization components are now required, such as the SAP Fiori Business Catalog, groups or areas, and pages. Additionally, you must now consider the backend part, authorizations, and the frontend part, the SAP Fiori Launchpad and its app usage. Your authorization and role concept is where these two parts converge. Therefore, one cannot speak of a SAP Fiori concept but, if anything, a SAP Fiori-based authorization concept that combines all application types (transactions, WebDynpros, ODATA services through SAP Fiori, etc.). In summary, the implementation of SAP Fiori authorizations with all the new and different components leads to significant additional efforts compared to SAP GUI work.

For an in-depth explanation of this paradigm shift in authorization with SAP Fiori, please take a look at the comprehensive blog by my colleague Stefan Wohlschlag on the topic “On the Complexity of Authorization Management in SAP Fiori.

SAP Fiori Pain Points

The authorization pain points in SAP Fiori are diverse and range from complex role and authorization management to ensuring that users can only access those SAP Fiori applications and functions for which they are authorized. Additionally, security must be ensured to prevent unauthorized access while maintaining user-friendliness. The solution to these pain points requires a precise authorization structure, documentation, and regular checks to ensure that authorizations align with business requirements and meet compliance requirements.

Feel free to explore my other blogs on the topic of SAP Fiori:

• SAP Fiori 3.0 | The New Design Concept of SAP S/4HANA (Basics, Part 1)
• SAP S/4HANA Fiori | Preparations for SAP Fiori Authorization Roles (Part 2)
• SAP S/4HANA Fiori | SAP Fiori Authorization Roles and Role Building (Part 3)

Protected Go-Live in Authorization Projects with SAP Fiori Launchpad

One of the most critical phases in a project is always the go-live. The new authorization concept will go live for the first time in a productive environment, and there is always the tendency to worry about unforeseen showstoppers that cannot be immediately addressed and resolved. Here, the Xiting Times Self Service, which can be used based on SAP GUI and SAP Fiori, comes to the rescue (Figure 4). It enables a completely uninterrupted go-live, where even failed authorization checks are automatically recorded with meticulous detail.

For more details on Xiting Protected Go-Live, please check out my colleague Manuel Griebel’s blog,“Putting an End to Uncertain Go-Live Phases – Xiting Protected Go-Live.” Note that we now also provide the use of Protected Go-Live in the SAP Fiori environment.

Identification of Used SAP Fiori Apps

Especially at the beginning of an SAP S/4HANA system, it can be challenging for the business department to identify the exact and required SAP Fiori Apps for business processes. The delivered SAP Business Catalogs are not a solution for everyday use but should only be used for functional tests since they represent too extensive an application scope with a 1:1 takeover. Thus, the challenge arises: which SAP Fiori Apps do I really need, and which ones have I executed during my tests? In the standard, you can only answer this question by using multiple information sources, such as the SAP Fiori App Library and S/4HANA Simplification List, in conjunction with a comprehensive testing process. However, it is technically not possible in the standard to narrow down to the actually used SAP Fiori Apps, as today’s trace capabilities do not allow it. Additionally, so-called “related Apps” add to the complexity. For this, we at Xiting have developed our Xiting Fiori App Tracker. It allows for automated identification of necessary Fiori Apps, including their additional information at the user level, as seen in Figure 5. Moreover, through integrated app tracking and simulation of backend roles, you can develop an audit-compliant and Fiori-based authorization concept.

Creation of Consistent Role Transports, Including SAP Fiori Objects This pain point may initially be perplexing for some, as it involves “just” transports. However, with SAP Fiori, the complexity has dramatically increased here as well. Even when a transaction needs to be “Fiorized,” i.e., a legacy app is created, a minimum of five different objects must be transported. Here, you need to include the technical catalog, business catalog, spaces, pages, and the role itself in transport requests. It can potentially be more if UI5 apps are included. If you forget just one component, your test is likely to be unsuccessful. Additionally, there are different object types, depending on whether you “Fiorize” transactions via SAP Fiori Launchpad Designer or App Manager. This can be a real showstopper, especially in large projects when there are multiple users responsible for the same roles. Unfortunately, there is no mass processing tool in the SAP standard for this. Transport recordings for SAP Fiori objects only occur for changes in the SAP Fiori context, and you cannot initiate them again directly, as with roles, for example.

A solution is provided by the Xiting Role Replicator for mass transport of any kind. Here, you can choose from a variety of selection criteria, such as the role itself, as shown in Figure 6.

As seen in Figure 7, you can then include all associated objects needed in the SAP Fiori context directly and easily with a click in the transport.

Mass Activation of Services

Anyone who has had to authorize a SAP Fiori App knows the situation: Apps are suggested by the business department, and now these need to be made functional. It sounds simple at first, but it is by no means easy. Before delving into the role work, you first need to work out the necessary technical elements (keyword: role, catalogs, spaces/pages, or groups). Moreover, it is crucial to activate the necessary app-relevant ICF nodes and associated OData services, especially for full web interface usage. For a single SAP Fiori App, this may work via transactions IWFND/MAINT_SERVICES or SICF, but not for numerous different SAP Fiori Apps not coming from the same role. This can quickly become very time-consuming.

In the SAP standard, there is the transaction STC01 for this. Here, you can use the following tasks:

• Task – Activation by Role: SAP_FIORI_FCM_CONTENT_ACTIVATION
• Task – Activation for ODATA Services: SAP_GATEWAY_ACTIVATE_ODATA_SERV
• Task – Activation for ICF Nodes: SAP_BASIS_ACTIVATE_ICF_NODES

In general, troubleshooting with SAP Fiori is much more complex compared to SAP GUI transactions, as there are many different tools and functions for analyzing specific entities. You now need not only transactions SU53 or STAUTHTRACE for your error search but a multitude more.

Authorization Differentiation of a SAP Fiori App Through SU24 Variants

My “Authorization Tool of the year 2022” is by far the updated transaction SU24 with the new function to create proposal data variants (also called application variants). I am truly excited about this new capability to cleanly address complex authorization differentiation. The problem of authorization differentiation within a transaction, e.g., a cockpit transaction like transaction MIGO, existed already in SAP ERP. With SAP Fiori Apps, this problem has now dramatically increased, as there are no longer separate display, change, and create transactions but rather these functions are unified in a SAP Fiori App or transaction, as seen, for example, with the business partner (transaction BP). With the new function in transaction SU24, you can now handle this complex differentiation easily, dividing, for example, the BP into variants for creditors and debtors or into different activity or access scenarios.

Since this topic is becoming increasingly important and is now better represented by the extension of SAP standard functions, we have taken on this possibility of authorization differentiation directly and provided optimized mass functions in our XAMS Suite. Mass processing of multiple proposal data variants is not possible in the SAP standard, but it is crucial for a time- and resource-efficient processing of this issue. With our newly developed functions, you can now not only manage your SU24 variants comprehensively but also create, copy, and delete these application variants massively through upload/download capabilities, as seen in Figure 8.

In my two following blogs, you can learn more about how to make use of these variants:

• The New Transaction SU24N (Part 1)
• Creation and Use of a Transaction SU24N Proposal Data Variant (Part 2)

Conclusion

It is important to reiterate that SAP Fiori is a “new” user interface and must be integrated into the existing authorization concept. SAP Fiori authorization management is highly complex and technically layered, requiring considerable training. Due to ever-faster SAP release cycles and innovations, SAP Fiori and associated tools are fast-paced, necessitating profound changes on a regular basis. For a comprehensive SAP Fiori authorization implementation and management, extensive expert knowledge is required, which must be up-to-date. Importantly, it is now more critical than ever to involve SAP authorization integration during the establishment of SAP Fiori business processes. Testing with the manual profile SAP_ALL will not help much for your rudimentary functional tests.

In this experiential report, I have highlighted the top pain points associated with SAP Fiori authorizations and presented solutions to overcome these challenges. A central solution for a smooth transition from testing to production environments is the Xiting Protected Go-Live through the SAP Fiori Launchpad. It allows uninterrupted work while providing IT administration with the ability to conduct careful error analysis and authorization corrections in the background without production downtime. With the Xiting App Tracker, we have also provided you with a tool to easily identify the SAP Fiori apps used, for example, during your functional tests, leading to significant progress in your SAP S/4HANA migration, including SAP Fiori. Additionally, the creation of consistent role transports, encompassing SAP Fiori objects, is crucial to ensuring that users have consistent access rights in different environments. This is facilitated by the functionalities of our Xiting Role Replicators (LINK!). Furthermore, the report addresses the mass activation of services. It is important to utilize automation tools and processes to efficiently activate the required services for SAP Fiori applications in terms of time and resources. Lastly, the differentiation of authorizations for a SAP Fiori app through SU24 variants is significant. This allows fine-tuning of authorizations to the specific requirements of an application, contributing to the minimization of authorization errors and access risks.

Overall, efficient management of SAP Fiori authorizations is crucial to meet security and compliance requirements while ensuring a user-friendly experience. The solutions and best practices mentioned above provide a guide for companies to successfully address these pain points and maximize the benefits of their SAP Fiori implementations.

I cordially invite you to one of our weekly webinars to learn more about our SAP Fiori tools and XAMS Suite. Given our successful execution of numerous SAP S/4HANA migrations with SAP Fiori for both small and large corporations, feel free to reach out to us if you are currently facing the challenge of an SAP S/4HANA migration or a preceding SAP ERP redesign. We are here to assist you with our decades of expertise in SAP Security. This knowledge is also available to you in the context of comprehensive SAP HANA database security. Additionally, we offer a variety of services and products to support you in maintaining your authorization management.