Introduction

In 2013, SAP introduced its new user-interface model called Fiori. 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 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 where the SAP Fiori applications can be called. The front-end server needs to be linked to the underlying back-end system, for example an SAP ECC system, on which the actual business process takes place.

Until recently, the role of front-end server was fulfilled by including an SAP NetWeaver Gateway system in the SAP system landscape. However, since mid-2016 it is also possible to consume SAP Fiori from the SAP Cloud Platform; the SAP Cloud Platform serves as front-end server. In this blog, the advantages and disadvantages of the on-premise scenario versus the SAP Cloud scenario with regard to SAP Fiori are discussed in 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 a S/4 HANA scenario, largely the same rules apply.

SAP Netweaver Gateway Server

In the on-premise scenario, an SAP NetWeaver Gateway is required to call SAP Fiori applications. Here, the necessary files 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 use the OData protocol to call 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 back-end system that feeds it with data.

 Figure 1: On premise scenario

Figure 1: On premise scenario

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 actions in the back-end system. Consider, for example, the creation of a purchase order, or the approval of an invoice. When in a certain SAP Fiori application the "Approve" button is pressed, this approval is processed via an OData call in the underlying backend system. 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 can not be called from the Fiori application. The external OData call is converted to a SAP-specific call via registration, for example a method in an ABAP class.

Although every SAP NetWeaver system can function as an SAP NetWeaver Gateway system from 7.0 or higher, the deployment of an SAP NetWeaver Gateway system on-premise is an additional burden on the management of the system landscape. Consider, for example, the scenario for approving purchase orders. If this has to be done through the standard SAP Fiori application, a new SAP NetWeaver Gateway system must be set up for one relatively simple process / application in addition to the available SAP ECC system.

If SAP Fiori is consumed from the Cloud, the need to set up an additional SAP NetWeaver Gateway system on-premise is no longer necessary. Many standard SAP Fiori applications have now been made available on the SAP Cloud Platform. The role that the SAP NetWeaver Gateway system fulfills for 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, an SAP Cloud Connector must be installed. The SAP Cloud Connector provides the connection between the SAP Cloud Platform and the underlying SAP back-end system.

 Figure 2: Hybride scenario

Figure 2: Hybride scenario

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

In addition to consuming the UI from the SAP Cloud Platform, the OData services on the SAP backend still have to be registered so that they can be called from the SAP Fiori application. It is possible to opt for this registration to take place on the on-premise Gateway system, so that in addition to the SAP Cloud, an SAP NetWeaver Gateway system is still required. However, the on-premise Gateway is now only intended for the registration of the OData services and no longer for the UI section. We here peak of a so-called hybrid solution (see figure 2).

Licensing costs must be paid for the use of SAP Fiori in the SAP Cloud. If there is an additional Gateway server in the landscape, purely for the registration of the OData services, this hybrid scenario would entail an unnecessary increase in costs. We therefore often see that in this scenario the SAP backend server fulfills the role of the Gateway for registering the OData services. For this the backend system must be at least an SAP NetWeaver 7.0 system.

 Figure 3: Cloud scenario

Figure 3: Cloud scenario

In addition to the hybrid scenario, a complete cloud scenario can also be chosen (see figure 3). In addition to consuming the user interface, the registration of the OData services takes place on the SAP Cloud Platform. This is done through 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 for the registration of the OData service. In this scenario, therefore, the management costs of an SAP NetWeaver Gateway server expire. By means of registration via the OData provisioning service on the SAP Cloud Platform, OData calls from the Fiori application are routed to the relevant back-end system where the OData service is available.

SAPUI5 Version management

When using SAP Fiori applications, the available SAPUI5 version on the front-end server is important. The SAPUI5 version determines, among other things, how the SAP Fiori application behaves, which look & feel is applicable and whether certain user-interface (UI) elements can be used in the application. For example, it can be that an SAP Fiori application only runs from a specific SAPUI5 version. On the other hand, it is possible that used UI elements in an SAP Fiori application in a higher version of SAPUI5 are no longer supported or have been replaced by other elements. In addition, upgrades that also being made with regard to security and new developments in the mobile sector must be supported through new SAPUI5 versions. This makes it necessary to upgrade / patch the SAPUI5 version with some regularity to the latest available version.

 Figure 4: Available SAP UI5 versions

Figure 4: Available SAP UI5 versions

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

  • Version 1.44.35 - April 26th 2018
  • Version 1.44.34 - March 29th 2018
  • Version 1.44.33 - March 13th 2018
  • Version 1.44.32 - March 1st 2018
  • Version 1.44.30 - February 19th 2018
  • Version 1.44.29 - January 22nd 2018

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

