SAP Fiori cache problems often appear after a transport, support package, SAPUI5 update, or application change. Typical symptoms include an old tile, outdated UI text, a blank page, metadata that does not match the back end, or an application that works for one user but not another.
The fastest solution is not to clear every cache blindly. Use the checklist below to identify the affected layer and apply the smallest safe fix.
Before you start
Run administrative reports only with the correct authorization and follow your organization's change process. In production, confirm the business impact and prefer a targeted or delta operation when SAP documentation provides one.
Step 1: Identify the symptom
- Only one browser or user is affected: start with browser cache and a private window.
- Several users see old launchpad content: investigate UI2 client caches.
- OData metadata is old: investigate SAP Gateway metadata caches.
- A transported SAPUI5 app is missing or outdated: check the SAPUI5 application index.
- The app opens but shows an authorization error: analyze authorization instead of repeatedly clearing caches.
Step 2: Test the browser layer
- Open the Fiori launchpad in a private or incognito window.
- Perform a hard refresh.
- If the private window works, clear site data for the launchpad domain rather than clearing unrelated browser data.
- Close all launchpad tabs and sign in again.
If all users have the same issue, the root cause is probably not limited to the browser.
Step 3: Invalidate SAP Fiori content caches
For outdated launchpad or UI2 content, SAP documents the report:
/UI2/INVALIDATE_GLOBAL_CACHESRun the report in the appropriate front-end system through transaction SE38. This invalidates global UI2 caches. Use it when UI2 content remains stale after a relevant change, upgrade, or support activity.
SAP also provides client-cache mechanisms. Follow the documentation for your SAP_UI and platform version because the correct report and behavior can vary by release.
Step 4: Clean SAP Gateway metadata caches
If an OData service returns outdated properties, wrong annotations, or metadata errors after a service change, clear the metadata cache at the relevant hub and back-end layers.
Front-end or Gateway hub: /IWFND/CACHE_CLEANUP
Back-end system: /IWBEP/CACHE_CLEANUPUse the back-end cleanup only when the architecture and symptom require it. After cleanup, request the service metadata again and verify that the expected entity types and properties are present.
Step 5: Recalculate the SAPUI5 application index
When SAPUI5 repository content changes, the application index may need an update. SAP documents the following report:
/UI5/APP_INDEX_CALCULATERun it through SE38 in the front-end system. SAP recommends a delta-style calculation for regular scheduling and reserves a complete calculation for exceptional cases. Review the report options and your release documentation before executing a full calculation.
Check the report log if the index contains invalid component IDs, duplicate component IDs, or manifest parsing errors. Application logs can also be analyzed with transaction SLG1 using the relevant UI5 application-index log object.
Step 6: Check authorization and connectivity
Cache cleanup cannot fix a missing role, failed trusted connection, inactive service, or back-end authorization.
- Use SU53 immediately after an authorization failure.
- Use ST01 or the approved authorization trace tool when deeper analysis is required.
- Check /IWFND/ERROR_LOG for SAP Gateway errors.
- Confirm the OData service is active and points to the expected system alias.
- Verify required ICF services in SICF.
Recommended troubleshooting order
- Reproduce the problem and record the exact time, user, app, URL, and error.
- Test in a private browser window.
- Check authorization and Gateway error logs.
- Clear the specific browser or metadata cache involved.
- Invalidate global UI2 caches only when the symptom points to shared Fiori content.
- Recalculate the SAPUI5 application index after repository or transport changes.
- Retest with the same user and a second user.
Common mistakes
- Running every cache report without identifying the affected layer.
- Performing a full application-index calculation when a delta update is sufficient.
- Clearing caches repeatedly while ignoring authorization or service errors.
- Testing with a different user and assuming the original issue is solved.
- Making production changes without recording the before-and-after result.
Quick reference table
| Symptom | First check | Likely tool |
|---|---|---|
| Old launchpad content for many users | UI2/shared cache | /UI2/INVALIDATE_GLOBAL_CACHES |
| Old OData metadata | Gateway metadata cache | /IWFND/CACHE_CLEANUP |
| Back-end metadata remains stale | Back-end cache | /IWBEP/CACHE_CLEANUP |
| Transported UI5 app missing or outdated | Application index | /UI5/APP_INDEX_CALCULATE |
| Authorization message | User authorization | SU53 / ST01 |
| OData request failure | Gateway error details | /IWFND/ERROR_LOG |
Conclusion
Treat Fiori caching as a layered system: browser, UI2 content, Gateway metadata, back-end metadata, and SAPUI5 application index. Start with the smallest relevant action, verify the result, and move to the next layer only when evidence supports it. This approach is safer and faster than clearing everything.
0 Comments