Introduction

In 2013 SAP introduced its new user-interface model called Fiori. Herewith 25 Fiori applications were made available which represented the most used business transactions. Since then, the number of Fiori applications has increased exponentially and more and more companies have started using SAP Fiori applications for one or more processes.

In order to be able to use Fiori applications, there are certain requirements regarding the SAP system landscape. The most important requirement is that a front-end server is available from which the SAP Fiori applications can be called. The front-end server must be linked to the underlying backend system, for example a SAP ECC system, on which the actual business process takes place.

Until recently, the role of front-end server was fulfilled by including a SAP NetWeaver Gateway system in the SAP system landscape. However, since mid-2016 it has also been possible to consume SAP Fiori from the SAP Cloud Platform; the SAP Cloud Platform acts as a front-end server. In this blog, the pros and cons of the on-premise scenario versus the SAP Cloud scenario with regard to SAP Fiori will be discussed in more detail.

NB. Because the majority of companies use SAP Fiori applications for the SAP Business Suite, this blog is mainly based on this setup. However, for an S/4HANA scenario largely the same rules apply.

SAP NetWeaver Gateway Server

In the on-premise scenario, a SAP NetWeaver Gateway is required to call SAP Fiori applications. Files from which the SAP Fiori application is created are retrieved from the SAP NetWeaver Gateway. These files form the so-called user-interface (UI) of the SAP Fiori application and are based on SAPUI5.

In addition, SAP Fiori applications make use of the OData protocol to retrieve business data from the linked backend system. After all, without data a SAP Fiori application is an "empty shell"; the application must be connected to a backend system that provides it with data.

To call OData services in an on-premise scenario (see figure 1) a SAP NetWeaver Gateway system is required. It supports the so-called CRUD concept(Create, Read, Update, Delete) to provide the application with data, or to perform certain operations in the backend system. Think for example of creating a purchase order, or approving an invoice. When in a certain SAP Fiori application the "Approve" button is pressed, this approval is processed in the underlying backend system via an OData call. Every SAP Fiori application has an OData service, which can be registered on the SAP NetWeaver Gateway system. Without this Gateway registration, the OData service cannot be called from the Fiori application. The external OData call is converted to a SAP specific call, for example a method in an ABAP class.

Despite the fact that every SAP NetWeaver system from 7.0 or higher can in principle function as a SAP NetWeaver Gateway system, deploying a SAP NetWeaver Gateway system on-premise is an extra burden on the management of the system landscape. Think for example of the scenario for the approval of purchase orders. When this needs to be done by means of the standard SAP Fiori application, a new SAP NetWeaver Gateway system needs to be set up next to the available SAP ECC system for one relatively simple process/application.

If SAP Fiori is consumed from the Cloud, it is no longer necessary to set up an additional SAP NetWeaver Gateway system on-premise. There are now many standard SAP Fiori applications available on the SAP Cloud Platform. The role of the SAP NetWeaver Gateway system in making the user interface (UI) of the SAP Fiori application available can therefore be taken over by the SAP Cloud Platform. When using the cloud scenario, a SAP Cloud Connector must be installed. The SAP Cloud Connector provides the connection between the SAP Cloud Platform and the underlying SAP backend system.

The most commonly used standard SAP Fiori applications have been made available on the SAP Cloud Platform and this number is being expanded. In an on-premise scenario, therefore, more standard SAP Fiori applications are currently available than in the cloud scenario.

Besides consuming the UI from the SAP Cloud Platform, the OData services on the SAP backend still need to be registered so that they can be called from the SAP Fiori application. You can choose to have this registration take place on the on-premise Gateway system, which means that a SAP NetWeaver Gateway system is still required in addition to the SAP Cloud. However, now the on-premise Gateway is only meant for the registration of the OData services and no longer for the UI part. We speak here of a so-called hybrid solution (see figure 2).

For the use of SAP Fiori in the SAP Cloud a license fee has to be paid. If there is an additional Gateway server in the landscape, purely for registering OData services, this hybrid scenario would unnecessarily increase costs. Therefore we often see that in this scenario the SAP backend server fulfils the role of the Gateway for the registration of the OData services. For this the underlying backend system needs to be at least a SAP NetWeaver 7.0 system.

In addition to the hybrid scenario, a full cloud scenario can also be chosen (see Figure 3). In this case, in addition to consuming the user interface, registration of the OData services also takes place on the SAP Cloud Platform. This is done by means of the so-called OData Provisioning Service.

