Fiori Launch Pad Designer Cache cleanup issue

[Former Member]

This saves a day!

Problem Statement:

It was one of those tight deployment schedules when you are blocked in a war room and trying to meet the project timelines. All of a sudden we stopped see our latest changes in Fiori LaunchPad. The Fiori Launchpad designer had captured all details in our catalog but when transported to Q systems the changes were not reflective.

Analysis:

The Launchpad designer changes made using cross-client URL using Tx: /UI2/FLPD_CONF updated the configuration layer and these changes are not persisted in the individual client.

When a user makes changes using TX: /UI2/FLPD_CONF then changes are usually persistent in the configuration layer. However, if in between the user uses TX: /UI2/FLPD_CUST then the changes are registered as a customized version.

TX: /UI2/FLPD_CONF – Launches https://<server>:<port>/sap/bc/ui5_ui5/sap/arsrvc_upb_admn/main.html?scope=CONF&sap-client=<clientId...;

TX: /UI2/FLPD_CUST – Launches https://<server>:<port>/sap/bc/ui5_ui5/sap/arsrvc_upb_admn/main.html?scope=CUST&sap-client=<clientId... CATALOGPAGE:<CUSTOM_TILE_CATALOG>

This leads to inconsistency between the configuration layer and customized version of the catalog.

Resolution:

Open the FLP designer using TX: /UI2/FLPD_CUST and then you can observe that there is an error against the catalog.



Also when you open the catalog you can observe an error message



Click on the “Outdated” text and it would open the below pop-up



Click the “OK” button and the catalog would be reloaded from the configuration layer. That would resolve the temporary synchronization issues.

Why does it save a day?

In my observation, the synchronization happens between CONF and CUST layers once a day. So if you don’t want to waste your time follow this little trick!!!

 

Author

Naveen Rokkam
Lead Software Developer – Product & Innovation