SAP Fiori 3.0 is the latest user interface (UI), or user experience (UX), from SAP. It replaces traditional UIs, like the SAP GUI. With SAP Fiori 3.0, SAP provides applications by using cards (formerly called tiles) to encapsulate standard business tasks, such as approving purchase requisitions and displaying sales orders, through role-based SAP Fiori apps. 

SAP Fiori is available for most SAP software products, such as SAP ERP (ECC), SAP S/4HANA, SAP Ariba Mobile, SAP Hybris Cloud for Customer and SAP SuccessFactors, and it utilizes the latest in-memory computing technology with the SAP HANA database. 

To use SAP Fiori, the end-user must have proper authorizations for the applications and underlying business data. In addition to app-specific authorizations, the end-users also need certain general authorizations for the frontend server and backend server. These authorizations are required to run the SAP Fiori launchpad, to trigger the OData services required for the SAP UI5 applications, and to run (for example) analytical SAP Fiori apps launched by using a KPI tile.

Role administrators must maintain SAP Fiori authorizations in transaction code PFCG, which remains the same approach as with all other ABAP authorizations.

The architecture in every SAP Fiori installation includes the SAP Fiori Launchpad (FLP) and the SAP Web Dispatcher, as well as the SAP Frontend Server (FES) and the SAP Backend Server (BES). The SAP Fiori Launchpad and the SAP Web Dispatcher run on the SAP Frontend Server.

SAP Fiori can be deployed in two different scenarios: an embedded deployment or a central hub deployment.

In an embedded deployment scenario, the frontend and backend servers run on the same instance, whereas in the central hub scenario the frontend and backend server are physically separated and connected through a remote function call (RFC). The backend server (BES) can be any type of an SAP system, like an SAP NetWeaver ABAP installation (e.g., SAP S/4HANA or SAP ERP).

In the early stages of Fiori, SAP recommended the central hub scenario but revised the recommendation with later releases. Nowadays, SAP recommends the embedded scenario in which the frontend and backend server are located on the same system. The main drivers for using the embedded scenario are better upgradability with new releases and lower cost (by reducing the number of systems required).

Regardless of the deployment scenario, your end-users require authorizations for both the frontend (SAP Fiori Launchpad, cards, etc.) as well as the backend server (oData services). In an embedded scenario, you can build the frontend and backend authorizations into one role.

Conversely, in the central hub scenario, you have to build two roles: one for frontend authorizations on the frontend server, and one for backend authorizations on the backend system.

From an SAP security perspective, the end-user needs the proper authorizations to start an application (card) in the SAP Fiori Launchpad by having authorizations for the corresponding Fiori group and catalog on the frontend server. That ensures that the Fiori application can be executed in the SAP Fiori Launchpad and call the OData service on the backend server.

On the frontend server, you have to build a PFCG role that contains and authorizes the group, catalog, and frontend OData services (object IWSG). On the backend server, you have to authorize the catalog and the backend OData services (object IWSV), as well as transactions, web dynpros, and the authorization objects required in the back-end role.

SAP Fiori Authorizations

The end-user requires basic authorizations to start and use the SAP Fiori Launchpad. SAP delivers predefined role templates for end-users, as well as for administrators. The roles are SAP_UI2_USER_700 for end-users and SAP_UI2_ADMIN_700 for administrators.

However, we recommend building custom roles for your end-users with the below authorizations. SAP standard roles should not be assigned to productive users, and it’s therefore recommended to build a custom role.

In a central hub scenario, your back-end authorizations require authorization objects S_RFC and S_RFCACL to enable access to the backend server via a trusted RFC connection. Remember, when using trusted RFC connections, the user IDs need to be identical on the frontend and backend server. Also, for S_RFCACL, add the SIDs and clients from all the frontend-servers (DEV, QAS, PROD) specifically instead of an asterisk (*).

The graphic below shows the Fiori Launchpad when properly authorized. In addition to the basic authorizations needed to start the Fiori Launchpad, users require app-specific authorizations through so-called catalogs and groups. Catalogs carry the authorizations for an application, whereas the group displays the applications on the end-user’s home screen in tabs.

When building Fiori roles, it’s important to build them through the role menu to take advantage of the authorization proposals from transaction SU24.

SAP delivers SU24 authorization default values for the backend services, and we recommend applying the same security principles as you would for your ABAP tcodes to leverage the proposals from transaction SU24.

This approach not only helps you in building the roles initially, but also in maintaining a sustainable role design going forward.

Learn More About Fiori Authorizations

