Nettoyage du cache de métadonnées Gateway

SAP Gateway met en cache les métadonnées de chaque service OData afin de ne pas reconstruire le modèle à chaque requête :

• Sur le hub, il met en cache le modèle de métadonnées, le modèle d'annotations et les textes d'annotations.
• Dans le back-end, il met en cache le modèle de métadonnées et le modèle d'annotations.
• Dans un déploiement embedded, hub et back-end forment un seul système, et la mise en cache n'a lieu qu'une fois.

Pour les services construits avec le modèle OData Channel, une classe de fournisseur de modèle modifiée déclenche une actualisation automatique : à chaque requête du document de service ou du document $metadata, le cache compare les horodatages et recharge les métadonnées obsolètes. Le cache de métadonnées SAP Gateway s'actualise donc de lui-même dans le cas courant et n'a besoin d'un nettoyage manuel que lorsque ce contrôle ne peut pas détecter la modification.

Videz le cache lorsque :

• une modification de l'ABAP Dictionary, comme un nouveau type de champ dans une structure, modifie le modèle sans changer la classe de fournisseur de modèle, car aucun mécanisme ne la détecte ;
• une classe de fournisseur de modèle modifiée a été importée dans un système de production, où SAP recommande un nettoyage après chaque import de ce type ;
• des support packages ont été importés, ce que SAP cite parmi les corrections de mise en cache du launchpad ;
• une application SAP Fiori affiche d'anciennes propriétés, d'anciens libellés ou d'anciennes annotations alors que le service est correct dans le back-end.

Dans les systèmes de développement, le cache du hub est désactivé par défaut : des métadonnées obsolètes y proviennent donc généralement du navigateur ou du cache du back-end. Le nettoyage du cache de métadonnées Gateway est une correction ciblée pour les modifications de modèle que le contrôle automatique ne détecte pas.

Alder Manufacturing transporte un nouveau champ dans son service fournisseurs, et l'application ne l'affiche toujours pas :

1. Dans le système hub, exécutez /IWFND/CACHE_CLEANUP. Sélectionnez Cleanup Cache for all Models, ou limitez-le au modèle concerné, puis exécutez.
2. Dans le système back-end, exécutez /IWBEP/CACHE_CLEANUP de la même façon. Dans un déploiement embedded, les deux s'exécutent dans le même système.
3. Vous pouvez aussi ouvrir /IWFND/GW_CLIENT, appeler le service et utiliser le menu Metadata pour nettoyer le hub, le back-end ou les deux, ou pour reconstruire le cache du service courant.
4. Demandez $metadata dans le SAP Gateway Client et vérifiez que le nouveau champ y figure.
5. Rechargez l'application ; si le navigateur affiche encore l'ancien modèle, videz le cache du navigateur.

Les deux nettoyages sont également disponibles comme activités IMG dans SPRO. Vérifier $metadata avant de tester l'application permet de distinguer un problème de cache de métadonnées Gateway d'un problème de cache du navigateur.

Le SAP Fiori launchpad met également en cache les métadonnées et annotations OData dans le navigateur web, protégées par des jetons cache buster. Le serveur front-end collecte ces jetons auprès des hubs SAP Gateway via le programme /UI5/UPD_ODATA_METADATA_CACHE, que SAP recommande de planifier périodiquement en production, mais pas dans les systèmes de développement. Lorsque les jetons changent, les navigateurs chargent les nouvelles métadonnées.

Si ce programme n'a pas tourné depuis une modification, les utilisateurs peuvent encore voir d'anciennes métadonnées après un nettoyage Gateway. /UI2/INVALIDATE_GLOBAL_CACHES vide les caches du launchpad, pas les métadonnées OData : il ne remplace donc pas cette étape. Le nettoyage du cache de métadonnées Gateway et la mise à jour des jetons côté navigateur rendent ensemble une modification de modèle visible de bout en bout.