The system landscape for SAP Fiori consists mainly of a Front-End Server (FES) and a Back-End Server (BES). These are system roles of an Application Server (AS) ABAP or ABAP Platform in this landscape. The back-end server is an SAP Business Suite or an SAP S/4HANA holding applications and data of any area based on an AS ABAP 7.40 or higher. The front-end server is a basic AS ABAP 7.40 or higher without any business products installed. Both systems can run on any database.
Note
Although the SAP Fiori launchpad (FLP) running in any client is able to communicate with the FES directly, it is recommended to use an SAP Web Dispatcher or another reverse proxy between FLP and FES in external facing scenarios and also internally. The reason is that for some features of the FLP multiple systems must be reached, which is forbidden in web communication with good reason. A reverse proxy offers a single point of communication holding routing rules to forward requests to the correct target systems.
In some scenarios, it is not necessary to operate separated front-end and back-end servers. It can even be counterproductive to do so. Therefore, you can deploy all components of SAP Fiori in one system, in an embedded deployment.
| Embedded Deployment | Central Hub Deployment |
|---|---|
| The tasks of the FES for providing SAP Fiori are embedded in the BES. There is only one system. | The FES and BES are two separated systems splitting the tasks in providing SAP Fiori. |
SAP Gateway, the only component in FES and BES, is the only part where you have to check carefully, which settings are in which system. As soon as there are multiple systems that want to provide SAP Fiori apps, the FES has many benefits in organizational and security terms.
Note
The SAP Fiori system landscape for a BES on any database supports transactional apps based on SAPUI5 and classic apps based on Web Dynpro and ABAP transactions. Mandatory components of the FES are the SAP Gateway for OData communication, the central UI for general SAP Fiori functions, and product UIs for the apps. The SAP Gateway and ABAP code for the business logic of the apps are in the BES.
To use any SAP Fiori app, a running FLP is needed. The FLP is part of the central UI including all views, functions, and tools for personalization, customizing, and configuration of the contents. When thinking about personalization, this is performed by the user in a running FLP. Therefore, the FLP must read and write data from and to the FES using OData, not only for personalization, but also in other areas.
There is no communication to the BES by the FLP. All general settings for SAP Fiori are saved in the FES to be independent from the BES. Although this is not visible in the diagram, having multiple back ends is usual for many customers. Having only one place (system) for SAP Fiori settings is a huge benefit.
Disregarding the need for a running FLP, transactional apps consist of SAPUI5 apps and SAP Gateway services. SAPUI5 apps are saved in the ABAP repository as BSPs and delivered using product-specific UI add-ons. These are installed on the FES. The SAP Gateway services are delivered as part of updates of the BES solution and are written in ABAP.
The registration of the Gateway services is performed on the FES by the customer. So, when transactional apps need data, an OData request is performed via the SAP Web Dispatcher to the registration of the Gateway service on the FES. From there, the SAP Gateway framework creates an RFC request to the implementation of the SAP Gateway service on the BES. In the implementation, ABAP code is used to access the data in the database.
Classic applications are part of the BES solution and have no interaction with the FES besides the FLP itself. The UI and data directly originate from the ABAP code on the BES. The only task of the FES is to provide the connection information to the BES when a navigation request — such as clicking a tile — is initiated in the FLP. This connection information must be set in the FES by an administrator.