To learn more about Fiori authorizations, check out the following Xiting webinars:

• SAP Fiori Authorizations – What You Need To Know
• SAP Fiori Authorizations: Challenges and Solutions
• Deep-Dive into Debugging Fiori Authorizations
• Simplifying Fiori Authorization Management with Automation Tools

SAP Fiori Apps Library

The SAP Fiori Apps Library offers an excellent overview of, and insights into, the available Fiori applications. It’s a great starting point for exploring new apps and learning how to correctly authorize them.

The SAP Fiori Apps Recommendation service allows you to upload historical usage data (e.g., ST03N) to see which Fiori applications can possibly replace or enhance the legacy transactions your users have used in the past.

For example, you can search for legacy transaction VA01 and the app library will show you available Fiori apps that can replace parts or all of the transactions’ functionality.

If you’d like to perform this mapping task directly inside of your SAP system, you can use automation tools, such as the Xiting Authorizations Management Suite (XAMS).

Using the XAMS reporting tools, you can get an understanding of what applications are required (based on historical usage data in your system) and how to correctly implement and authorize them.

The screenshot below shows the output of one of the XAMS reports and illustrates what Fiori apps you could use for sample user ASAMBILL (based on the user’s transaction history).

To learn more about a particular Fiori application, you can simply copy the Fiori App ID and paste it into the search field of the Fiori Apps Library.

Xiting Role Profiler Analysis of Used tcodes for Fiori Applications" />

In addition, the Fiori Apps library provides you with the implementation details of all applications. In the tab Implementation Information > Configuration, you can see the OData services as well as the pre-defined catalog and role that SAP delivers.

Such templates enable you to test new roles in a sandbox environment without having to first build out authorizations manually.

Before you implement app-specific authorizations, make sure that the frontend and backend components in your SAP system have the required patch level, and that the relevant SAPUI5 Fiori applications and OData services are activated.

SAP Fiori Catalogs vs. SAP Fiori Groups

SAP recommends a role design for SAP Fiori authorizations based on the defined catalogs and groups in the Fiori Launchpad. Such a catalog usually contains a set of apps and services that are relevant for a specific user group.

If a role has been authorized for one or more catalogs, the corresponding catalogs and groups are only displayed for the authorized users when the Fiori Launchpad is started. This ensures that each user only sees the apps they require.

A catalog contains Fiori applications for a job function (e.g., sales manager) and is similar to a business role. A catalog can have one or more Fiori Apps.

The group defines the view of the Fiori Apps in the Fiori Launchpad. The creation of groups is based on business requirements and could, for example, follow a task-based approach.

You can create multiple groups per job function. A group contains applications from one or more catalogs.

For example, the catalog “Sales Manager” contains four applications, which are then separated into two groups (e.g., “Reporting” and “Internal Sales”).

You can build catalogs and groups on the frontend server in the Fiori Launchpad Designer. It is important to understand that in order to get authorized for the group “Reporting,” the end-users need to be authorized for the catalog(s) that carry the applications of the group “Reporting.”

In the above example, that means that you have to authorize the catalog “Sales Manager,” which will also authorize two more cards that are not present in the group “Reporting.”

The end-user will not see the cards on the Fiori Launchpad by default, but can find the cards through the so-called “App Finder.”

Hence, we have to understand that when we authorize a catalog all the contained apps are being authorized, regardless of whether they are in a group or not.

When designing SAP Fiori groups, you can enable personalization for the end-users, which means that, when allowed, the end-user can personalize the applications in the group (add, remove, move).

The end-user is only allowed to add or remove applications that he or she is authorized for through the catalogs. However, with personalization enabled, the end-user can control the apps that are displayed for a group on the homepage. Therefore, it is not always recommended to allow personalization, as users might accidentally remove an application from the group and not know how to re-add it.

Design Considerations for Catalogs and Groups

SAP recommends building groups that contain applications from a single catalog, which means that in one group you only add apps from one catalog.

SAP differentiates between technical catalogs and business catalogs. In the Fiori Apps Library, you can see the information for both catalog types.

Technical catalogs start with the prefix SAP_TC, whereas business catalogs have the prefix SAP_*_BC. The asterisk is a placeholder that identifies the module the catalog is associated with. For example, SAP_FIN_BC would be a prefix for a finance catalog.

SAP uses the technical catalog to group applications based on their component, whereas the business catalog represents a job function. For example, the application “Create Sales Order” comes with the following catalogs:

• Technical catalog: SAP_SD_TC_T_X1
• Business catalog: SAP_SD_BC_FIELDSALESREP_X1

