Search
Close this search box.

Migration from SAP Fiori Groups to SAP Fiori Spaces

SAP Fiori was first introduced in 2013 to improve the user-friendliness of SAP applications. It was based on the principle of role-based, simple and intuitive user interfaces. Originally, Fiori relied on tiles in groups to organize content. This allowed users to quickly access specific functions or data via personalized home pages.

With the further development of Fiori, SAP has placed a stronger focus on modularity and flexibility. A significant innovation was the transition from Fiori groups to Fiori Spaces and Pages. Instead of simply organizing information and applications in groups, the concept of Spaces enables a hierarchical, multi-layered structure in which users can navigate better between different contexts. Pages serve as specific navigation levels within an area and offer an even better overview of relevant applications and content.

This transition reflects the growing requirements of companies that want to map increasingly complex scenarios in their SAP systems while ensuring a simple user experience.

The advantages at a glance:

1. Clarity and better organization

Instead of numerous groups in the Launchpad, which often appear confusing, spaces offer a tidy and thematically clearly structured interface. Users see the spaces and pages that are relevant to them, which reduces complexity and simplifies navigation.

2. Improved performance and user satisfaction

The separation of spaces and pages makes the Fiori Launchpad leaner and more performant. This leads to a faster page load time and an overall higher user satisfaction.

3. Customizable and role-based spaces

The role-based assignment of SAP Fiori spaces allows you to optimize the user interface for different user groups. This provides customized dashboards that display only the necessary apps, increasing employee efficiency.

How does a migration from SAP Fiori groups to SAP Fiori spaces generally work?

The migration process from groups to spaces requires careful planning and consideration of the existing structure. Here are the general steps you should follow during the migration:

1. Preparation

  • Analyse the existing group structure: Review the SAP Fiori groups currently in use and identify spaces where multiple groups overlap or unnecessary redundancies exist. The structure of the catalogs and PFCG roles should also be checked as part of this process.
  • Define the new structure: Plan what the new SAP Fiori Spaces and Pages should look like. The topics and content should be user-oriented and logically structured. According to Xiting best practice, we highly recommend structuring the SAP Fiori catalogs 1:1 to their PFCG roles. The PFCG (individual) roles should in turn be structured and set up in a workplace-oriented manner.

2. Conception

  • Definition of Spaces: An SAP Fiori Space, as well as a catalog, should represent a job function or workplace, e.g. accounts payable clerk, accounts receivable clerk, general ledger clerk, buyer, etc.
  • Create Pages within the Spaces: Within an Space, there can be multiple Pages that reflect specific processes or app groups. The frequently used apps should be clearly visible here.
  • Design aspect of Spaces: With the introduction of Spaces, the visibility of tiles also changed. In previous S/4 HANA versions, tiles in Spaces were only visible if the user had also assigned the specific business catalog referenced in the Space. This restriction meant that Spaces were generally only created for specific roles (e.g. an ā€œAccounts Payable Accountantā€ Space). However, this problem has been solved in current S/4 HANA versions with the introduction of a ā€œVisualization ID Related to Technical Catalogā€. This new Visualization ID means that the visibility of a tile can now be controlled independently of the assignment of specific business catalogs. The key factor for the visibility of a tile is now the existence of the authorization for the navigation intent referenced in the space via any assigned business catalog. Due to this newly gained flexibility, it is now also possible to create global, reusable spaces. For example, a ā€œReportingā€ Space could be reused in different roles. Depending on his job function, a user would see exactly those tiles in this space to which he is authorized. Tiles that are not authorized are automatically hidden.

3. Migration of the existing groups

To do this, the following OData services must first be activated via STC01 with the task list SAP_GATEWAY_ACTIVATE_ODATA_SERV and the corresponding ICF nodes with the task list SAP_BASIS_ACTIVATE_ICF_NODES in transaction STC01.

In addition, the Spaces function must be activated generally (switch: SPACES) or user-enabled (switch: SPACES_ENABLE_USER) via transaction /UI2/FLP_CUS_CONF. With user-specific activation, users can activate or deactivate the Spaces and Pages themselves via the settings in the Fiori Launchpad.

  • Assign apps to the new Spaces and Pages:

The spaces are created and managed via the Fiori app F4834 ā€œManage launchpad spacesā€ (part of the SAP_FLP_ADMIN role), whereby a page can also be created directly in the course of creating spaces and the transport of the spaces (transport object: R3TR UISC) and pages (transport object: R3TR UIPC) can also be initiated.

The visibility of the page must be adjusted accordingly in the app so that it is also displayed in the Fiori Launchpad and can therefore also be edited to add corresponding Fiori apps from catalogs. Pages are managed via the Fiori app F4512 ā€œManage Launchpad pagesā€. You can specifically reassign apps to ensure better user guidance.

The created space must then be added to the role menu in the PFCG. Below is an overview of the tables in which the content is saved.

The Fiori app /UI2/FDM_GTP ā€œCreate launchpad pages from groupsā€ from SAP supports the transition from groups to spaces/pages.

