SAP FIORI Launchpad Architecture

What Fiori is

SAP Fiori is basically designed to focus on the most common and critical activities such as:

Role-based – what does this mean? It means explicitly designed to break down complex applications into a task-based experience with one central entry point for each user.

Responsive: It adapts to all sizes, devices, versions, and channels to provide a common user experience across all channels.

 Simple: SAP Fiori apps follow what we call the 1-1-3 rule – 1 user, 1 scenario, 3 screens.

Coherent: a user experience with apps that speak the same design language.

Delightful, or instant value – what do we mean by that?

It makes an emotional connection. It allows you to access the most recent version of your backend data via OData services.

All UIs are built using HTML5 and SAPUI5. Now that we have an idea about what is behind Fiori launchpad, we’ll go to the architecture.

The most important thing for us when we look at or want to try to troubleshoot any Fiori issues is we want to understand what kind of architecture we are dealing with.

For example, in Fiori you would have a client that is running on a mobile device or laptop, and you will get a Web-based application that is served from a back-end server, you will have a front-end server that is running SAP Gateway, and you may possibly have a mobile platform in the front as a reverse proxy to deal with mobile devices.

And in your back end, where your data is located, you may have S/4HANA. But in our architecture, in the front, we also have something called the SAP Web dispatcher.

Why do we need the Web dispatcher? Because we need to connect to a different back end that is not the original host of the server.

What does this mean? Imagine you are talking to domain 1 and you want to access data from domain 2.

That is not allowed by the browser – we call this CORS, Cross-Origin Resource Sharing. So to overcome this issue, we use the Web dispatcher.

Deployment Options:

Gateway Central Hub Deployment:

For example, we have the Gateway central hub deployment. What does this mean?

It means that in the front you will have an SAP gateway running the UI5 library, and you have a back-end S/4HANA.

The front end talks to the back end by using an RFC connection, and that way, if there is a product issue, for example, in the library, in the UI5, you will upgrade the library on the front-end server, and you don’t need to touch the back-end server. That’s the beauty of that.

Embedded System Deployment:

With that system, you will have one node, one host – everything running on that node. We call that the embedded system.

Development Central Hub System Deployment:

It offers the same advantages as the central hub. The only difference here is that the services are developed on the front end.

Components Required for Central Hub System:

components needs to be deploy on the front end and the back end :

For example, the components that are required for the central hub deployment on the front end…

* if you are running less than SAP Gateway 7.40, then you need to have what we call GW_CORE and IW_FND
* And on the back end, you need to have IW_BEP. And the SAPUI5 library that you’ll have is 1.28 or higher.
* Now, if you’re running 7.40 or higher, we made it simpler for you. We put everything in one component and that is called SAP_GWFND, and that resides on the front end and on the back end as well.

Components Required for Embedded System:

In the embedded system, they’re constant – they all run on one node. And in that case, you will have the same thing as we said.

If you’re running less than 7.40, then you need all three components running on the same node. But if you’re running higher than or equal to 7.40, then you need SAP_GWFND.

Now that we’ve understood what Fiori and the architecture are, and we know the deployment options that we have.

SAP FIORI Launchpad Building Blocks:

SAP Fiori launchpad is based on the unified shell architecture.

The guiding principle of the unified shell is to have a single platform-independent client-side runtime environment which can be hosted on different server platforms – for example, SAP Gateway or SAP Cloud Platform.

This means that the shell offers unified services with platform-independent interfaces to the hosted apps and shell components. The implementation of these services can utilize different service adapters for the respective platform if they need platform-specific behavior. The visualization of this shell is independent of the shell services.

This is achieved by using a shell renderer that can be replaced by a different implementation. Now, we’ll continue with the building blocks

The apps are embedded in an “application container“. As this is an independent re-use component, the embedding aspect is decoupled from the renderer. The application container can host SAPUI5 components, Web Dynpro ABAP applications, and SAP GUI for HTML transactions.

The shell services and renderers are managed by the central shell container.

It utilizes a runtime configuration which defines the concrete implementations for services, adapters, and shell renderers, as well as global settings like theme, language, system and user data.

The runtime configuration is fed by the following settings:

static configuration settings in the hosting HTML page; dynamic configuration data read from the front-end server during startup and dynamic settings passed as query parameters in the URL. Finally, all described JavaScript components are embedded into a single HTML page.

The SAP Fiori launchpad implementation of the SAP Gateway front-end server contains a standard page called FioriLaunchpad.html. http://bit.ly/2uu9fkG #SAP #SAPCloud #AI