The technical catalog defines the applications that are from the same module, whereas the business catalog represents the job function “Field Sales Representative” and contains multiple applications that SAP groups for this very job.

Therefore, the business catalog might contain applications from various technical catalogs.

When building your own catalogs (which is the recommended approach), you should always use the technical catalog as a reference and not the business catalog. Whenever possible, use the reference feature in the launchpad designer to make use of the pre-delivered configuration (learn more about how to reference applications in the next section, SAP Fiori Launchpad Designer).

When building custom groups, always make sure that you include the apps from your custom catalogs and not from the SAP standard technical catalog.

The best practice for building custom catalogs and groups is to follow a job-based approach for your catalogs and then define the groups to display the applications on the user’s homepage. By doing this, you can specifically define what applications need to be authorized per job function through the catalog.

Again, make sure that you add applications from one catalog into one group.

On the other hand, if you design your catalogs as building-blocks (i.e., a task-based approach), you increase the complexity in a similar way as you would when using composite roles in PFCG.

For example, removing an application from a “building block” catalog that’s used in multiple groups impacts all of those groups — including those you might not even be aware of.

Therefore, we recommend following a job-based approach for your catalogs and building the groups with applications from one catalog only.

SAP Fiori Launchpad Designer

The SAP Fiori Launchpad Designer is the main tool for creating and maintaining catalogs, groups and cards, up until SAP S/4HANA 2020.

As of SAP S/4HANA 2020, the maintenance of technical catalogs will shift to the Launchpad App Manager (see next chapter).

You can start the Fiori Launchpad Designer with transaction /UI2/FLPD_CUST.

The Fiori Launchpad Designer is the standard tool for:

• Configuring the cards and their target mappings.
• Creating pre-configured groups and catalogs.
• Transporting the configurations (groups, catalogs and cards).

Within the Fiori Launchpad Designer, you can build and maintain your custom groups and catalogs. When building custom catalogs, always use the reference to the pre-delivered technical catalogs from SAP, so that you don’t have to configure the application manually.

To add applications to your custom catalog, simply drag and drop the applications from the technical catalog and create a reference.

The SAP Fiori Launchpad Designer, as well as the SAP Fiori Launchpad Content Manager, can be accessed in two scopes: cross-client configuration (CONF), and client-specific customizing (CUST) scope.

In the CONF scope changes are made client-independent, which requires a workbench transport. The CUST scope requires a customizing transport as it’s a client-dependent configuration.

SAP recommends performing the changes in the CUST scope, and transporting from one client to another, if required. With regards to authorizations, you build roles and authorizations client-dependent. Therefore, we recommend following the same principle for the SAP Fiori content.

As long as you don’t change the configuration of an application in your custom catalog, the reference to the original application from the technical catalog will remain intact.

If you make a change, the reference will be broken, which means that the application will still continue to work but you have to transfer potential changes to the application manually. SAP might change the configuration to the application in the technical catalog with the next support package, which you then have to manually perform in your custom catalog. Therefore, it’s recommended that you keep the reference intact. If the reference is intact, the configuration will automatically be updated when a change to the technical catalog is being performed.

The screenshot below shows an example of a technical catalog while creating a reference of an app. To create a reference, simply drag and drop an application, left click with your mouse, and hold so that the launchpad designer will show a pop-up dialog that allows you to create a reference.

After adding the application to the custom catalog, you also have to reference the target mapping. Applications don’t work without the target mapping, which holds the configuration of the application.

To create the reference of the target mapping, simply go to the Target Mapping tab, select the one you want to use, and choose Create Reference.

Interactive features, such as the ability to drag and drop elements, make the launchpad designer a straightforward and easy-to-use tool for administrators.

As a result, creating new catalogs or groups is as simple as entering a name (title) and a technical ID — similar to how you create roles in transaction PFCG.

Once a catalog is created, you can easily add new applications through the referencing capabilities. Similarly, when defining groups, you can select the applications from a catalog.

SAP Fiori Launchpad App Manager

As of SAP S/4HANA 2020, the maintenance of technical catalogs will shift to the Launchpad App Manager that you can start with transaction /UI2/FLPAM. The purpose of this tool is to manage all technical catalogs in one place. It supersedes the SAP Fiori Launchpad Designer.

We will update this article as soon as the new tool has been released.

SAP Fiori Launchpad Content Manager

The SAP Fiori Launchpad Content Manager helps you with the creation and adaptation of SAP Fiori launchpad catalogs.

