SAP Fiori using Azure CDN for SAPUI5 libraries
|The content of this blog post will be updated with Azure Front Doort architecture in future. For latest SAP Fiori applications a different CDN architecture using Azure Front Door with dynamic caching and ABAP system as source is needed. Until then, the steps described in this blog show how to cache user owned content, such as own UI5 libraries and other static content.|
What is CDN? Wikipedia describes CDN a “geographically distributed network of proxy servers, providing high availability and performance by distributing the service spatially relative to end users”.
With CDN, the content is cached near the users around the world. With Azure CDN, at the time of writing, over 130 points of presence (POP) locations are available worldwide. This way content is delivered much faster since the network path is closer to users own or neighboring country instead of accessing from another continent.
If you are an organization with a large global footprint, having users accessing your central SAP system landscape spread out across the world, you have one enemy when providing speedy access to Fiori – laws of physics. A central SAP system must be place in one place in the world and users accessing it are bound to the speed of light which even network transmissions must observe. An https request from a user in Singapore accessing an SAP environment located in Eastern US simply must cross half the planet and return, resulting in 150-200ms network latency round trip.
How do we integrate Azure CDN with our SAP system? They say a picture is worth a thousand words.
It’s simple. An end user opens the SAP Fiori’s URL, webserver responds with data and points to the CDN’s URL to obtain the static SAPUI5 libraries. Everything else, Fiori generated website content, is loaded from the Fiori server. The use of Azure CDN is possible regardless of where your SAP system runs, on-premises or some hosting partner or public cloud. It’s not mandatory to have it running on Azure although that’s clearly ideal as the network traffic for both CDN and Fiori returns to users from the same Microsoft network backbone.
In addition to making things faster for end user by way of quicker network response time, Azure CDN serving the static content reduces load on your SAP Fiori servers, as part of the response is offloaded, potentially saving cost due to needing fewer VM resources to run it.
Can I not use SAP’s own CDN?
The usage of SAP’s SAPUI5 CDN is only allowed for SAP Cloud products like e.g., SAP Cloud Platform, SAP S/4HANA Cloud, SAP SuccessFactors or SAP HANA Enterprise Cloud, however on-premises installations/systems are not allowed to bootstrap SAPUI5 from SAP’s SAPUI5 CDN. Use of 3rd party CDNs, like Azure CDN, is however supported as per SAP note
2943781 – Is the usage of SAP’s Content Delivery Network for onPremise systems permitted?
Get your SAPUI5 libraries in Azure storage
We start with determining the version of your SAPUI5 libraries. To get the exact version you can use SAP note 2363155 which shows several different ways. Having obtained the exact version on your Fiori system, download SAPUI5 version from SAP – https://tools.hana.ondemand.com/#sapui5. The website shows all current and old versions so you can match to your system.
The download is a ~180MB large, compressed file which needs to be extracted first.
To have Azure CDN access the files, they need to be stored in Azure storage. For this, create a storage account which needs to be publicly accessible for the CDN service to use it. As documented, by default anonymous public read access for blobs is usually disabled as it’s a security risk, however in this case the content is publicly available SAP library files, and no own Fiori content/data is stored on the blob container. Alternatively, SAS signatures or authentication tokens could be used with some adaptation, as described here.
Create an Azure storage account with following settings:
- Basics tab/Account kind: StorageV2 (general purpose v2)
- Networking tab/Connectivity method – public endpoint (all networks) – this is public afterall!
- Data protection tab/Secure transfer required: enabled – only allow https
- Allow Blob public access: enabled – for CDN connectivity, alternatives below.
Other settings can remain default.
Within the storage account, we need a blob container holding the actual data. Create a blob container with anonymous blob access enabled in this storage container. Add the SAPUI5 version in the container string, so you can more easily change to a newer version by simply uploading to new container and re-point CDN to this new container and its different SAPUI5 version.
Now upload all extracted files and folders of the downloaded SAPUI5 library pack to this container, as this can be over 30000 files and 500MB, use a tool like Azure Storage Explorer or azcopy to make your life easier. Once uploaded, the SAPUI5 library files are ready to be accessed from Azure CDN. You can test the public access by calling one file through your browser https://<storageaccount-name>.blob.core.windows.net/<container-name>/<path-and-filename>.
Configure Azure CDN
Azure CDN is configured on the same storage account that contains the just uploaded SAPUI5 libraries.
Configure a new endpoint using the Microsoft pricing tier. CDN endpoint name will be accessible under <cdn-endpoint>.azureedge.net but can be later changed to a custom domain for easier management.
Once created, select the now running CDN endpoint to start configuring CDN features.
Configure Azure CDN’s Origin
We have a CDN, we have a storage account with a blob container. We need to link them together, to tell Azure CDN where to find the files to cache!
To do that, we need to configure the origin settings. For this SAPUI5 libraries setup its very straightforward, simply navigate as per the images below and set the origin settings. We only enable https – since we enabled secure transfer only on the storage account – and the path which in our case is the container name. We chose a container name to contain the SAPUI5 version so we can keep Azure CDN’s URL static in SAP Fiori but change to a newer SAPUI5 version should we do update the Fiori system – remember earlier chapter how to determine the exact SAPUI5 version used by the application.
After the origin is configured, the local CDN endpoints around the world will start caching your data, typically within minutes. In future when updating your SAP systems, you’d need to update the SAPUI5 libraries on CDN too. Simply create a new blob container with new version, upload files, change CDN origin to point to new blob container and purge the CDN endpoints. Within ~10 minutes all public CDN endpoints will contain the new SAPUI5 libraries.
Add a custom domain (optional)
Your CDN endpoint established during the creation will be <CDN endpoint name> followed by .azureedge.net.
To make it appear more streamlined for access purposes, firewalls, etc., utilize your own custom domain. Your Fiori application is in the end available at a public URL, protected by Azure Active Directory and Multi-Factor Authentication certainly but still a public URL using a (sub)domain. You can leverage the very same custom domain for your CDN.
The easiest way is of course if your domain is provided by Azure, for example through the App Service Domains service. Azure has a short tutorial how to add such custom domain to your CDN.
If your custom domain is through a different registrar and DNS provider, fret not, as Azure has the same steps documented as well here. If you’d want to map Azure CDN to a domain root or apex, this too is possible as documented in this guide.
Similarly activating https support for your custom domain depends on where your domain is registered and ownership of the TLS certificates. A tutorial exists by Azure to walk you through these steps as well for all available scenarios.
At the end of your steps, your custom domain is mapped to Azure CDN and https is enabled. In this blog post we chose to go with an Azure Web Service Domain, Azure DNS and subdomain cdn in domain azurecdn-sapui5-blog.com.
Add a CORS rule
CORS (Cross Origin Resource Sharing) is a http feature to access resources of a different (sub)domain by a web application. So if your Fiori application runs on https://www.azurecdn-sapui5-blog.com and your SAPUI5 assets inside your CDN are accessible at https://cdn.azurecdn-sapui5-blog.com, you need to correctly configure http headers to tell the client – browser – to access assets from the cdn subdomain.
In principle two options exist to accomplish this.
First, the web application – in our case the SAP Fiori system – needs to correctly create Access-Control-Allow-Origin headers authorizing the CDN (sub)domain. This can be accomplished by a rewrite rule inside of either SAP WebDispatcher or the actual SAP ICM on SAP Fiori system. A SAP Wiki article explains the actions needed. If there are multiple web dispatchers or SAP application servers providing ICM service, the same rewrite rule needs to be set on each of them in their profiles.
Alternatively, to doing this on the Fiori level, is to activate such rewrite rule on the CDN level centrally. Such rule can be only activated on Azure CDN with Microsoft profile or Verizon premium profile. In our example we used the Microsoft profile and show below the rewrite rule allowing the CDN assets to be used by the SAP Fiori application, without the need for any other SAP configuration to account for CORS.
Test the performance
Now that everything is ready on CDN side
- SAPUI5 libraries extracted and uploaded to CDN’s storage blob
- CDN created and configured
- (optional) Custom domain activated, https active
let’s test the performance, how quickly can we access a single file from the CDN around the globe.
A great tool for this purpose exists called GeoPeeker – “how a site appears to the rest of the world”. Simply add your CDN’s URL and path to the single file you test – could be a text file existing in the SAPUI5 libraries or a simple test page you created. In my case I created super small html page to test with. Geopeeker will then access the website through endpoints around the world and show you the page how it looks and the response time to obtain the result.
Results? Single digit latency accessing from around the world, the power of CDN. Beats waiting 150ms or more for a round trip around the globe.
2ms from Singapore, 1ms in Brazil and 2ms Australia. Our CDN performs great, lets configure it on the SAP side!
Configure CDN use within SAP Fiori
How to setup CDN for SAPUI5 libraries inside your SAP Fiori system is described in SAP note 2526542 – How to load SAPUI5 files from CDN for performance improvements in Fiori and Standalone UI5 apps.
The note does a wonderful job explaining how to setup CDN and the custom role to enable CDN usage on per user basis. You need to add the path /resources to your CDN’s (sub)domain, as explained in the note.
SAP note 2526542 described in this blog is not valid anymore for newer Fiori Frontend Server versions starting with 2020. See SAP’s documentation and also documentation for the Customizing (TX SPRO) activity Configure SAPUI5 Bootstrapping in Customizing under This method is not depicted and described in this section, however.
From now, all SAP users with the custom CDN role enabled will have their requests for SAPUI5 libraries redirected to the CDN URL provided, resulting in much better access speed and performance. Users who should not use CDN, be it for legal or technical reasons, continue obtaining these SAPUI5 libraries from the SAP Fiori server directly.
You can verify in a Browser’s developer tools (Ctrl+Shift+I) and loading your Fiori applications, where the UI5 libraries are loaded from – you should see the URL for your CDN and very good response times.
For a SAP user with CDN turned off or global CDN setting removed in SAP Fiori, you’d see all SAPUI5 coming from the Fiori system itself, like below.
How much benefit does it bring in the end?
Performance improvement with CDN depends on many factors. How geographically spread is your user base and from which geographical point are you measuring? A user accessing SAP Fiori – centrally located in Europe – from the Middle East will have less benefit from CDN than a user in Australia. However, the benefit is still present, for very low implementation and operational cost.
We ran a test comparing one user with the CDN role activated and one without. The Fiori launchpad was accessed from a VM in Singapore, United States (WA) and Germany. Our SAP backend including the Fiori Frontend are based in Dublin. As a preparation caching was disabled using the browser’s developer tools and all test calls were made from Chrome. The next data collection was initiated by hitting refresh.
The experiment does not reach statistical relevance but gives a good indication of the achievable speedup. With more distance between the calling client and SAP Fiori, the more beneficial Azure CDN becomes in overall response time for an initial page load.
Avg. loading time with CDN
Avg. loading time without CDN
Performance gain by using CDN
Each SAP Fiori implementation would see different numbers, absolute and relative, do not assume identical gains for your setup. You can simply test with two otherwise identical users, one with CDN caching enabled and disabled.
You can couple the use of Azure CDN for SAPUI5 with having the actual SAP Fiori system running in Azure and utilizing Azure Application Gateway with Web Application Firewall as described in the following blog series: SAP on Azure: Azure Application Gateway Web Application Firewall (WAF) v2 Setup for Internet facing SAP Fiori Apps by Dennis Padia.
Another benefit is that Azure CDN, as well as Azure Application Gateway if SAP runs in Azure already, by default enable http/2 protocol for much faster access. SAP unfortunately does not activate http/2 support by default in ICM and/or Webdispatcher, however the below blog post provides details on this and great benefits associated How HTTP/2 feature can improve your Fiori/SAPUI5 solution performance
To further lock down Azure CDN and data contained therein, use documented practices by Azure such as shared access signature storage keys for accessing data, restricting access by regions or rules.
No amount of network magic fairy dust will help with a slowly responding application. Beyond just the network layer, start looking at performance of Fiori apps such as OData performance testing described in this blog post Measure the performance of your OData service. Tune those slow queries, there is only so much you can improve with better network response times.