Aufwärmen eines Endpunkts

Beim ersten Aufruf eines Cloud-API-Endpunkts durch eine aufrufende Anwendung kann die Verarbeitung des Aufrufs länger als normal dauern. Dies liegt daran, dass der Guidewire-Server möglicherweise Aufgaben für den ersten Aufruf ausführen muss, die er für nachfolgende Aufgaben nicht erneut ausführen muss, z. B.:

  • Laden von Java- und Gosu-Klassen
  • Analysieren und Laden von Konfigurationsdateien, die in der ersten Referenz geladen sind
  • Laden von Daten aus der Datenbank oder anderen Quellen in lokale Caches
  • Initialisieren von Datenbankverbindungen

Möglicherweise möchte eine aufrufende Anwendung vermeiden, dass diese langsame Verarbeitungszeit während eines echten Geschäftsaufrufs auftritt. Daher kann es sein, dass die aufrufende Anwendung den Endpunkt „aufwärmen“ möchte. Dabei wird eine „Aufwärmanforderung“ als Dummy gesendet, um diese ersten Aufgaben auszulösen. Die Aufwärmanforderung unterstützt nachfolgende Anforderungen bei der schnelleren Ausführung.

Aufwärmanforderungen sollen keine Daten erstellen oder ändern. Theoretisch könnte eine aufrufende Anwendung ein GET als Aufwärmanforderung verwenden. Allerdings lösen GETs nicht so viele Startaufgaben aus wie POSTs. Die bessere Option ist das Senden eines POST, der keine Änderungen per Commit an die Datenbank übergibt. Dies lässt sich am besten mit einem POST erreichen, der den GW-DoNotCommit-Header enthält. Dieser Header gibt an, dass durch die Anforderung vorgenommene Datenänderungen verworfen und nicht per Commit übergeben werden müssen.

Bewährte Verfahren zum Aufwärmen von Endpunkten

Jeder Endpunkt nutzt unterschiedliche Ressourcen. Zum Aufwärmen mehrerer Endpunkte benötigen Sie daher mehrere Anforderungen. Im Allgemeinen ist die effektivste Aufwärmanforderung eine zusammengesetzte Anforderung mit einer großen Anzahl von Unteranforderungen, die einen POST an jedem Endpunkt durchführen, den Sie aufwärmen möchten.

Dies kann z. B. eine zusammengesetzte Anforderung sein, bei der Sie eine unverifizierte Police erstellen und dann einen Schadenfall für diese Police. Dazu gehören auch POSTs für andere untergeordnete Objekte wie Kontakte, Vorfälle, Teilschäden und Serviceanfragen.

Bei der Ausführung einer GW-DoNotCommit-Anforderung ist der Antwortcode wie normal, z. B. 200 oder 201, auch wenn keine Daten per Commit übergeben werden. Aufrufende Anwendungen müssen darauf achten, dass keine anderen unerwünschten Nebenwirkungen aus der Aufwärmanforderung auftreten, z. B. Integrationspunkte, die versehentlich die Dummy-Daten an das nachgelagerte System senden.