Skip to Content
Technical Articles
Author's profile photo Wouter Lemaire

Cache Buster Indexing UI5 Tooling Task


I think today almost everyone is aware of the cache buster mechanism in UI5. In case you never heard about it or you have no clue what it does, it’s explained very well by SAP here

The cache buster mechanism enables UI5 applications to benefit from browser caching and still makes sure the browser bypasses the cache when a new version of the app is available.

Or how it’s explained in the documentation:

A cache buster allows SAPUI5 to notify the browser to refresh the resources only when the SAPUI5 resources have been changed. As long as they are not changed, the resources can always be fetched from the browser’s cache.


This cache buster concept adds a timestamp to the path of each file like “~20120716-0201~”. This allows the cache buster to update this file in the cache by changing the timestamp to access the file. For generating these timestamps and provide the paths, SAP has cache busting indexing mechanisms for Java, ABAP and embedded into BTP. But not for HANA XS or on any other system for serving OpenUI5 apps:

When you search for Cache Buster solutions on HANA XS and XSA, you might find some already.

In this blog I want to provide another solution to do this making use of the UI5 Tooling.

Enable Cachebuster in the app

Before explaining the solution, let’s enable cache buster in your OpenUI5 app. This needs to be activated in the bootstrap code in the index.html page like this.

            data-sap-ui-resourceroots='{"be.wl.cachebusterdemoapp": "./"}'

Maybe you don’t see the differences immediately so let’s focus on the parts that differs from the default bootstrap code.

First part is the “src” property, here we add “sap-ui-cachebuster” between “resources” and “sap-ui-core.js”:


Second, the property “data-sap-ui-appCacheBuster=”./”” needs to be added to the bootstrap like this:


Test the App with CacheBuster locally

The CacheBuster mechanism can be tested locally by building the app with the task “generateCachebusterInfo” and run it from the “dist” folder.

“ui5 build -a –clean-dest –include-task=generateCachebusterInfo”


Let’s Install “serve” to test the dist folder locally

npm i –save-dev serve

Add a start dist script to Package.json

“start:dist”:”serve dist”,

Run it:

npm run start:dist


Running the app from the dist folder will not work. With CacheBuster enabled, UI5 is adding the generated timestamp from the CacheBuster info file to the request url. This path does not exist in the “dist” folder.

This would be the exact same problem on an XSA server or none Fiori Launchpad environment. In other system you could solve this with a Java Servlet or PHP script. In the next step I will provide you an alternative.


As a solution for this problem, I created a Cachebuster indexing task for the UI5 tooling. This task will generate the CacheBuster info page, which contains all the files and their timestamp for the CacheBuster mechanism and use this CacheBuster info file to copy each file of the UI5 project to a folder with the generated timestamp. This will make sure that all request paths including timestamps generated by the CacheBuster mechanism can be resolved.

The UI5 tooling task is available on NPM:

This makes it easy to consume, simply install the npm package:

npm install ui5-task-cachebuster-indexing –save-dev