In this scenario only the OData service needs to be present on the on-premise SAP backend system, but no SAP NetWeaver Gateway system is needed anymore for the registration of the OData service. In this scenario the management costs of a SAP NetWeaver Gateway server will be eliminated. By means of registration via the OData provisioning service on the SAP Cloud Platform, OData calls are routed from the Fiori application to the relevant backend system where the OData service is available.

SAPUI5 version management

Important when using SAP Fiori applications is the available SAPUI5 version on the front-end server. The SAPUI5 version determines, among other things, how the SAP Fiori application behaves, which look & feel applies and whether certain user-interface (UI) elements can be used in the application. It is possible, for example, that a SAP Fiori application only runs from a certain SAPUI5 version. On the other hand, it may happen that used UI elements in a SAP Fiori application are no longer supported in a higher version of SAPUI5 or have been replaced by other elements. In addition, upgrades are also implemented with regard to security and new developments in the mobile sector need to be supported with new SAPUI5 versions. This makes it necessary to upgrade/ patch the SAPUI5 version to the latest available version on a regular basis.

The release cycles of SAPUI5 versions and patches differ significantly from the traditional release cycles for SAP software. Looking at the patches that are released for SAPUI5 versions, a new patch is available about every other month. For example for SAPUI5 version 1.44 the following patches have recently been released:

Version 1.44.45 - 02 May 2019
Version 1.44.44 - 11 March 2019
Version 1.44.43 - 12 February 2019
Version 1.44.42 - 30 November 2018
Version 1.44.41 - 25 October 2018
…..

Upgrading an on-premise system has a relatively large impact on the ICT landscape and costs time and money to implement. Think of making resources available, responding to support packages or executing the SPAU. All this impact expires in the cloud scenario where a new SAPUI5 version is simply made available on the SAP Cloud Platform. Upgrading to a higher SAPUI5 version on the SAP Cloud Platform does not involve much more than selecting a higher version in the configuration of, for example, the SAP Fiori Launchpad.

Upgrading the SAPUI5 version could possibly result in the standard SAP Fiori applications in use no longer working correctly. Looking at an on-premise scenario, this means that various SAP OSS notes or support packages/patches may have to be played in to get the SAP Fiori application working on a higher SAPUI5 version. This effort is also no longer required in a cloud scenario; the standard SAP Fiori applications available on the SAP Cloud Platform work on the SAPUI5 versions made available there. It could even be "cheated" whether all SAP Fiori applications work in a higher SAPUI5 version on the SAP Cloud Platform. This is not possible in an on-premise scenario, where only one version is available. When using the SAP UI Theme Designer to create your own themes, these need to be generated again when a new SAPUI5 version is installed. In an on-premise scenario this should be included as one of the activities in the upgrade. In a cloud scenario, own themes are automatically generated again as soon as a new SAPUI5 version is available.

As mentioned earlier, there are fewer standard SAP Fiori applications available in the cloud scenario (+1,100) compared to the on-premise scenario (+2,100), but this difference will gradually decrease. By the way, there is always the possibility to bring a standard Fiori application, which is only available on-premise, to the SAP Cloud Platform. This can be done simply by an on-premise download of the SAP Fiori application followed by an upload (or deploy from the SAP Web IDE) to the SAP Cloud Platform.

User/identity management

In an on-premise scenario the SAP users of the SAP backend system need to be replicated on the SAP NetWeaver Gateway system. This requires extra management work for the maintenance of employees within an organization. In the cloud scenario, no additional Gateway SAP users are needed anymore, but the users need to be created in a linked identity provider in the SAP Cloud Platform. When using SAP Fiori in the Cloud, SAP makes an identity provider available which can be used for this purpose. However, the SAP Fiori cloud scenario has been extensively prepared to make use of the already available identity provider within an organization. Think of an Active Directory or Miscrosoft Azure solution, where a user logs into the SAP Fiori Launchpad with his or her own email address and password which is also used elsewhere (for example when logging into the PC or email account). As a result, no extra SAP users need to be maintained and the organization's already available identity provider can be used.

Figure 5: Example user and identity management setup

As far as user/identity management is concerned, two streams can be distinguished: a data stream and an authentication stream. An authentication flow must be sent to the linked identity provider (in the figure below this is an Active Directory), after which the data can be retrieved from the linked SAP backend system. The user identified during authentication is sent along with the data stream to the SAP backend system.

