Copyright © Cloud Software Group, Inc. All Rights Reserved

Response Caching

TIBCO API Exchange Gateway can cache response messages from the target services. The response caching functionality is supported for HTTP(s)/REST and HTTP(s)/SOAP requests. To enable caching of response messages from the target services for any facade operation, see Enable Response Caching.

Response caching is supported by the CacheEnabled operation feature of TIBCO API Exchange Gateway. If the CacheEnabled keyword is specified in the Operation Feature and the caching is not explicitly configured on the Config UI for a facade operation, TIBCO API Exchange Gateway uses the default caching parameters as follows:

−	Cache Type: Simple Cache

−	Time To Live: 1 day (24 hours)

Types of Response Caching

The following types of response caching are supported:

Facade Response Cache (Simple Cache)

The Facade Response Cache is known as Simple Cache. If the Simple Cache type is enabled as response caching for a facade operation, the Core Engine processes the incoming facade requests as follows:

•	The Core Engine retrieves the response message from the cache for the matching cache response key for every facade request from the client.

•	If the response message is found in the cache and is not expired, the Core Engine sends the response message from the cache as the facade response message to the client.

•

If the response message is not found in the cache, the Core Engine forwards the facade request to the target operation and sends the response message from the target service to the client. The Core Engine stores the response message into the cache just before sending the response message to the client. This ensures that the response message is available in the cache for subsequent requests from the client. The Time to Live parameter specifies the duration of the response message in the cache.See Response Caching Parameters table.

•	If the response message in the cache for the same cache response key is expired, the Core Engine deletes the response message from cache and forwards the facade request to the target operation.

•

When the response message is received from the target service by the Core Engine for the first time, the Core Engine stores the response message including the headers in the cache using the cache response key. See Cache Response Key. For every subsequent requests from the client, the response from the cache is returned with all the response headers, similar to the response headers from the target service. The X-Cache: Hit in the response message header indicates that the response message is returned from the cache.

•	If the response from the target operation is an error, the Core Engine does not cache the response.

• When a response message is found in the cache for a facade operation request, the Core Engine adds the following header in the response message: X-Cache: Hit • If the HTTP header of the response message from the target service has a Cache Control header with either the no-cache or no-store directive, the response is not cached.

Sample Request Header

The following is the sample request header for the facade request with accept header:

---

 

<h:request xmlns:h="http://www.tibco.com/asg/protocols/http">

<h:server-ip>localhost</h:server-ip>

<h:server-port>9222</h:server-port>

<h:client-ip>0:0:0:0:0:0:0:1</h:client-ip>

<h:client-port>0</h:client-port>

<h:scheme>http</h:scheme>

<h:method>GET</h:method>

<h:request-uri>/Books/BookOperations/Title/The Power of Now</h:request-uri>

<h:protocol-version>HTTP/1.1</h:protocol-version>

<h:query-string/>

<h:header name="host">localhost:9222</h:header>

<h:header name="connection">keep-alive</h:header>

<h:header name="accept">

text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

</h:header>

---

 

 

Sample Response Headers

The following are sample response headers for the facade response caching type:

Sample Response Headers from Target Service

---

 

Access-Control-Allow-Origin: *

Date: Wed, 13 Aug 2014 20:59:06 GMT

Server: Apache-Coyote/1.1

Connection: Keep-Alive

Transfer-Encoding: chunked

Access-Control-Allow-Methods: GET, POST, DELETE, PUT

Content-Type: application/json;charset=ISO-8859-1

---

 

Sample Response Headers from Cached Response

---

 

Access-Control-Allow-Origin: *

Date: Wed, 13 Aug 2014 20:59:06 GMT

X-Cache: Hit

Server: Apache-Coyote/1.1

Connection: Keep-Alive

Transfer-Encoding: chunked

Access-Control-Allow-Methods: GET, POST, DELETE, PUT

Content-Type: application/json;charset=ISO-8859-1

---

 

Target Backup Response Cache

The Target Backup Response Cache is known as Backup Cache. The Target Backup Response Cache ensures that the response message is sent from the cache (if existing) to the client in case the response is not received from the target service within a time period.

If the response caching of Improve SLA type is enabled for a facade operation, the Core Engine processes the incoming facade request as follows:

•	The Core Engine routes the request to the appropriate target service.

•	The Core Engine sends the response message from the target service to the client if a successful response message is received.

•	The Core Engine stores the response message in the cache.

•	The Core Engine processes the subsequent requests from the client as follows:

−	For any request from the client, if the response from the target service is not received within a configured time period specified by the Short Wait Timer parameter, the Core Engine fetches the response message stored in the cache.

a.	If the response is found in the cache and is not expired, the Core Engine sends back the response message to the client.

b.	If the response is found in the cache and is expired, the Core Engine deletes the response from the cache and waits for the response message from the target service.

c.	If the response is not found in the cache, the Core Engine waits for the target service to respond and sends back the response to client when received. If the response message is not received from the target service, the Core Engine sends a timeout error to the client.

−	If the response message from the target operation is received after the specified time period, the Core Engine just updates the cached response message with the received response message.

Cache Response Key

TIBCO API Exchange Gateway uses the cache response key to check if a cached response exists in the cache for an incoming request.

By default, the Core Engine constructs the value of the cache response key for REST/HTTP requests using the following parameters:

routingKey+requestURI(minus the API Key)+Accept-Header+Soap Action

where,

•	Routing Key: when the routing key is added to the cache response key, this ensures that for each incoming request, the cached response is only returned for a particular routing key.