Add as a UI5 dependency in the package.json

	"ui5": {
		"dependencies": [

Make sure it run behinds the last possible step (eg generateVersionInfo) or after generateCachebusterInfo. The task generateCachebusterInfo is not required as this is included in this Cache Buster Indexing task as well.

Define the task ui5.yaml config as a custom builder task:

  - name: ui5-task-cachebuster-indexing
    afterTask: generateCachebusterInfo

Build the app and you’ll see your productive app in the dist folder with a copy of each file in a folder with the related timestamp. The dist folder isn’t that beautiful anymore but it should only provide you a productive app. It doesn’t matter much what’s in it as long as it does the job 😊

Run test from dist folder again


Known limitations

The task “generateCacheBusterInfo” from the UI5 Tooling can be configured to work with hashes or timestamps. Like in this example:

Currently this configuration is not taken into account in the custom task for Cache Buster Indexing. It’s not yet possible, or at least not that I know of, to access global config in a custom task.



This UI5 Tooling task is available on npm:

You can find the code of this package on GitHub:

The demo project is also available on GitHub:

It is also listed in the UI5 Tooling Ecosystem Showcase:

Hope this will help you with any caching problems in your OpenUI5 project! 😉

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Somnath Paul
      Somnath Paul

      Hello Wouter,

      Thanks for sharing this blog post. I was trying with this tooling to enabling my ui5 app for cache buster set up. But I have encountered a few issues here.

      The build worked as per your blog post. But I need to deploy my code back to ABAP server. So when I tried that it failed because it is now having folders which starts with '~' sign and that is not being accepted.

      Also I find all my files are duplicated under dist folder, and artefact count doubled kind of. So I had to drop off this approach and tried with an old method by using script tag in my index.html file as below.

      		sap.ui.getCore().attachInit(function () {
      			//force update on page load if version changed - i.e. app cache buster
      			//Appending version to files		    	
      			$.post("./version.json?" + "&__=" + new Date().getTime(), function (data) {
      				(function () {
      					var proxied =;
  = function () {
      						var url = arguments[1];
      						if (url.indexOf("?") == -1) {
      							url = url + "?";
      						arguments[1] = url + "&_TheAppVersion=" + data._TheAppVersion;
      						return proxied.apply(this, [];
      				new sap.m.Shell({
      					app: new sap.ui.core.ComponentContainer({
      						height: "100%",
      						name: "ABAP.Resource.WorkList",
      						settings: {
      							id: "ABAP.Resource.WorkList"
      			}, 'json');

      Now by doing this it gets attached some hard coded version at the end of the file ( being picked up from verison.json file) while getting loaded and it serves my purpose, only problem is one of the file (a controller under webapp folder) is NOT being considered while adding the version tag at the end of the file, hence its always disk cached.

      So could you please share some thoughts how to fix this issue, and also at the same time, I felt may be I am not doing the tooling part properly or may be this npm plugin is not built for ABAP deployment (my guess only).

      If you please share your views on that. Thanks in advance!

      - Regards , Somnath


      Author's profile photo Wouter Lemaire
      Wouter Lemaire
      Blog Post Author

      Hi Somnath,

      Thank you for your interest in this topic. Normally (depending on the version of your backend) this is not needed if you are working on an ABAP system with the gateway component. It has cachebusting mechanism already in the system but you have to run the report "/UI5/APP_INDEX_CALCULATE".

      The purpose of this UI5 Tooling extension is rather for standalone UI5 applications on HANA XSA system or a OpenUI5 app on any other webhost.

      I also tried the solution you proposed but somehow this made the performance of the app very slow...

      Kr, Wouter

      Author's profile photo Pieter Janssens
      Pieter Janssens

      Hi Wouter,


      SAP has cache busting indexing mechanisms for Java, ABAP and embedded into BTP.


      • Is there any documentation on the cache busting mechanism embedded into BTP?
      • Is this only supported when deploying via the Business Application Studio? 
        • I'm doing my developments locally (VS Code)
      • Does this support both CF apps and deployments in the HTML5 Application Repository Service?

      P.S. I belief the URL in your introduction should point to the AppCacheBuster page?


      Best regards,



      Author's profile photo Wouter Lemaire
      Wouter Lemaire
      Blog Post Author

      Hi Pieter,


      It doesn't matter where you develop your app. Cache buster is working inside the launchpad service of BTP.

      The Launchpad service works together with the html5 app repo service so yes it supports this.

      Regarding docu, not much available on this except it is mentioned here:

      When you update a site, note that:
      Personalization is kept.
      Cache busting is supported. If you change static resources, you don't need to clear the cache.

      Kr, Wouter

      Author's profile photo Pieter Janssens
      Pieter Janssens

      Hi Wouter,


      What is your use case for serving dist locally?

      It's sufficient to use a proxy/middleware to link the path including the cache timestamp to the actual resource. This is most probably also what is done by the HTML5 Repository Service.

      To use app cache busting in a deployed @sap/approuter app I have also solved this by providing a generic route for these cache buster paths.


      Best regards,


      Author's profile photo Wouter Lemaire
      Wouter Lemaire
      Blog Post Author

      In my case the app is running on hana xsa with not all cf services available, no html5 app repo and launchpad service.


      Normally the launchpad service handles cache busting.

      Why dist folder? Webapp should be for development purposes or debugging. Dist for productive usage. Cache busting is only needed for end users and not a problem while developing.