Die neun Höllen des Caches
Wie schon in dem Blog-Post UI5/Fiori und der Cache von Johann Fößleiter von der Cadaxo beschrieben, gibt es in der Welt des UI5 und Fiori viele Caching-Mechanismen, die einem gerne das Leben schwer machen. Ein Mechanismus wurde mir heute klarer, der gerne und häufig zum Leid der Entwickler beitragen, und wie man diesen korrigiert.
SAP-CONTEXT-TOKEN
Der ein oder andere Entwickler kennt es: Änderungen von Annotationen haben gerne mal keinen Impact auf die deployte Fiori Elements Anwendung. Schaut man sich aber über Eclipse/ADT die Preview an, dann klappt es direkt - woran liegt das?
Ein Punkt, der mir die letzten Tage ruiniert hat - der Titel des Blog-Posts ist durchaus berechtigt - ist der sap-context-token. Dieser fällt auf, wenn man sich den Aufruf der Metadaten ansieht, der aus dem Launchpad getriggert wird. Dieser sieht dann so aus:
$metadata?sap-client=100&sap-language=EN&sap-context-token=20251024093624
Wichtig sind hierbei die letzten Zeichen - der Token. Dieser dient dem Caching für eine gute Performance in der Produktion, aber in der Entwicklung will ich lieber 2 Sekunden länger warten und dafür mein neues Coding sehen.
Herkunft
Mit dem Report /UI5/UPD_ODATA_METADATA_CACHE wird hier ein Caching aufgebaut, was auch sinnvoll sein kann. In der Report-Beschreibung wird auch empfohlen hierfür einen stündlich laufenden Job einzuplanen - und solange der Cache da ist, wir die Anzeige auch nur stündlich aktualisiert - nicht das, was wir als Entwickler wollen!
Lösung
In zwei einfachen Schritten wird das Leben schöner:
- Einplanung des Jobs löschen (lassen)
- Den Report **/UI5/DEL_ODATA_METADATA_CACHE anwerfen, der die bestehnden Cachings löscht
...und so einfach ist der Tag gerettet. :-)