Regardless of which identity provider is chosen in the cloud scenario, the corresponding SAP user ultimately needs to be logged into the SAP backend to, for example, execute the approval of a purchase order under the correct user in SAP. For this purpose the so-called "principal propagation" is used. With certificates a trust relationship is realized between the different components from the SAP Cloud Platform up to and including the SAP backend system. By means of so-called "SAML2 assertion" an attribute of the user on the identity provider linked to the SAP Cloud Platform is propagated to the SAP backend system. In the SAP backend system this attribute makes sure that the correct SAP user is logged in and performs the actions in the SAP backend system.

In order to achieve this, the following trust relationships have been set up by means of certificates:

Identity provider <-> SAP Cloud Platform
SAP Cloud Platform <-> SAP Cloud Connector
SAP Cloud Connector <-> SAP backend system

It goes without saying that such a set-up to realize this required principal propagation requires a certain multidisciplinary effort, which is not necessarily necessary in an on-premise scenario. The great advantage, however, is that users experience the convenience of single sign on (SSO) and can also use SAP Fiori with their regular user name and password within the company, without having to remember separate SAP user names and passwords. Of course, such an SSO set-up can also be realised in an on-premise scenario, but is not required and is therefore less common. In addition, the on-premise scenario is not prepared or pre-sorted in the same way for setting up a local identity provider as the cloud scenario is.

Report/Monitoring

When an on-premise scenario is used, various reporting and monitoring possibilities are offered in both the backend and front-end system. The advantage of this is that monitoring and logging can be called up at a central location, namely the SAP NetWeaver Gateway system. Possible errors in the backend system are also visible in the SAP NetWeaver Gateway.

Figure 6: Error log SAP NetWeaver Gateway

Looking at a cloud scenario, the reporting and monitoring capabilities are more dispersed across the different parts of the installation. Roughly speaking, these are divided into three parts:

SAP backend system
SAP Cloud Connector
SAP Cloud Platform

Reporting and monitoring on the SAP Cloud Platform and in the SAP Cloud Connector is not as extensive as when an on-premise scenario applies. In addition, the logging of errors, for example, is not centrally organized as is the case in an on-premise scenario. After all, the occurrence of an error can originate from one of the above three components, and it is therefore necessary to analyse what went wrong and why in several places.

Performance/geographically dispersed

If an on-premise SAP NetWeaver Gateway system is used in geographically dispersed locations, there may be a delay in loading SAPUI5 resources. The further away you are from the Gateway server, the more possible delay (so-called latency) occurs when loading the SAPUI5 resources.

This problem is addressed in the SAP Cloud Platform through the multiple SAP Cloud data center locations. See the figure below for a representation of the different locations where the services of the SAP Cloud Platform are hosted.

Figure 7 - SAP Cloud data center locations

The SAP Cloud services that are purchased with regard to SAP Fiori are SAP Fiori Cloud and (possibly) OData Provisioning. The table below shows which locations support these services on the SAP Cloud Platform.

Figure 8: SAP Fiori Cloud and OData Provisioning data center locations

Because the services on the SAP Cloud Platform are available all over the world, resources can be loaded from a server at a location closest to the applicant (is client).

In addition, a so-called Content Delivery Network (CDN) can also be used. Since 2015, SAPUI5 has also been made available on the SAP Cloud Platform via such a CDN, namely the Akamai CDN. The Akamai CDN routes requests to the nearest Akamai server, i.e. USA, Germany or Australia. The multiple SAP Cloud data center locations combined with the route optimization offered by the Akamai CDN will reduce any latency and speed up application loading.

Conclusion

Figure 9: Advantages and disadvantages Fiori on-premise versus Cloud

In summary, we can say that the SAP Cloud Platform is a very good alternative to an on-premise SAP NetWeaver Gateway system. Especially the flexibility in terms of upgrades, the plug & play experience for standard SAP Fiori applications and the performance optimization that is possible are advantages of the SAP Cloud Platform. On the other hand, the landscape for a cloud scenario will require more multi-disciplinary effort as an on-premise scenario. Also, there are currently more SAP Fiori apps available for the on-premise scenario than for the cloud scenario. However, the latter can be done by downloading and uploading the application to the SAP Cloud Platform.

Attached is a list of all the pros and cons mentioned in this blog.

For further questions or information on this subject, please contact Joost van Poppel. For other questions regarding SAP Workflow, Fiori, SAP Invoice Management (SIM) or SAP Master Data Governance (MDG) please contact Sander van der Wijngaart.

Fiori on-premise versus Fiori Cloud