The SAP FIORI environment has been available on the market for many years. Yet, still, in almost every project I’ve been involved in, many users prefer using the standard SAP GUI interface – an interface whose current form dates back to the early 1990s!
When I ask users and business consultants why this is the case, I often receive responses like, “Oh, it’s just what I’m used to, and with FIORI, it’s just problems – I have access, but I can’t see the applications,” “Something’s always not working, the tiles won’t open, I get browser errors – so I prefer to quickly check things in the GUI,” “In the GUI, I can see everything, but here in FIORI, I don’t see the data, it’s not finding anything.”
Many users immediately associate these types of problems with something complicated, something where analyzing the cause will take a long time and may even require development work. So, they choose the shortcut of going back to the SAP GUI interface, which has already passed its prime and, in terms of visual appeal, data presentation/analysis, and overall capabilities, actually falls short of FIORI applications in almost every way.
To demystify the image of SAP FIORI as an environment where identifying the causes of problems with the visibility or functionality of FIORI tiles seems complicated and time-consuming, in this article, I will describe the causes and solutions for the most common issues – which, as it turns out, are mostly very simple to resolve and don’t require a lot of time. I will also present useful tools for analyzing problem causes, collecting and tracking application logs, and identifying where we can finally fix our application issues.
SAP FIORI – application access architecture
Simply put, SAP FIORI is an overlay for the SAP ERP system – currently most often S/4 HANA, where it serves as the foundational solution. FIORI is built on the SAPUI5 framework based on HTML5, CSS, and JavaScript technologies. This allows FIORI applications to be developed and customized using modern web technologies.
However, the data and applications are still retrieved from the SAP S/4 HANA system, which is based on the ABAP language and with which FIORI is directly integrated. In the current approach, the SAP FIORI Embedded configuration is used, meaning that both the frontend and backend operate within a single SAP system. Below is a diagram of the SAP FIORI application access architecture:
Layers of integration
As shown in the graphic above, there are three main layers of this integration:
- Backend Server (BES) – this is the business logic layer we can assume to be our S/4 HANA system. In this layer, business roles are assigned to users. These roles contain information about FIORI applications, such as the catalogs they are located in, OData services (IWSV), ABAP transactions they use, Web Dynpro applications, etc.
- SAP Frontend Server (FES) – to put it simply, this is what happens in the background of the FIORI environment itself. In this layer, requests for access to the Backend system are sent through the SAP Gateway. This layer also contains access roles with information such as catalogs, groups, and OData services (IWSG).
- SAP FIORI Launchpad (FLP) is the final layer – visual, directly accessible, and visible to the user. This is where the user launches and views FIORI applications.
At first glance, it’s easy to guess that problems can arise at any of these layers.
The most common problems
Let’s look at the most common issues and their causes.
Attention! Before we continue 😊 The article describes situations where a user theoretically should already have access to specific SAP FIORI applications yet still encounters issues with their visibility or functionality. I also assume that the reader is familiar with transactions such as SUIM, SU01, and PFCG to be able to find the role with the missing authorization object (resulting, for example, from SU53 logs) and assign it to the user, modify the selected existing role, or create a new role in the SAP system.
To remind you, there are two ways to verify if a user already has the appropriate role that theoretically should give them access to a specific FIORI application:
- For standard SAP FIORI applications, open the publicly accessible SAP FIORI Apps Library, select the category “All apps,” choose the appropriate SAP system version, and in the “Configuration” tab, check the “Business Role(s)” table for the list of roles that grant access to the selected application. Then, in the SU01 or PFCG transaction, verify if the user already has this role assigned.
- For both standard and custom SAP FIORI applications, open the transaction /n/UI2/FLPCM_CUST in SAP GUI, go to the “Tiles/Target Mappings” tab, and enter the exact name of your FIORI tile (case sensitivity and spaces matter!). Select it and choose the “Show usage in Roles” option. Then, in the SU01 or PFCG transaction, verify if the user already has this role assigned.
It’s also worth checking whether the FIORI application you searched for is in the FIORI catalog in the form of (Tile+TM) and whether this catalog is assigned to the FIORI role that the user has or wants to assign to them. To verify this, follow the same steps as in the previous points, but at the end, choose the “Show usage in Roles” option, check the “Reference Details” column, and in the PFCG transaction, ensure that the catalog is assigned to the role that the user has or that you want to assign to them.
If a given application’s information (Tile + TM) is not available in any catalog, then the missing Tile or TM element must be added to the appropriate FIORI catalog. However, this is a topic for a completely separate article.
For now, I’ve left a link to the SAP Documentation that describes similar cases: SAP Fiori Launchpad Content Manager.
Errors when opening a FIORI tile
Scenario 1.
In the SAP Launchpad, we found the FIORI application we are interested in. We want to open it, but it takes a very long time, and eventually, instead of the application window, we get a 403/404 browser error – an example of such an error is shown below:
This indicates that an OData service (a service that communicates between the front and backend) is not functioning correctly, is inactive, or has not been implemented in the system. To analyze and fix this, follow these steps:
Step 1. Run the transaction /n/UI2/FLPCM_CUST
Step 2. In the “Tiles/Target Mappings” tab, find the application in question, select it, and choose the option Services -> Check and Show Services. Check the oData V2 Services and oData V4 Services tabs. Below are screenshots from the transaction:
If any of the OData services in these tabs have a red status (inactive), you should:
- go to the transaction /n/IWFND/MAINT_SERVICE, find the inactive OData service in the External Service Name column, select it, and activate it in the ICF Services window at the bottom left by choosing ICF Node -> Activate:
If the service status does not change and you receive a system message stating that the service cannot be activated, select ICF Node –> Configure SICF. You will be redirected to the SICF transaction,directly to the tree of objects containing the service. If it is deactivated (grayed out), right-click on it and choose Activate Service, then confirm by selecting the second option, Yes, in the next window, as shown in the screenshots below:
It will now be active when you return to your service in the /n/IWFND/MAINT_SERVICE transaction. Its status will also change to “green” in the OData tabs in the /n/UI2/FLPCM_CUST transaction mentioned at the beginning of Step 2.
- go to the /n/IWFND/MAINT_SERVICE transaction and search for the inactive OData service in the External Service Name column. It has not been implemented in your system if you cannot find it. How can you implement it? Refer to the following articles:
Once the services are implemented and activated, return to your service in the /n/IWFND/MAINT_SERVICE transaction, where it will now be active. Its status will also change to “green” in the OData tabs in the /n/UI2/FLPCM_CUST transaction mentioned at the beginning of Step 2.
Step 3. Test the application’s functionality in the SAP FIORI Launchpad, preferably after refreshing the page, clearing the browser’s cookies/cache, or logging back into SAP FIORI.
Scenario 2.
In the SAP Launchpad, we found the FIORI application we are interested in. We want to open it, but it takes a very long time, and eventually, instead of the application window, we receive a 403/500 browser error – request failed, for example:
You should proceed in the same way as in Scenario 1, with the difference that in Step 2, you need to check the ICF Services tab. If any ICF service is inactive, you should select it and choose the Define Services option, and then activate the ICF service in the same way as in Scenario 1 – Step 2, when the system redirected us to the SICF transaction:
The 403/500 error – Request Failed or Component Failed may also have a direct authorization-related cause in the SAP S/4 HANA system. The user may not have the necessary authorizations for the S_RFCACL authorization object, which we can diagnose using the SU53, STAUTHTRACE, or App Support (in FIORI) transactions. I will mention these tools further in the article.
Scenario 3.
The steps taken in Scenarios 1 and 2 did not help, and additionally, we are receiving the following message:
This means that the application still cannot locate a particular oData service and, consequently, the ICF service as well. To verify this, you should perform Step 1 and Step 2 from Scenario 1 and check if the number of oData V2 and V4 services matches the documentation for this application in the FIORI Library. Any service that is missing should be added similarly to Scenario 1, Step 2(b).
Authorization errors in CDS views
CDS (Core Data Services) views in SAP allow the creation of advanced, efficient, and complex data models and application logic at the database level. These views can be accessed via SAP FIORI. Still, access to the mentioned data models (Virtual Data Model) in CDS views is always controlled through a combination of the following authorizations:
- Classic authorization object checks – through authorization checks in ABAP code, such as objects (S_TCODE, S_START, S_SERVICE, SDDLVIEW, etc.) – occur when the application is started.
- User authorization verification at the CDS view data source level happens dynamically while using the view as it fetches additional data. Permissions in the CDS view code are continually compared to the user authorizations in PFCG.
Below is a diagram comparing the classic approach to authorization verification for ABAP-based applications with the DCL approach for CDS views:
The DCL (Data Control Language) approach defines what data a user can view, depending on their permissions. It is mainly used to restrict access to data at the record level (row-level security) and at the column level (column-level security) in CDS data models.
Once defined, authorization rules are automatically applied to all queries using the given CDS view, ensuring consistency and reducing the risk of errors. This allows for dynamic and context-sensitive data access adjustments based on user attributes, which is harder to achieve with the classic approach.
Due to their more flexible and efficient operation, CDS views and the DCL approach are also increasingly used in standard SAP transactions. An example is the Display Material (MM03) application.
User tracking and simulation of data access in CDS
In transaction STAUTHTRACE, I initiated user tracking to verify which authorizations I am attempting to use. After starting the Display Material (MM03) application, I received the following logs:
As seen in the CDS Entity column, there is information that some of the data displayed to me in the Display Material (MM03) application comes from a CDS view, and access to this data is authorized at the CDS view level. An important note is that such information will not be available in SU53!
Therefore, for more detailed verification of logs/authorization errors, it is also advisable to use transaction STAUTHTRACE. Furthermore, from the logs, I can directly navigate to the CDS Access Control application, allowing me to verify what is being checked in the CDS view to display the appropriate data. Below is an example of the previously invoked view:
As shown, there is a fragment of code that, at the CDS view level, compares the values of authorization objects provided here with the authorization objects held by the user currently viewing the CDS view and decides whether the specific data set can be displayed.
In the example above, this data set pertains to access to product groups (object M_MATE_MAT, field: BEGRU). The CDS view checks what access the user has to the object and displays data only for those product groups (BEGRU) where the user has the activity values 03 (display) and F4 (display in value help).
Therefore, unlike the classic approach, the system does not check every activity field value (ACTVT) value for the data product groups from the BEGRU field in the ABAP script. Instead, it “fetches” the user’s accesses (activities) to the values in the BEGRU field and, at the database script level, checks if these values are among those specified in the CDS view query. If they are, the data is displayed. A beneficial tool for verifying what data a specific user can access in a view is the CDS Access Control Runtime Simulator (SACM):
In Fig. 20, it is clear that my user can access all data in this view. However, in Fig. 21, a user with different roles can only access one product group marked as XYZ. Only data for this product group will be displayed to them in the application using this CDS view.
This is very useful when a user cannot see some data and receives no authorization error, nor does it appear in SU53. In such cases, combining STAUTHTRACE and SACM tools significantly eases the problem analysis.
Error analysis tools + most commonly detected errors
SU53
This is a tool that hardly needs an introduction; it is an absolute classic for analyzing authorization issues in both ABAP and FIORI systems 😊
In the context of FIORI application functionality, the most common problem is the lack of user authorization for the relevant services (e.g., ODATA) defined in the authorization object S_SERVICE. This will cause issues with opening applications or even result in a lack of access to specific data or options.
Below is an example of such logs in transaction SU53:
To resolve this, you need to either find a role that already contains the object with that value (e.g., using transaction SUIM) or add this value to the S_SERVICE object in an existing role using transaction PFCG:
A limitation of SU53 is that it does not provide logs for all types of authorization errors; for example, it does not include logs for errors related to CDS view authorizations defined at the CDS view code level.
TIP! As soon as you know that a FIORI application has been affected and check the logs in SU53, it is advisable to save them immediately, as they are only visible for a limited time. This way, you avoid asking the user to “regenerate” the error 😊 Alternatively, you can ask the user to download and send us the logs.
App Support
Simplified, this is the equivalent of SU53 but available directly from the SAP FIORI Launchpad. However, this application is not available by default; it must be activated, and the FIORI catalog must be added to the roles we select in SAP. The application appears as follows:
SAP documentation on how to activate the application for users: Setting Up App Support.
STAUTHTRACE
This tool allows you to track which authorization objects are checked during specific user operations. This helps identify which authorizations are required and which are causing problems. You can select the range of users for whom you want to enable tracing and specify the operations you want to track:
This tool will also indicate errors related to permissions for CDS views.
/n/IWFND/ERROR_LOG
This diagnostic tool allows verification of error logs during the processing of oData service requests – errors related to communication between SAP Gateway and the backend system, including data processing issues:
/n/IWBEP/ERROR_LOG
Similar to the previous tool, it allows verification of error logs during oData request processing, but on the backend side. It also helps analyze errors related to the RFC authorization object – S_RFCACL mentioned earlier:
ST22
A transaction used for analyzing ABAP errors. It is included here because sometimes what initially appears to be an authorization error may not be one 😊 For example, if a user receives an unclear error message that suggests a lack of access. There are no error logs in transaction SU53; it is worth checking logs in transaction ST22 to determine if it is an ABAP/developer error:
Browser Developer Tools (Chrome, Firefox, Edge, Opera, etc.)
Many things in SAP FIORI occur at the browser level, so using built-in developer tools and their consoles can help pinpoint the source of potential problems – verify what request was made and which service/function caused the error. Below is a screenshot of an example error and the information that can be read from the developer tool:
Additional useful tools
- /UI5/APP_INDEX_CALCULATE – this transaction generates or recreates the SAPUI5 application index, which is crucial after deploying new Fiori applications, system updates, or changes in application configuration. Using this transaction is often recommended when facing issues with displaying Fiori applications, such as missing applications or availability problems—especially if changes have been made.
- /n/IWFND/CACHE_CLEANUP – in case of issues with oData services or Fiori applications, such as malfunctioning applications or missing or outdated data, this transaction can help restore proper functioning by clearing the cache, forcing the system to reload current data from the backend.
- SM20 (Security Audit Log) – used to review user logs, such as their transactions.
- SLG1 – Used to review system logs triggered by the user, such as in a specific transaction or program.
- HTTP Trace Tools – various tools for monitoring HTTP or oData requests in the context of SAP FIORI applications. You can review detailed information about each request, such as the method (GET, POST, PUT, DELETE), headers, body, response status, response time, and more.
Other errors
- Incorrectly assigned or missing system alias during the creation/configuration of a new FIORI application, specifically for the services supporting it. This results in the application not being visible in the FIORI environment. For more information and examples, refer to: SAP Community – No System Alias found for Service ” and user,” and SAP Note 3245402 – OData Service throws an error: System alias ‘ ‘ does not exist
- Users hide applications themselves – if users can personalize groups in the FIORI system, users often experiment with the system or accidentally hide tiles from the FIORI application view. This can be done using the Edit Home Page option by clicking on their avatar in SAP FIORI:
Summary
Although managing the access and visibility of applications and data within the SAP FIORI environment may seem challenging, knowing the right tools and common issues can greatly simplify the process.
It is helpful to prepare a so-called task list with potential problems, solutions, and instructions to address them and systematically apply it when the cause is unclear. Over time, this approach becomes second nature, and you can identify and resolve issues in just a few minutes. Additionally, in today’s world, it is beneficial to utilize AI-powered tools that can provide valuable insights and even offer step-by-step solutions. I hope this article proves helpful and aids in the rapid resolution of common issues, ultimately encouraging end-users to use FIORI applications instead of the traditional GUI 😊
***
If you are interested in SAP topics, also take a look at other articles by our specialists.
Leave a comment