In SAP S/4HANA embedded Fiori landscapes, we often assume that clearing Fiori, Gateway, and browser caches is sufficient after transporting UI5 changes. However, in production systems—especially those with long uptimes and higher user traffic—this assumption can lead to confusing and inconsistent behavior.

In this blog, I’ll share a real troubleshooting scenario where a Fiori app update worked perfectly in Pre-Prod but failed to reflect in Production when accessed via an internal DNS. The root cause turned out to be an often-overlooked component: the ICM HTTP Server Cache (SMICM).

Problem Statement

After transporting an updated Fiori/UI5 application:

• ✅ The updated app worked correctly in Pre-Prod
• ✅ The updated app worked in Production via Public DNS
• ❌ The app did NOT reflect changes in Production via Internal / Local DNS

Despite clearing the following caches:

• Fiori Global Cache
• Fiori Local Cache
• Gateway Cache (/IWFND/CACHE_CLEANUP)
• Page Cache (/UI2/PAGE_CACHE_SYNCHRONIZATION)
• Browser cache

…the issue persisted only in Production and only for the internal DNS.

This led to confusion, as:

• Both DNS aliases were hitting /sap/bc/*
• Cache-buster JSON was identical
• Backend systems and transports were confirmed correct

Investigation Highlights

During deeper analysis using browser developer tools:

• Public DNS responses had no Cache-Control headers
• Internal DNS responses included Cache-Control headers
• No ETag was present, indicating server/proxy-level caching

This pointed away from SAP UI or Gateway caches and towards HTTP-level caching.

Root Cause

The issue was caused by stale content in the ICM HTTP Server Cache on the Production system.

Key factors why this surfaced only in Production:

• Long system uptime
• Higher traffic keeping cache entries “warm”
• Larger ICM server cache size
• Internal DNS consistently routing to the same ICM instance
• Pre-Prod systems having lower load and more frequent restarts

The ICM cache is hostname-aware, meaning different DNS aliases can result in different cached entries—even for the same /sap/bc/ui5_ui5 path.

Solution

Clearing the ICM HTTP Server Cache immediately resolved the issue.

Steps:

1. Go to transaction SMICM
2. Navigate to: Goto → HTTP Plug-In → Server Cache → Invalidate Globally (or restart ICM if required)
3. Reload the Fiori app using the internal DNS

🎉 The updated UI5 application was now visible.

Why This Was Not Needed in Pre-Prod

Pre-Prod systems typically:

• Have lower user load
• Use smaller or default ICM cache sizes
• Are restarted more frequently
• Do not retain cached UI5 resources for long periods

As a result, stale ICM cache entries rarely survive long enough to cause visible issues.

Key Takeaways

• Clearing Fiori and Gateway caches does not clear the ICM HTTP server cache
• In embedded S/4HANA systems, SMICM cache can serve stale UI5 resources
• Issues appearing only in Production often relate to uptime, load, and cache persistence
• Always include SMICM cache invalidation in Fiori deployment troubleshooting