Technical Articles
SAP UI5/OData & SAP Gateway Cache clearing (Frequently Faced Issues)
Having worked on many UI5 and Fiori deployments ranging from SAP ECC till SAP HANA 1709, here I am investing my time to brief the idea of cache handling and few related concepts.
- First issues observed in custom developments using sap UI5 is that, after the first deployment moved to production and respective users start using the system, few changes are observed and now when we make the changes and push the same to production.
- Problem : Here the issue is, many company use IE as there browser and the whole set of UI5 code written is loaded and hence your code is not at all reflected and hence client end up saying no changes were reflected.
- Solution : Since your code is residing in client system you have to externally clear the code by refreshing using F12 button and reload with server code or use the in SE38 run the program /UI2/INVALIDATE_GLOBAL_CACHES.
2. Second issue observed is UI code is reflected but the ODATA code which you have changed does not get reflected and system starts behaving differently with some unknown errors and actions.
- Solution : This is very rarely faced issue and needs a keen observation from Payload or debugging that the new code is loaded of not, if not we can use the T-Code /IWBEP/CACHE_CLEANUP for each of your back end systems (SAP ERP,CRM etc)
Select check box “Cleanup Cache in all models”
3. Third issue which we face regularly is that whenever we deploy the new tile on Fiori launchpad or newly configure a UI5 application as a tile on Fiori launch pad, we do not see the changes again due to same cache issue.
- Solution : Since your code is residing in client system you have to externally clear the code by refreshing using F12 button and reload with server code or use the in SE38 run the program /UI2/INVALIDATE_GLOBAL_CACHES.
These are the few ways to handle the cache, which the beginners are not aware of. This is a small document which may help beginner like me.
Thank you Abhilash, real time scenario wise cache clearing was really useful.
Regards,
Jakes
hi abhilash,
thank you for sharing valuable information. i am also new to SAPUI5 world.
in the above content i have some confusssions can you please help me out.
if we use other than IE i.e. chrome, firefox etc… still there is a chance of getting issues in client side
what is the preferd borwer to run SAPUI5 applications
according to problem no.1, the changes were not reflected in client side right so clearing the brower cache is enough , but why should we go for ABAP program(/UI2/INVALIDATE_GLOBAL_CACHES) run in Server side?
thanks in advance.
Hello Bala Krishna,
You are welcome.
Hi Abhilash,
the report /UI2/INVALIDATE_GLOBAL_CACHES should never be used as a standard measure to solve cache issues. It might help in some cases but it only hides the symptom of wrong app implementation or system setup and prevents a later error analysis.
Therefore it should only be used in emergency cases (Production down) but not during the usual production updates.
The most important job is /UI5/APP_INDEX_CALCULATE. This must be executed after a transport reached the production system. A lot of caches depend on this.
In case of standalone apps that run outside of the launchpad, this might not be sufficient because the app does not use cachebuster. This can detected, by checking the requested URL. A request with active cachebuster contains a token usually enclosed in ~...~. If this is not there, the app should be adjusted to enable cachebuster.
For the 2nd case: If the caching of OData $metadata is enabled in the system, it is important to run /UI5/UPD_ODATA_METADATA_CACHE as well. This ensures to update all tokens for these requests.
There might be particular services where customizing changes do not update $metadata automatically. Also here /IWBEP/CACHE_CLEANUP fixes the symptom, but the root cause is an implementation error in the service. Here it misses to calculate its cache token properly which must depend on such customizing changes.
Best regards
Matthias