SAP Cloud Platform Central Launchpad

Since the introduction of SAP Fiori in 2013, the SAP Fiori Launchpad is increasingly positioned as the single-point-of-entry for SAP users. The SAP Fiori Launchpad is the starting point for SAP Fiori apps for both desktop and mobile devices. The SAP Fiori Launchpad displays a start page with so-called tiles positioned on it. Each tile represents an application which the user can start by clicking on the tile.

The applications that can be started in the SAP Fiori Launchpad are in most cases SAP Fiori applications. In order to use the SAP Fiori Launchpad and Fiori applications, there are certain requirements regarding the SAP system landscape. One of the most important conditions is that a so-called front-end server must be available, from where the SAP Fiori Launchpad and applications can be called. In an on-premise landscape, the role of front-end server is fulfilled by a SAP NetWeaver Gateway system. Since 2016 it is also possible to consume SAP Fiori from the SAP Cloud Platform via the SAP Fiori Cloud Edition. The SAP Cloud Platform takes over the front-end server role from the SAP NetWeaver Gateway system. For more information see the blog "Fiori on-premise versus fiori cloud".

In Q4 2020 a new option will be added for setting up a SAP Fiori Launchpad, namely the SAP Cloud Platform Launchpad. In this blog we will discuss this new functionality and why it has been introduced.

Embedded versus hub deployment

In both the on-premise and the cloud variant, the underlying SAP backend systems are linked to the front-end server, while in the cloud variant, the SAP Cloud Platform itself acts as the front-end server.

In the on-premise scenario, an embedded or hub deployment of the front-end server can be chosen. If the underlying SAP backend system also functions as SAP NetWeaver Gateway system or front-end server, we speak of embedded deployment.

When a SAP NetWeaver Gateway system is placed in the SAP system landscape that acts purely as a front-end server towards one or more linked backend systems, we speak of hub deployment.

In the set-up of the cloud scenario, there is always a hub deployment scenario; the SAP Cloud Platform fulfils the role of front-end server and is linked via the SAP Cloud Connector to one or more SAP backend systems.

If there is a system landscape with multiple SAP backend systems, the hub deployment variant has advantages over the embedded deployment. One of the most important advantages is that only one SAP Fiori Launchpad needs to be set up for all underlying systems. This means that the end user only needs one application - the SAP Fiori Launchpad - to access all underlying backend systems.

S/4HANA 1809

With the introduction of S/4HANA 1809 there have been some changes in the requirements of the system landscape regarding the front-end server. As a result, there are two major limitations to the hub deployment variant:

As of version S/4HANA 1809, standard SAP Fiori applications will no longer be delivered via the SAP Fiori Cloud Edition. In other words, the SAP Fiori Cloud Edition can be used up to and including S/4HANA 1709.
In the on-premise scenario from S/4HANA 1809 it is recommended to choose the embedded deployment variant. Hub deployment is still possible from S/4HANA 1809, but in this scenario the SAP NetWeaver Gateway should be kept exactly the same as the underlying SAP S/4HANA system in terms of support packages and patches.

The above two points obviously present quite a few challenges. If the SAP Fiori Cloud Edition is used and the SAP backend landscape is upgraded to S/4HANA 1809 or higher, it is suddenly no longer possible to use SAP Fiori Cloud for standard SAP Fiori apps. This is also clear in the SAP Fiori app libray:

Not only in the cloud scenario, but also in an on-premise scenario, with the introduction of S/4HANA 1809 or higher the hub deployment variant becomes increasingly difficult and in some cases even impossible. The requirement that front-end and backend must be the same in terms of S/4HANA release implies that an upgrade of the backend system must be carried out simultaneously with an upgrade of the front-end system. In the case of a system landscape with multiple S/4HANA backend systems, this becomes an increasing challenge. For example, upgrading multiple backend systems exactly at the same time in combination with the front-end server puts enormous pressure on system and application management within companies' IT organisations. If there is a system landscape with multiple S/4HANA backend systems containing different S/4HANA releases, hub deployment is not possible at all! By way of illustration: the latest version of the front-end server (SAP FES 2020) is expected in Q1 2021. This version of the front-end server is required for release S/4HANA 2020, and also works for releases S/4HANA 1809 and S/4HANA 1909. However, this version of the front-end server is not suitable for SAP ECC Business Suite systems or S/4HANA releases up to and including 1709.

