In a properly configured Fiori Launchpad system the data requested by the server should be up to date with the UI5 Resources deployed on the ABAP Frontend server (typically cohosted with the Gateway server).
This article helps to
a) Identify whether a cache-inconsistency is relevant to your problem.
b) Indicates how to fix this.
The Fiori Cache-busting mechanism on the ABAP uses ui5 cachebusting tokens, e.g. ~02696CA62242C2C5DA00BA7EA2280BB9~5
to address resources of individual applications, e.g.
The suffix ( ~5 ) and path position (behind UI5 Application/BSP name /ca_fiori_inbox/ ) indicates that it is an per application/libary cachebuster token.
The ushell resources may use a generic cachebuster token ( ~C )
If a newer version of application resources are deployed, the cachebuster token should change.
Invoke the FLP with the cache-busting-mechanism disabled (sap-ushell-nocb=X )
In a network trace, you will see that resources are now loaded without a cache-buster token. (and served without cache headers), thus
they source actually deployed resources on the server.
If the application runs this with setting, it’s a strong indication reindexing the cache-busting tokens will address the issue.
If a a specific application is flawed one may then directly comparing the responses of individual files (typcially the component-preload.js ):
In a consistent system the responses with and without cache-buster token in the URL should be identical:
Fire the request (e.g. by double clicking in the Chrome Network trace) .
Remove the Cachebuster token from the URL, fire again:
Compare the results (typically comparing the length in the response , here 64235 is enough to tell a difference)
But you may also download the file and use a textual comparison/diff tool.
One can also check for the file content deployed within the mime repository
If the response served from the servers are distinct, this indicates the Fiori Launchpad attempts to read stale resources from the server.
The server may still serve these old resources, as they are in the ICF cache.
(In a non-productive system or severe cases refreshing the ICF cache content may be a means to highlight more inconsitsencies, as, if this cache is deleted, the server may return with a 404 response for stale ui5 resources).
1. Run the report /UI5/APP_INDEX_CALCULATE ( this report should be scheduled in a system).
Check the Report and the associated Application log for errors in this indexing process ( related to the app under suspicion).
2. Open the Fiori Launchpad again. Check whether it now uses a *new* cachebusting token for the questionable resource (here ~8EE…):
Now (N)ew and (D)eployed resource should be in sync again (file size and content identical).
If there are still inconsistencies or the cache-busting token is identical, run
/UI2/INVALIDATE_GLOBAL_CACHES and /UI2/INVALIDATE_CLIENT_CACHES in the affected client.
Wait 3-4 minutes for app-server synchronization and see whether this has resolved the issue.
Note that the latter two should *not* be run regularly, as, in contrast to /UI5/APP_INDEX_CALCULATE, they will generate ( “touch”)
new timestamps each time they are executed for some UI2 resources, leading to a degradation of End-User-Performance in productive systems.
If there are
a) no application log errors during app indexing,
b) the ui2 invalidation reports were run.
c) the server response is still inconsistent (even after waiting app server synchronization time).
d) SAP-external network mechanism (e.g. additional proxy servers with custom cache rules) have been checked /flushed
do not hesitate to file a support ticket on one of the associated components:
CA-UI5-TOL (app index, ui5 resource handler)
CA-UI2-INT-BE (Fiori Launchpad ABAP backend caches).
Related SAP Documentation:
- Cache Buster for SAP Fiori – User Interface Add-On for SAP NetWeaver – SAP Library
- SAPUI5 Application Index – User Interface Add-On for SAP NetWeaver – SAP Library
Related SCN Articles: