In this blog post, we’ll go over the different SAP Fiori deployment options for SAP S/4HANA and SAP Business Suite systems, and emphasize recommended deployment options, the pros and cons of each, and so on.
We’ll start with on-premise, followed by cloud deployment.
On-Premise Deployment
For SAP Fiori on-premise, there are two deployment options:
- Central hub
- Embedded
In both cases, business data is consumed from an on-premise SAP system. The difference is in the location of SAP Fiori UI components: with the central hub option, the SAP Fiori components are deployed on a separate (SAP Gateway) server, while for the embedded option, they reside on the same server.
Central Hub
In the beginning, when SAP Fiori was introduced, the central hub was the only deployment option. A separate SAP Gateway installation was required to expose SAP Business Suite data to the SAP Fiori UI using OData. Nowadays, this limitation for SAP Business Suite systems doesn’t exist anymore, but the deployment option is still recommended for the SAP Business Suite backend (see figure below).
It can also be used for SAP S/4HANA in a single system scenario, although the recommended approach is to use embedded deployment. There are specific use cases where there can be exceptions to this rule—for example, if you have a requirement to have backend and frontend server systems in separate network zones, to protect the backend system from exposure on the internet. However, this brings some complexity, which we’ll cover at the end of this section, when we go through the list of advantages and disadvantages of central hub deployment.
The real advantage of the central hub deployment option is in scenarios in which you have multiple backend systems and want to use the central hub as a central entry point through which you’ll expose the SAP Fiori UI.
The first use case is a scenario with multiple backend SAP Business Suite systems, as shown in this figure.
Because the SAP Fiori UI components of SAP Business Suite systems are compatible with multiple backend versions, it’s possible to connect backend systems on different release versions to a central SAP Fiori frontend server. It’s also important to mention here that the SAP Fiori frontend server can run on any database.
The next use case covers scenarios in which you have a single SAP S/4HANA system together with one or more SAP Business Suite systems, as shown below.
Because you’re using a single SAP Fiori frontend server to expose content from both the SAP S/4HANA and SAP Business Suite backend systems, the SAP Fiori frontend server has to be on the exact release that corresponds to the SAP S/4HANA product. More details are presented in the second table below.
The recommended, but not mandatory, database system for the frontend server in this scenario is SAP HANA.
Now, let’s expand the previous scenario with an additional SAP S/4HANA system. It will look as shown.
As a consequence, there will be an additional SAP Fiori launchpad for every additional SAP S/4HANA system. The way to connect the central SAP Fiori launchpad with local SAP S/4HANA launchpads is to introduce a URL tile, which in turn would launch the local launchpad of the dedicated application in the target system. This is not the common scenario, and it’s mostly used in complex landscapes in which SAP Business Suite systems are being upgraded to SAP S/4HANA.
The major restriction of this approach is related to UI integration capabilities due to multiple launchpads.
To overcome the limitations of this scenario, you should consider using SAP Launchpad service on SAP BTP.
Finally, let’s consider a scenario with multiple SAP S/4HANA systems, as shown in the next figure.
For this specific scenario, the recommended approach is to use the embedded deployment option (covered later in this section). However, if you still want to use a central SAP Fiori launchpad, this can be implemented via an SAP Fiori frontend server with custom tiles that will launch the local launchpads via URL integration in a separate browser window. As SAP S/4HANA systems that are involved in this scenario are potentially on different versions, only release-independent UIs such as the My Inbox app or custom apps can be deployed centrally.
The same limitations that apply for UI integration capabilities are present here as well, and the same recommendation is applicable as well: consider using SAP Launchpad service on SAP BTP.
Now that we’ve gone through the different scenarios for the central hub deployment option, let’s summarize advantages and disadvantages of this approach.
As mentioned previously, when implementing a standalone frontend server for one or more backend SAP S/4HANA systems, the frontend server has to be on a supported version for the specific SAP S/4HANA release, as detailed here.
These dependencies are also valid for embedded implementation.
Embedded
In embedded scenarios, the SAP frontend server and backend are integrated into one system. Although this configuration brings advantages such as reduced total cost of ownership (TCO) and direct access to structures and business logic, there are some considerations to take into account, such as dependency between versions of the SAP frontend server and backend component versions, the component lifecycles, and so on. At the end of this section, we’ll go through the list of advantages and disadvantages of the embedded scenario.
The embedded scenario is the recommended setup for single and multiple SAP S/4HANA system deployments, but it can be used for SAP Business Suite applications as well. The figure below shows one example of an embedded scenario for a single system.
A scenario with multiple SAP S/4HANA systems would look as shown here.
The major advantages and disadvantages of the embedded scenario are listed in the following table.
SAP Fiori Launchpad Content
Central Launchpad on SAP Business Technology Platform
You can expect that modern, complex landscapes will consist of multiple on-premise and/or cloud systems. For example, the landscape can contain SAP S/4HANA systems and SAP software-as-a-service (SaaS) solutions (SAP SuccessFactors, SAP Ariba, etc.), but also custom-built applications and extensions running in SAP BTP. This landscape needs one central entry point, which due to the hybrid landscape has to be deployed in SAP BTP. To help organizations address this challenge, SAP provides the SAP Launchpad service on SAP BTP (see below). It is currently available in multiple regions, on Amazon Web Services (AWS) and Microsoft Azure infrastructure, and also available via Alibaba in China.
From an operations perspective, the underlying systems still have their own software lifecycle, authorization management, and business content. While each system still has its own launchpad, the SAP Launchpad service enables business users to have one central place where they can access all their applications, without having to switch between the multiple backend systems.
There are two approaches to integrating applications into the central SAP Fiori launchpad:
- Manual integration using templates for common UI technologies, like SAPUI5, Web Dynpro, SAPGUI for HTML, and so on. It’s also possible to integrate web applications using a generic URL launcher. Applications integrated using this approach can be configured to open in place or in a new tab.
- Content federation using SAP products as common data model (CDM)–compliant content providers, exposing business content via roles, applications, and related metadata.
The table below shows some examples of applications that can be integrated using the manual integration or content federation approach.
The SAP Launchpad service is configured using Site Manager tools:
- Site Directory: Manage the sites in an SAP BTP subaccount.
- Content Manager: Manage business content in an SAP BTP subaccount. The integration can be done, as already said, using a manual integration or content federation approach. Business content can be used in any site that belongs to the same SAP BTP subaccount.
- Provider Manager: Manage content providers.
- Settings: Manage settings such as for the error log, notifications, alias mapping, and so on. Here you’ll also find an option to migrate SAP Fiori launchpad sites from a Neo to a Cloud Foundry environment.
Note that more information and the latest documentation about SAP Launchpad service can be found at http://s-prs.co/v544905.
Editor’s note: This post has been adapted from a section of the SAP Fiori: Implementation and Development by Souvik Roy, Aleksandar Debelic, and Gairik Acharya.
Comments