For the above reasons, it is therefore recommended to move towards an embedded deployment variant as far as the front-end server is concerned. If there is only one backend system in the landscape, this will not cause any problems. The challenge comes when multiple backend systems exist in the landscape, or when using the SAP Fiori Cloud Edition. The biggest advantage of hub deployment disappears when embedded deployment is chosen, namely a "single point of access" for the end user in the form of in SAP Fiori Launchpad.

To compensate for this loss, it is advised to designate one SAP system as a central front-end server, on which a SAP Fiori Launchpad is installed. This designated Fiori Launchpad should then include tiles, which refer to the system-specific local SAP Fiori Launchpads via URL integration (see figure).

This setup with a central SAP Fiori Launchpad on a designated central front-end server solves the previously mentioned problems that various S/4 HANA releases entail. However, it introduces yet another new problem and that is significant deterioration in user experience (UX). One opens a central Fiori Launchpad, which contains tiles that represent the underlying S/4HANA systems. Clicking on one of these tiles opens a new SAP Fiori Launchpad for the S/4HANA system in question, containing tiles for applications in that system. This is not a scenario you want to present to end users; navigating from launchpad to launchpad to eventually open an application. Ideally, all applications should be presented in one central launchpad, as was the case with the hub deployment variant. The SAP Cloud Platform Launchpad was introduced for this purpose.

SAP Cloud Platform Launchpad

The SAP Cloud Platform Launchpad offers the possibility to link multiple S/4HANA releases to one central Launchpad. In addition, SAP ECC Business Suite systems, S/4HANA Cloud systems, enterprise portals, SAP Cloud Platform applications, custom or 3rd party applications can also be linked to this central launchpad.

The SAP Cloud Platform Launchpad is rolled out via the Cloud Foundry environment of the SAP Cloud Platform. One of the most important features of this new lauchpad is the so-called content federation. The SAP Cloud Platform Launchpad can include applications such as Fiori apps in the configuration, while these applications (or content) are not located on the Cloud Platform but in an on-premise S/4HANA backend system. An S/4HANA backend system can be set up in the embedded deployment variant, where the SAP Cloud Platform Launchpad approaches the specific apps in the S/4HANA backend system by means of tiles on the launchpad on the SAP Cloud Platform.

The calling and recording of so-called remote content was not possible before the introduction of the SAP Cloud Platform Launchpad. In the SAP Fiori Cloud Edition, Fiori apps could only be included in the Launchpad if they were also physically located on the SAP Cloud Platform. The same still applies to an on-premise scenario. When setting up a SAP Fiori Launchpad on a front-end server, Fiori applications need to be on the same front-end server to be included as a tile in this SAP Fiori Launchpad.

Through this content federation, the SAP Cloud Platform Launchpad can be set up with multiple S/4HANA backend systems, without the requirement that they all have the same S/4HANA release.

Content federation and Common Data Model

The SAP Cloud Platform Launchpad can therefore call Fiori and other applications that are physically located on the linked S/4HANA backend systems: also called content federation. Content in the form of apps is included in the design of the launchpad and it can be indicated whether it is located on a backend system.

For recent S/4HANA releases running on a front-end server version 2020, it is also possible to make content available to the SAP Cloud Platform in a prefabricated format from the backend using a so-called common data model (CDM). This is done by including functionality in the S/4HANA backend system via roles through a dedicated transaction.

In the configuration of the SAP Cloud Platform Launchpad, the provided content can then be selected as a role and assigned to the relevant launchpad site and users.

Because of this set-up, a central launch path can be configured in the SAP Cloud Platform, to which multiple backend systems can be linked without interfering with the user experience. Each S/4HANA system can be managed separately and any upgrades can be performed independently of the other systems. The end user experiences consistent functionality in the launchpad for different applications, no matter from which backend system or cloud environment this application is consumed.

If non-SAP systems need to be connected to the SAP Cloud Platform Launchpad, the same content data model (CDM) can be used as for S/4HANA releases. If the content is made available through CDM, content from non-SAP systems can also be selected directly in the configuration of the SAP Cloud Platform Launchpad.

More information

For questions or information about the application possibilities of SAP Fiori within your organization or for questions regarding SAP Workflow, SAP Invoice Management (SIM) or SAP Master Data Governance (MDG), please contact Victor van den Hazelkamp.