Improving SAP Fiori Performance with Amazon CloudFront and AWS Global Accelerator

Introduction

SAP customers with global operations are generally interested in enabling their entire workforce access SAP applications at any time, from any device, and from anywhere. Access at any time is easy to achieve, by making the services to be accessed, available around the clock. Access from any device is a key feature of SAP Fiori, with SAPUI5 capabilities. However, access from anywhere is where the complexity lies, and customers need to consider organizational security policies, performance requirements, existing network connectivity (including its bandwidth and latency characteristics) from branch locations, users mobility, and other considerations.

In this blog, I will consider a scenario where a customer is running their SAP workloads on AWS and is interested in providing direct access to SAP applications without significant investments in dedicated network connectivity.

I will discuss options to address performance challenges for globally accessible SAP Fiori workloads on AWS, and highlight the potential improvements that can be achieved.

Background

SAP Fiori is the User Interface component of SAP applications such as S/4HANA, BW/4HANA, etc. It is based on SAP’s own HTML5 implementation called SAPUI5, and OData API Calls for its dynamic content. SAP Fiori relies on the HTTP protocol and modern web browsers as the client. Due to the nature of HTML5, it runs in nearly any user devices that supports modern browsers such as mobile phones, tablets and laptops. With this capability, many SAP customers are deploying SAP Fiori to be internet facing with the flexibility to support any connectivity for the end-users globally, including connection types such as over 3G, 4G, 5G, or Wi-Fi.

There are a number of performance challenges when deploying SAP Fiori for end-users over the Internet. The challenges can be due to poor latency, limited bandwidth and stability in-between user and SAP Fiori, as well as the size of the components such as JavaScript, stylesheets, images and data that need to be transferred.

To address the standard SAPUI5 components performance, SAP provided guidance in SAP Note 2526542 (an SAP S-User id is required to access) “How to load SAPUI5 files from CDN for performance improvements in Fiori and Standalone UI5 apps”. The applicability of this SAP note is well described by Mario De Felipe in his blog on leveraging CloudFront as the Content Delivery Network (CDN). However this SAP note and blog will not address the performance of Custom UI5 apps, and Fiori OData API calls. The potential solutions that we discuss below will address these gaps.

Potential Solutions

 To address these challenges on AWS, you have a couple of options that can be considered:

 1. Amazon CloudFront.

Amazon CloudFront is a content delivery network that delivers both static (e.g. images, files, videos) and dynamic content (e.g. dynamic site delivery, API calls and web sockets) with high availability, performance and security to viewers. It operates at the layer 7 of the Open Systems Interconnection (OSI) layer and supports the HTTP and HTTPS protocols. It delivers performance improvements by performing a quick TLS handshake with the nearest edge location, by caching objects at the edge and regional location, utilizing performance optimizations such as HTTP2, persistent connections and connections reuse, leveraging the AWS network backbone.  

 2. AWS Global Accelerator.

AWS Global Accelerator is a global traffic manager that improves the performance and availability of your web applications serving internet users. It operates at the layer 4 of the OSI layer and accelerates a wide range of protocols over TCP or UDP (e.g. HTTP, RTP, WebRTC) by proxying packets at the edge and sending them over the AWS network backbone to your applications in the AWS Regions.

Please note that Global Accelerator and CloudFront are two separate services that use the AWS global network and its edge locations around the world. 

Solutions Comparison and Use Case

If we compare what objects are accelerated using these two preferred options, versus only implementing SAP Note 2526542, we will observe the following:

Please note ‘X’ means accelerated, based on these points, we recommend that :

• You implement CloudFront as the solution to address SAP Fiori performance challenges when deployed globally or regionally.
• If you have a requirement to improve the performance of OData API calls for external system integration scenario with SAP S/4HANA, you may want to implement Global Accelerator. This typically requires a set of static IP addresses for whitelisting, no SSL termination and no edge processing, which fits the use case of Global Accelerator.

Solution Overview

Demo Architecture Diagram of CloudFront and Global Accelerator for SAP Fiori

Based on the diagram above, we will implement a simple deployment of SAP S/4HANA 2020 with embedded Fiori in the AWS us-east-1 (Northern Virginia) region that can be accessed over the Internet, while the users are located in Singapore. The configuration for CloudFront and Global Accelerator will be described in details in the second blog post in this series, “Improving SAP Fiori Performance with Amazon CloudFront and AWS Global Accelerator – How to Guide”. In this setup, you can see that CloudFront performs TLS 1.3 offloading which improves the security posture of SAP Fiori. This is because CloudFront enforce the use of TLS 1.3, while SAP support for TLS 1.3 is not yet released.

Please note that in the real-life productive deployment, to improve the security posture, we recommend you install SAP S/4HANA with embedded Fiori in a private subnet, and setup an SAP Web dispatcher in a public subnet.

Performance Test 

In this single unit performance test, we use the Google Chrome browser, as it is able to measure the performance for end-user, and also includes a debugging tool that is supported by SAP Fiori. The SAP Fiori user’s profile is assigned with Procurement Manager role in SAP Fiori and S/4HANA.

In the first scenario, we enable incognito mode when accessing SAP Fiori Launchpad. This is to understand the improvement that can be achieved for group users who have no cache available in the browser when accessing SAP Fiori for the first time or when their cache is invalidated due
to UI5 transport changes or upgrades. The improvement via CloudFront was about ~49% compared to direct access to Application Load Balancer in North Virginia because of accelerated performance of both static and dynamic contents of Fiori Launchpad.

In the second scenario, we disable incognito mode when accessing SAP Fiori Launchpad to understand the improvement that we can achieve on the dynamic content only (OData API call). We will logon to Fiori Launchpad and select on “Managed Purchase Requisition” Fiori App with one Purchase Requisition displayed. We will measure only the dynamic content acceleration over Global Accelerator. The improvement was about ~16% compared to direct access to Application Load Balancer in North Virginia because of the use of AWS global network which is faster compared to internet.

Please note that your experiences may vary depending on a variety of factors, such as the location of the end user and your SAP workload, the performance of the network between your end user and the nearest AWS point of presence, and multiple other factors. We encourage you to include your own performance testing, with support from AWS and/or AWS Partner Network (APN) partners, as needed. 

Before you rollout CloudFront and/or Global Accelerator to wider users, we recommend to execute automated performance test from various user’s location to determine the performance improvement that can be achieved in your scenario. You can use real user monitoring tool or an automated software testing tool such as Load Runner for SAP. For more information on how to do performance testing you can refer to this blog.

Conclusion

In the first test scenario, we have reduced the load time of SAP Fiori Launchpad with the use of CloudFront. This is because of the number of cacheable objects that are now available much closer to the end users, and optimized network route for the OData API calls using CloudFront. On top of that, the SAP Fiori Launchpad is now more secure with the TLS 1.3 offloading capability of CloudFront.

In the second test scenario, we have reduced the OData API call load time with the use of Global Accelerator because of optimized network route to the SAP S/4HANA servers. The performance advantage will be even better when we have a higher volume of data being transferred from and to external systems such as SAP SuccessFactors, SAP Cloud Analytics, etc.

Finally, in short, CloudFront is recommended to accelerate the SAP Fiori Launchpad use case, while Global Accelerator is recommended to accelerate the external system integration scenario via OData API calls such as Data extraction for analytics and reporting, etc.

In the subsequent blog, I will be sharing the configuration steps required for CloudFront and Global Accelerator for SAP Fiori. You can also find out more about SAP on AWS, CloudFront and Global Accelerator from the AWS product documentation.