エンドポイントのウォームアップ

呼び出し元のアプリケーションが Cloud API エンドポイントへの呼び出しを初めて実行する際は、通常よりも処理に時間がかかることがあります。これは、Guidewire サーバーが、以下のような初回呼び出しのタスクを実行する必要がある可能性があるためです。これらのタスクは初回以後のタスクで再び実行する必要はありません。

呼び出し元アプリケーションは、正規のビジネス呼び出しでこうした長時間処理が発生するのを回避することもできます。したがって、エンドポイントを「ウォームアップ」することも可能です。このためには、ダミーの「ウォームアップ要求」を送信して、これらの初回タスクをトリガします。このウォームアップ要求は、それ以降の要求のより迅速な実行に役立ちます。

ウォームアップ要求には、データの作成や変更は想定されていません。理論上、呼び出し元アプリケーションは GET をウォームアップ要求として使用できます。ただし、GET は POST ほどさまざまな起動タスクをトリガしません。これよりもよい選択肢は、データベースへの変更をコミットしない POST を送信することです。それには、GW-DoNotCommit ヘッダーを含む POST を使用する方法が最適です。このヘッダーは、要求が行うデータ変更は破棄され、コミットされないものと識別します。

エンドポイントのウォームアップのベストプラクティス

すべてのエンドポイントはさまざまなリソースを利用します。したがって、複数のエンドポイントをウォームアップするには、複数の要求が必要です。一般的に、最も効果的なウォームアップ要求は、ウォームアップしたい各エンドポイントに対して POST を実行する大量のサブ要求を含むコンポジット要求です。

例えば、未検証の保険契約を作成してから、その保険契約のクレームを作成するコンポジット要求などがあります。これには、連絡先、インシデント、エクスポージャー、およびサービス要求などのその他の子オブジェクトに対する POST も含まれます。

GW-DoNotCommit 要求を実行すると、データはコミットされないものの、応答コードは 200 や 201 など、通常と同じになります。呼び出し元アプリケーションは、ダミーデータをダウンストリームに意図せず送信する可能性がある連携ポイントなど、ウォームアップ要求のその他の望ましくない副作用が発生しないように注意する必要があります。