Please note that this SAP standard app does not support mass processing.

  • Customization of roles: The existing user roles must be analysed and adjusted to ensure that each user has access to the spaces and pages relevant to them.

4. Testing, optimization & activation

We recommend that you first carry out the user-enabled activation in customizing to ensure acceptance. This allows the user to activate/de-activate the new view independently or “restore” the old view with the Fiori groups.

Make sure that:

  • The user guidance is intuitive and all required apps are easy to find.
  • Performance is optimized and there are no delays.
  • Roles and access rights are assigned correctly.

Important: ā€œMy Homeā€ from the old Fiori concept cannot be ā€œtaken alongā€ or transferred. When switching to the new Fiori spaces and pages concept, the homepage will be empty! This makes it even more crucial to prepare users in advance and provide them the opportunity to create a new homepage before enabling the general customization option. (switch: SPACES).

From Sap S/4HANA 2023 FPS01, SAP offers more flexibility regarding the homepage, e.g. there will then be a download and upload functionality.

5. User communication and training

To ensure that users accept the new structure well, you should inform them about the migration at an early stage. Training and tutorials help end users to quickly familiarize themselves with the new interface.

How does the technical migration from SAP Fiori groups to SAP Fiori spaces work as part of the Xiting service?

The migration process for the Xiting service package focuses on swiftly migrating all Fiori groups to Fiori spaces and pages in a 1:1 manner. Itā€™s important to note that this process does not involve the creation of a new structure; however, minor customer specifications can be accommodated. For any significant requirements, discussions must be held on a individual basis to determine any additional efforts. Catalog authorizations will remain unchanged.

  1. Preparation

a) As part of the preparation, the scope and which groups are to be migrated must be defined. The specification can be a list of technical group names or the technical PFCG role names. If the PFCG role names are specified, it is assumed that all groups in the respective roles are relevant.

b) In the next steps, the following information is extracted from the respective transactions and prepared practically:

  • Identification of the relevant apps for the groups via transaction /UI2/FLC:

The “Tile Reference ID” is relevant, but if not available, the “Tile or TM ID” is relevant

  • Identification of the relevant Tile IDs (aka Reference Tile IDs) and Target mapping IDs (aka Reference Target mapping IDs) via transaction /UI2/FLPCA

Important: The column headings may differ depending on the release.

c) In the last step of the preparation, the technical naming convention of the spaces, pages and sections must be defined. A simplified approach could be to define a new prefix for the existing group name, e.g. the group ZNWO_MYGROUP becomes the space Z_SP_ZNWO_MYGROUP, etc.

The short descriptions of the spaces and pages must also be defined. For mass processing in XAMS, it is also necessary to assign the technical names of the sections in order to carry out the assignment of the apps en masse. The section title is optional.

  1. Technical migration of the existing groups

The XAMS Role Replicator (/n/XITING/RR) for Fiori objects is used for the technical migration.

For mass processing, the various Excel files must be prepared and executed or uploaded in the following order:

  1. Creation of the spaces
  2. Creation of the pages
  3. Creation of the sections
  4. Assignment of the pages to the sections
  5. Assignment of the apps to the sections

In the last step, you must assign the created spaces to the respective PFCG roles. This is then done en masse via Excel upload using the ā€œRolesā€ tab in the Role Replicator:

  1. Validation & activation

In principle, no catalog authorizations are changed within the service. Therefore, authorization errors are not expected. Service validation mainly involves checking the view and usability in the Fiori Launchpad.

Before activation:

After activation:

As expected, the homepage is empty and as you can see in the figure below, the group has been migrated 1:1 to a Fiori area/page/section. This would be the standard within the migration service.

If you can work out clear specifications, it would be possible to follow these requirements for the structure, e.g. instead of creating a page with one section with 5 apps here, it would also be possible to create two pages and/or several sections. You can now make your own adjustments independently or request additional adjustments as part of the service. Depending on the scope of the requirements, however, additional efforts may be required.

Tips:

  • Inform users about the migration in good time and offer training.
  • First use the user-enabled customizing switch (switch: SPACES_ENABLE_USER) for activation. With user-enabled activation, users can activate or deactivate the new Fiori spaces and pages themselves via the settings in the Fiori Launchpad.
  • ā€¢Actively seek feedback from users after the migration to further improve the structure and range of functions.

Conclusion: Why you should switch to SAP Fiori spaces now

Migrating from SAP Fiori Groups to SAP Fiori spaces is not just a technical upgrade, it offers a much better user experience, greater efficiency and a future-proof structure for your SAP Fiori Launchpad. By moving from traditional grouping to a modernized spaces and page logic, you increase the productivity of your employees and ensure that your organization keeps pace with the latest SAP technologies.

Nicole Wolderling
Latest posts by Nicole Wolderling (see all)
Contact

Get in touch with us!

Do you have questions about our products?

+41 43 422 8803
[email protected]
+49 7656 8999 002
[email protected]
+1 855 594 84 64
[email protected]
+44 1454 838 785
[email protected]
Contact
Webinars

Attend our live webinars and learn more from our experts about SAP authorizations, XAMS, SAP IDM and many other topics in the context of SAP security.

Register now