CentraSite 10.5 | CentraSite User’s Guide | Runtime Governance | Run-Time Policy Management | Built-In Run-Time Actions Reference (CentraSite Business UI) | Built-in Actions for Run-Time Policies (CentraSite Business UI) | Service Result Cache
 
Service Result Cache
This action enables caching of the results of SOAP and REST API invocations based on the caching criteria that you define. If the Service Result Cache action is set for an API, Mediator enables caching for the API when the API is deployed using the information for the action received from CentraSite. You can define the elements for which the API responses are to be cached based on the criteria: HTTP Header, Path, or XPath Expression. You can also limit the values to store in the cache using a whitelist. And, for the elements that are stored in the cache, you can specify other parameters such as Time to Live (TTL) and maximum response payload size.
Note:
In the case of REST based APIs, caching is supported only for the results of the HTTP method GET and not for other methods. Service result cache is not supported for a JSON request in a REST based API but is supported for a JSON response.
Caching the results of an API request:
*Increases the throughput of the API call
*Improves the scalability of the API
Note:
We recommend the use of caching only for elements that do not require live data and state values.
Input Parameters
Configure Caching Based On
Select a caching criteria. Mediator uses this information to determine the request component that is the actual payload based on which the results of the API invocation are cached. The options are:
*HTTP Header Uses the HTTP header in the API request. You can use this criteria for REST based APIs that accept payloads only in HTTP format.
*Path Uses the entire invocation URL including the query parameter. This option is applicable mainly for REST based API requests that use the URL or path parameter as the payload.
*XPath Expression Uses the XPath expression in the API request. You can use this criteria for: SOAP based API requests whose payload is a SOAP envelope, and REST based API requests that accept payloads in XML format.
Header Name
(Only if you select HTTP Header).
Specifies the HTTP header name.
Namespace
(Only if you select XPath Expression).
(Optional). Specifies the namespace of the XPath expression:
*Prefix - The prefix for the namespace. For example, soapenv or axis
*URI - The namespace URI - For example, http://schemas.xmlsoap.org/soap/envelope/ or http://ws.apache.org/axis
XPath Expression
(Only if you select XPath Expression).
Specifies the XPath expression in the API request.
Add to Whitelist
(Only if you select HTTP Header or XPath Expression).
(Optional). Mediator caches the API responses only for requests whose cache criteria matches with the one set for the action, and whose criteria evaluation results in any one of the values in this list.
Time to Live
(Optional). Specifies the lifespan (Days Hours Minutes, for example: 5d 4h 1m) of the elements in the cache after which the elements are consider out-of-date.
Note:
The maximum value that you can set for the Time to Live (TTL) parameter is 24855 days (unlimited). If no value is specified, the TTL is unlimited (does not expire). If you set the TTL value to 0d 0h 0m, the API results are not cached.
Maximum Response Payload Size
Specifies the maximum payload size for the API in kilo bytes.
The value -1 stands for unlimited payload size.
Mediator uses the Ehcache capability provided by Integration Server to cache the results of the API calls. You can configure caching for a single Mediator node or for a cluster. For details on configuring Ehcache, see webMethods Integration Server Administrator’s Guide.
Recommendations and Best Practices for Service Result Caching
This section provides guidance on the use of caching for the results of an API request.
*Caching is not recommended in cases where consumers absolutely rely on current information retrieved from a back-end service.
*As caching occurs in memory, ensure that you are not operating in a memory constrained environment.
*Balance the memory consumption with the API response sizes. If your API returns huge responses or large binary attachments, limit caching by specifying the maximum size of the cache or by defining data eviction policies to avoid excessive memory consumption.
*Design the APIs for which you want to implement caching to be idempotent to support reliable caching.
*Configure a suitable value for the Time to Live (TTL) parameter for the cache entries based on your business needs and the use cases for your API.
For example, if your API serves static product catalog data which is only updated once a quarter select a large TTL value. If your API serves for example environmental data where a certain age of the data is tolerated, select a TTL value like 15 minutes.
Note:
A TTL value that you set in a standalone Mediator is reset if the Mediator restarts. For example, if you set 15 minutes as the TTL value of an element which is inserted after 10 minutes, and Mediator restarts. The element has a TTL value of 15 minutes after the Mediator is restarted.
*Caching of the results of an API call is recommended:
*If the response time of a direct query to the database is high or subject to high latencies, and if the data requested does not change frequently or is static.
*If the client applications can use slightly outdated, cached data. For example, a weather API can be supplied data from a cache which is an hour old.
*If there are temporary service interruptions on the server side, to mitigate these interruptions with data from the cache.
*If the API that requests data is subject to traffic management rules, usage quotas, or if billing is based on the number of calls to the API, you can overcome these by using cached data.
*Caching may not be effective or is not recommended:
*If the response of a direct request for data to the database is very fast and scaling is not an issue, using cached data may not provide additional benefits.
*If your API uses non-indempotent requests.