Launchpad Cache Invalidation

Three caches can hold outdated launchpad content:

• Server-side UI2 cache on the front-end server, for the launchpad's own services such as page building and personalization. The system invalidates it automatically when a tile or catalog configuration, a PFCG role, LPD_CUST content or a SAPUI5 app changes.
• Browser cache, for SAPUI5 resources, app code, target mappings and OData metadata. Cache buster tokens in the resource URLs make the browser reload only what changed on the server.
• SAP Gateway metadata cache, for OData service models, cleared separately with /IWFND/CACHE_CLEANUP and /IWBEP/CACHE_CLEANUP.

Knowing which of the three holds the stale data decides which launchpad cache invalidation step is needed.

SAP's position is that manual invalidation of the UI2 cache should normally not be required, because changes trigger it automatically. Clearing caches is justified when:

• a transported catalog or app does not appear although roles and content are correct;
• a support package, SAPUI5 note or release upgrade has been applied;
• users see old app behavior after a deployment, and the SAPUI5 application index was not recalculated.

Do not clear caches as a reflex for every missing tile. A missing catalog in the role or a target mapping without the user's device type produces the same symptom, and /UI2/FLIA finds those in minutes. Launchpad cache invalidation fixes stale data, not wrong content.

After Alder Manufacturing imports a support package on its front-end server:

1. Run /UI5/APP_INDEX_CALCULATE, or confirm that its scheduled job ran, so cache buster tokens reflect the new app versions.
2. Run /UI2/INVALIDATE_GLOBAL_CACHES in SE38, or transaction /UI2/INVAL_CACHES, to invalidate all UI2 caches.
3. If needed, run /UI2/INVALIDATE_CLIENT_CACHES in SE38, for all users or one user. Invalidating other users' caches requires the role SAP_UI2_ADMIN_700.
4. Run /UI2/DELETE_CACHE_AFTER_IMP after the import if the upgrade guide for your release lists it.
5. Clean up the SAP Gateway metadata cache if OData services changed.
6. Ask affected users to reload, or clear the browser cache if symptoms persist.

Each client cache invalidation is logged in the application log (SLG1). Following this order makes launchpad cache invalidation predictable instead of trial and error.

/UI2/INVALIDATE_CLIENT_CACHES renews the global cache buster token. Since SAP introduced application-specific cache busting, SAP Fiori apps in the SAPUI5 repository get their own tokens from the SAPUI5 application index, and the browser reloads an app only when it changed. The global token still covers:

• data from the launchpad's own OData requests, such as target mappings and personalization;
• classic SAPUI5 resources that are not components, for example some custom tile implementations;
• apps missing from an incomplete application index.

SAP therefore describes running /UI2/INVALIDATE_CLIENT_CACHES as necessary only in exceptional cases. A regularly scheduled application index makes /UI2/INVALIDATE_CLIENT_CACHES rarely needed.