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:
- Loading Java and Gosu classes
- Parsing and loading configuration files that are lazy-loaded on the first reference
- Loading data from the database or other sources into local caches
- Initializing database connections
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 unverified policy, and then a claim for that policy. This would include POSTs to other child objects as well, such as contacts, incidents, exposures, and service requests.
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