Gateway Metadata Cache Cleanup

SAP Gateway caches the metadata of each OData service so that it does not rebuild the model on every request:

• On the hub, it caches the metadata model, the annotation model and the annotation texts.
• In the backend, it caches the metadata model and the annotation model.
• In an embedded deployment, hub and backend are one system, and caching happens once.

For services built with the OData Channel model, a changed model provider class triggers an automatic refresh: on each request for the service document or the $metadata document, the cache compares timestamps and reloads outdated metadata. The SAP Gateway metadata cache therefore refreshes itself in the common case and needs manual cleanup only when that check cannot see the change.

Clear the cache when:

• an ABAP Dictionary change, such as a new field type in a structure, alters the model without changing the model provider class, because no hook detects it;
• a changed model provider class was imported into a production system, where SAP recommends a cleanup after every such import;
• support packages were imported, which SAP lists among the launchpad caching fixes;
• an SAP Fiori app shows old properties, labels or annotations although the service in the backend is correct.

In development systems the hub cache is deactivated by default, so stale metadata there usually comes from the browser or the backend cache. Gateway metadata cache cleanup is a targeted fix for model changes the automatic check misses.

Alder Manufacturing transports a new field into its supplier service, and the app still does not show it:

1. In the hub system, run /IWFND/CACHE_CLEANUP. Select Cleanup Cache for all Models, or restrict it to the affected model, and execute.
2. In the backend system, run /IWBEP/CACHE_CLEANUP the same way. In an embedded deployment, both run in the same system.
3. Alternatively, open /IWFND/GW_CLIENT, call the service and use the Metadata menu to clean up the hub, the backend or both, or to rebuild the cache for the current service.
4. Request $metadata in the SAP Gateway Client and confirm that the new field is there.
5. Reload the app; if the browser still shows the old model, clear the browser cache.

Both cleanups are also available as IMG activities in SPRO. Verifying $metadata before testing the app separates a Gateway metadata cache problem from a browser cache problem.

The SAP Fiori launchpad also caches OData metadata and annotations in the web browser, protected by cache buster tokens. The front-end server collects these tokens from the SAP Gateway hubs through the report /UI5/UPD_ODATA_METADATA_CACHE, which SAP recommends scheduling periodically in production but not in development systems. When the tokens change, browsers load the new metadata.

If that report has not run since a change, users can still see old metadata after a Gateway cleanup. /UI2/INVALIDATE_GLOBAL_CACHES clears launchpad caches, not OData metadata, so it does not replace this step. Gateway metadata cache cleanup and the browser-side token update together make a model change visible end to end.