How to Identify Authorization Errors in the SAP Fiori Launchpad

The first app I set up in the SAP Fiori Launchpad was My Leave Requests in version 1 of the transactional app. As being relatively new to Fiori and to HR topics, it was quite a struggle for me to figure out which authorizations are required to run the app. Of course, HR authorization checks have their own challenges, but adding these challenges to a distributed landscape simply leads to a very long implementation phase. Fortunately, now there is the possibility to speed up authorization troubleshooting, without having to switch to SAP GUI. In the following article, I will cover the possibilities of looking up authorization issues by using the App Support plugin in the SAP Fiori Launchpad. For easier reading, I’ve split up the topic into two different points of view. I think this makes sense, as the requirements for somebody with a more technical background (key user or admin) might be different from a business user.

Example setup: End User

Usually, business users are not really interested in the error details themselves, but more in a correctly working app. I’ll start with the steps from the user’s point of view and then follow up with the setup. In this example, I’m using the Create Purchase Requisition app, which is a UI5 application. After the user clicks on the tile the stops with an authorization error message. The user is now able to retrieve his authorization errors from App Support:

The user can now download an Excel file and forward it to the IT support staff or a key user. The file contains multiple sheets, most importantly the authorization errors for the front-end and back-end system:

How to setup App Support for this scenario

On the front-end server you will have to add authorization object S_FLP_AS to your general user roles. In transaction PFCG you can then specify which information should be generally available. In this case, you would only add ADELOCALAUTHORIZATIONLOG and ADEREMOTEAUTHORIZATIONLOG for field SUI_ADEDS. As you only want them to be able to access their own logs, set SUI_ADEUS to CURRENT. The settings for ACTVT depend mostly on your company’s preferences. You can decide, if users should be able to see their authorization errors or only be able to download them. In this example I’ve set them to ‘DL’ Download only.

After assigning this role to your user group, it should be possible for them to retrieve their authorization logs as described above.

Example setup: Key User

Key users usually can handle the more technical information displayed in authorization logs, so they would want to see the authorization errors right away for their own and for other users. We continue to use the app Create Purchase Requisition. Let’s assume another user contacted our key user for assistance, the only information provided is the screenshot above with the error message.Our key user now logs in to the same app and checks, if authorization errors exist for the other user with App Support.

After the dialog opens, the key user can navigate to the authorization errors of the participating systems.

After switching the name in the User field, our key user is able to look up the missing authorizations for the other users.

How to setup App Support for this scenario

On the front-end server, you will have to add the authorization object S_FLP_AS to your key user roles. In transaction PFCG you can then specify which information should be generally available.

For field SUI_ADEDS you define which logs should be displayed. In this case only the authorization logs ADELOCALAUTHORIZATIONLOG and ADEREMOTEAUTHORIZATIONLOG are relevant. Since you want key users to review authorization issues for other users as well, grant full authorizations for SUI_ADEUS. For the field ACTVT, you can decide if the users should be able to see their authorization errors or only be able to download them. In addition to the setting for S_FLP_AS the key user will also require authorization to read error logs for a different user on the backend and frontend. These authorization rights should already be in place if the key users are able to lookup the errors in transaction SU53. These would be tied to the authorization object S_USER_GRP.

While authorization errors are only a small set of App Support’s features, they are probably the most important ones in a day-to-day business. By setting up the system in this way, users are enabled to retrieve their own authorization errors and speed up problem-solving.