•	requestURI: this is the URI that contains the path and query parameters. The API key is removed from the URI.

•

Accept-Header: The Accept HTTP request-header may be used to pass a content-type preference to the target service. For example, a service may support an Accept-Header of application/xml or application/json to preferentially return the response message in XML or JSON format. For the purpose of caching, the request with Accept-Header of application/xml or application/json are managed as two separate requests. The Accept-Header is added to the cache response key as an additional discriminator.

For example, if a user requests the JSON data for a URI such as /Books/BookOperations/Title/Power , the cached response is only returned if the cache value has a JSON response for that URI in the cache.

•	Soap Action: specifies the SOAP Action header for a HTTP SOAP request used to construct the default cache response key.

For HTTP/REST and HTTP/SOAP requests, the Core Engine creates a default caching key using the above parameters..

You can override the default cache response key using the custom XSLT specified in the parsing step of a facade operation request. See Override Cache Response Key and Parameters on how to create a cache response key using XSLT.

Response Caching with Proxy Server

For the Proxy operation feature of TIBCO API Exchange Gateway, the response caching is supported as follows:

•	If the caching is explicitly configured for a facade operation on the Config UI, TIBCO API Exchange Gateway uses the Cache Type and other caching parameters such as Time To Live as configured for the facade operation.

•	If the caching is not explicitly configured for a facade operation on the Config UI, TIBCO API Exchange Gateway uses the default caching parameters, as follows:

−	Cache Type: Simple Cache

−	Time To Live: 1 day (24 hours)

Enable Response Caching

To enable the response caching for a facade operation request, follow these steps::

1.	Start the Config UI, if not running.

2.	Log in to the Config UI using your credentials.

3.	Add a new project or select an existing project under Projects.

4.	Click the ROUTING tab on the right-hand side.

5.	Click the Facade Operations tab.

6.	Select a facade operation to enable the response caching.

7.	Select the Enable Caching check box.

8.	Enter the parameters as explained in the Response Caching Parameters table.

Response Caching Parameters

The following table explains the parameters required for response caching:

Table 159 Response Caching Parameters

Parameter	Description
Cache Type	Specifies the type of the response caching. The possible values are: • Simple Cache • Backup Cache
Time To Live	Specifies the time (in milliseconds) that a response is retained in the cache. The default value is 86400000 (ms).
Short Wait Timer	• Specifies the time that the Core Engine waits for a response from the target operation before sending a response back from the cache. • This parameter is not applicable for Simple Cache response caching type.

Clear Cached Items

The cached messages are deleted after the time specified by Time To Live parameter. Start the Cache Cleanup Agent to clear the cached response messages as follows:

1.	Navigate to the ASG_HOME/bin directory.

2.	Type the following command:

On Windows platform,

./asg-engine.exe -u asg-cache-cleanup

On Unix platform,

asg-engine -u asg-cache-cleanup

Override Cache Response Key and Parameters

Using TIBCO API Exchange Gateway, you can override the following parameters for a specific facade operation request:

•	Cache Response Key

See Cache Response Key.

•	Cache Response Parameters

The Cache Response Key and Cache Response parameters can be overwritten using a custom XSLT file.

To overide the cache response key and cache response parameters, follow these tasks:

 

Task A Create XSLT File

Create an XSLT file with the following key types to specify the new values for the cache response. Refer to Sample XSLT File.

Table 160 Key Tags for XSLT File

KeyType	Description
CacheResponse_Key	Specifies the cache response key for a facade operation request used to check if a cached response exists for this request.
CacheResponse_ShortWait	Specifies the time that the Core Engine waits for a response from the target service before sending a response back from the cache.
CacheResponse_TTL	Specifies the time (in milliseconds) that a response is retained in the cache.

Task B Upload XSLT File

To upload the XSLT file, follow these steps:

1.	Start the Config UI, if not running.

2.	Log in to the Config UI using your credentials.

3.	Add a new project or select an existing project under Projects.

4.	Click the ROUTING tab on the right-hand side.

5.	Click the Facade Operations tab.

6.	Select a facade operation to enable the response caching.

7.	Upload the XSLT file in the New ProcessBody Transform field.

8.	Save the changes to your configuration.

If you copy the XSLT file to the ASG_CONFIG_HOME/ASGProjectConfig/xslt directory, select the XSLT file in the ProcessBody Transform field of the Facade Operations tab.

Sample XSLT File

The following is an example XSLT file which can be used to override the cache response key and response caching parameters:

---

 

<!-- The key used to check if a cached response exists for this request -->

<key type="CacheResponse_Key"><xsl:value-of select="$httpRequest/h:request/h:request-uri"/></key>

 

<!-- This is how long (in milliseconds) we wait for the response from the service before sending a cached response instead -->

<key type="CacheResponse_ShortWait">4000</key>

 

<!-- This is the time (in seconds) that the response will be retained in the cache -->

<key type="CacheResponse_TTL">50</key>

 

<!-- What caching semantics are applied?

simpleCache - return a value from cache if present, otherwise invoke service and put response in cache.

improveSLA - use a cached value if the service takes more than ShortWait ms to reply. Freshen value in cache with real response.

-->

<key type="xCacheResponse_Type">simpleCache</key>

---

 

Response Caching Example

Out of the box, TIBCO API Exchange Gateway provides a BookQueryBE example. By default ,the queryBookByTitle facade operation is enabled for simple cache response type.

Copyright © Cloud Software Group, Inc. All Rights Reserved