Warming up an endpoint

The first time a caller application makes a call to a Cloud API endpoint, the call may take longer to process than normal. This is because the Guidewire server may need to execute tasks for the first call that it does not need to re-execute for subsequent tasks, such as:

A caller application may want to avoid having this slow processing time occur during a genuine business call. Therefore, the caller application may want to "warm up" the endpoint. This involves sending a dummy "warm-up request" to trigger these initial tasks. The warm-up request helps subsequent requests execute more rapidly.

Warm-up requests are not supposed to create or modify data. Theoretically, a caller application could use a GET as a warm-up request. However, GETs do not trigger as wide a range of start-up tasks as POSTs. The better option is to send a POST that does not commit any changes to the database. The best way to accomplish this is with a POST that contains the GW-DoNotCommit header. This header identifies that data modifications made by the request are to be discarded and not committed.

Best practices for warming up endpoints

Every endpoint makes use of different resources. Therefore, to warm up multiple endpoints, you need multiple requests. In general, the most effective warm-up request is a composite request with a large number of subrequests that POST to each endpoint you want to warm up.

For example, this could be a composite request where you create an account, and then a submission for the account, which you then quote and bind. This would include POSTs to other child objects as well, such as contacts, locations, coverages, and documents.

When executing a GW-DoNotCommit request, the response code will be the same as normal, such as 200 or 201, even though no data is committed. Caller applications need to be careful to ensure that there are no other undesired side effects from the warm-up request, such as integration points that might inadvertently send the dummy data downstream.