The content manager was introduced with release 1909 FSP01 and enhances the launchpad designer. You can use it to explore existing content and to create your own catalogs by copying existing ones and modifying them to fit your needs.

You can start the content manager using transaction /UI2/FLPCM_CUST (client specific). In the content manager, you can check the catalogs for its services to make sure they are activated and properly configured.

The content manager is a great tool when building business catalogs as it helps you to make sure all required services and configurations are available and configured correctly.

You can learn more about the Fiori Launchpad Content Manager here.

SAP Fiori Rapid Activation

With SAP S/4HANA, SAP introduced the rapid content activation task list to dramatically reduce the activation effort of such an implementation. The SAP Rapid Activation Content SAP_FIORI_FCM_CONTENT_ACTIVATION is available as of release 1909 FSP01. If you are on a lower release, please check SAP Note 2834415.

When implementing Fiori, you have to activate certain OData services, which are used by the UI5 applications. Historically, you activate services through transaction /IWFND/MAINT_SERVICE, but SAP allows mass activation using transaction STC01 and task list SAP_GATEWAY_ACTIVATE_ODATA_SERV.

In addition, you can use the task list SAP_BASIS_ACTIVATE_ICF_NODES to activate several ICF nodes in one shot.

You can learn more about Rapid Content Activation here.

SAP S/4HANA Migration and Fiori Implementation

With the migration to SAP S/4HANA, SAP Fiori is no longer optional but mandatory because SAP has moved numerous capabilities into Fiori. Especially when using SAP S/4HANA Essential (Multi Tenant) or Extended (Single Tenant), Fiori has become the standard user interface.

Therefore, when migrating to SAP S/4HANA, you have to adjust the authorization concept to include the new Fiori authorizations. SAP provides a “Simplification List” for each S/4HANA release that further details the replacement of legacy transactions with Fiori apps, or new ABAP transactions, web dynpros, etc.

The Simplification List is a PDF document that contains several hundred pages and is difficult to digest. Therefore, we recommended using automation tools that simplify and automate the migration to S/4HANA.

For example, the Xiting Authorizations Management Suite (XAMS), as described in SAP Note 1682316, enables organizations to automate the migration of roles to SAP S/4HANA.

With the XAMS, you can leverage the information from the Fiori Apps Library, the Simplification List, your existing role concept, and usage data from ST03N to dramatically speed up the migration of roles and authorizations from ECC to SAP S/4HANA.

In addition, the XAMS offers a variety of mass-processing tools to speed up the maintenance of catalogs and groups, as well as assignments of the Fiori applications and target mappings.

Most of the mass-processing tools offer import/export functionality from Microsoft Excel, which allows the security administrator to define roles in a known application.

Impact on SAP Access Control (GRC) and Segregation of Duties (SOD) Considerations

When implementing SAP Fiori, we have to understand that SAP Fiori authorizations must be considered in the SAP Access Control (GRC) ruleset for risk analysis (critical access, segregation of duties, etc.). Having a ruleset in place that also covers SAP UI5 apps early on enables you to check new roles for SoD conflicts as you design roles to authorize users for those Fiori apps.

If you do not have an updated ruleset, you should make sure not to over-authorize your end-users. That’s why we recommend avoiding asterisks (*) or broad value ranges in your authorization data when building the roles.

Expert tools, like the one mentioned in SAP Note 1682316, can help you find missing authorization values and build compliance conform roles from the get-go.

SAP Access Control (GRC) 10.1 Support Package 22 (initially introduced with SP19) and SAP Access Control 12.0 SP03 contain rulesets for SAP S/4HANA and SAP Fiori. If you are not on SAP Access Control 12.0 yet, please make sure you upgrade before the end of 2020. SAP’s support for SAP Access Control 10.0/10.1 will end on December 31st, 2020.

Conclusion

The third generation of SAP Fiori is an exciting new user experience that becomes significantly more important when moving to SAP S/4HANA or SAP’s new cloud solutions.

With the migration to SAP S/4HANA, SAP Fiori must be part of the upgrade/migration project as its implementation may be required. That’s because some of the new and updated features are only available in Fiori.

From a security point of view, Fiori demands an understanding of the architecture and how to build and authorize catalogs and groups. Luckily, you can build your roles and authorizations using the same tools you used in the past.

We strongly recommend following the same authorization principles as for your traditional ABAP authorization roles, including the use of the authorization defaults in transaction SU24.

When implementing Fiori, also make sure to consider the Fiori applications in the SAP Access Control (GRC) ruleset to ensure seamless compliance.