Upgrading the SAPUI5 version could possibly lead to the default SAP Fiori applications 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 used to get the SAP Fiori application working on a higher SAPUI5 version. This effort is no longer needed in a cloud scenario; the standard SAP Fiori applications available on the SAP Cloud Platform work on the SAPUI5 versions available there. It could even be "spotted" 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 their own themes, these must be regenerated 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 regenerated as soon as a new SAPUI5 version is available.

As mentioned earlier, fewer standard SAP Fiori applications are available in the cloud scenario (+500) compared to the on-premise scenario (+1.700), but this difference will gradually become less and less. Incidentally, 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 means of an on-premise download of the SAP Fiori application followed by an upload (or deployment from the SAP Web IDE) to the SAP Cloud Platform.

User-/ identity management

In an on-premise scenario, the SAP users of the SAP back-end system must be replicated on the SAP NetWeaver Gateway system. This therefore requires extra management work for the maintenance of employees within an organization. In the cloud scenario, no additional Gateway SAP users are needed, but the users need to be created in a connected identity provider in the SAP Cloud Platform. When SAP Fiori is used in the Cloud, SAP provides an identity provider that can be used for this purpose. However, the SAP Fiori cloud scenario is very well prepared to use the already available identity provider within an organization. Think of an Active Directory or Microsoft Azure solution, where a user for the SAP Fiori Launchpad logs in with his or her own e-mail address and password which is also used elsewhere (for example when logging in to the PC or e-mail account). This means that no additional SAP users need to be maintained and the already available identity provider of the organization can be used.

Voorbeeld+opzet+user-+en+identity+management (1).jpg

As far as user / identity management is concerned, two streams can be distinguished; a data stream and an authentication stream. It must be authenticated towards 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 established with the authentication is sent along with the data flow towards the SAP backend system.

Regardless which identity provider is chosen in the cloud scenario, the corresponding SAP user ultimately has to be logged into the SAP backend, for example to perform the approval of a purchase order under the right user in SAP. For this purpose use is made of the so-called "principal propagation". A trust relationship is realized with certificates between the various 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" towards the SAP backend system. In the SAP back-end system, this attribute ensures that the correct SAP user is logged in and takes action in the SAP back-end system.

To realize this, the following trust relations have been set up through certificates:

  1. Identity provider <-> SAP Cloud Platform
  2. SAP Cloud Platform <-> SAP Cloud Connector
  3. 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 necessary in an on-premise scenario. The big advantage, however, is that users experience the convenience of single sign on (SSO) : with their regular username and password within the company they can also use SAP Fiori, without having to remember separate SAP user names and passwords. Of course, such an SSO design can also be realized in an on-premise scenario, but is not required and is therefore less common. In addition, the on-premise scenario is not prepared in the same way or preconfigured on setting up a local identity provider such as the cloud scenario.

Reporting / Monitoring

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

 Figure 6: Error log SAP NetWeaver Gateway

Figure 6: Error log SAP NetWeaver Gateway

Looking at a cloud scenario, the reporting and monitoring options are more spread over the different parts of the installation. Roughly these are divided into three parts:

  1. SAP backend system
  2. SAP Cloud Connector
  3. SAP Cloud Platform

The 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, for example, errors is not centrally organized, so that is applicable in an on-premise scenario. After all, the occurrence of an error can originate in one of the above-mentioned three parts, and it must therefore be analyzed in several places what went wrong and why.

Performance / geographically distributed

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

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

 Figure 7: SAP Cloud Data Center Locations

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

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

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

In addition, you can also make use of a so-called Content Delivery Network (CDN). Since 2015 SAPUI5 on the SAP Cloud Platform has also been made available via such a CDN, namely the Akamai CDN. The Akamai CDN routes requests to the nearest Akamai server, namely US, Germany or Australia. The multiple SAP Cloud data center locations combined with the route optimization provided by the Akamai CDN will ensure that any delay (latency) is reduced and the application is loaded faster.

Conclusion

 Figure : Pros and cons Fiori on-premise versus Cloud

Figure : Pros and cons Fiori on-premise versus Cloud

In summary, we can say that the SAP Cloud Platform is a very good alternative for an on-premise SAP NetWeaver Gateway system. In particular the flexibility in the field of upgrades, the plug & play experience for standard SAP Fiori applications and the performance optimization that is possible are advantages that the SAP Cloud Platform entails. On the other hand, the landscape for a cloud scenario will require more multidisciplinary effort as an on-premise scenario. There are currently more SAP Fiori apps available for the on-premise scenario than for the cloud scenario. However, the latter can be overcome through a down- and upload of the application to the SAP Cloud Platform.

Enclosed is a list of all advantages and disadvantages mentioned in this blog.

 

 

Thanks to Joost van Poppel for writing this article.

For questions in the area of AP Workflow, Fiori, SAP Invoice Management (SIM) or SAP Master Data Governance (MDG), please contact Wouter Van Peteghem.