Yes, you are missing something, though I don’t know exactly what.
You said
I am trying to cache the response only if one the query param is equal to a value
ok, good. The logic in the Skip elements seems to be the right idea. I don’t know why you chose to assign the value of the queryparam to “name12”. You can just reference the queryparam directly like request.queryparam.PositionName .
ok, now beyond that, you need to ATTACH the policy. You didn’t specify how you are attaching the policy so it’s possible you’ve got it wrong. The ResponseCache policy should be attached exactly twice: once in the request flow (preferably early in the request flow) and once in the response flow, AFTER the response has been assigned.
That’s it.
I have a loopback proxy bundle to illustrate. Find it attached below. This proxy doesn’t connect to anything, but it dynamically assigns a payload that looks like this:
{
"status" : "ok",
"key" : "/cache-skip-logic/c?action=cache",
"now" : "20181205 00:06:24.299"
}
The key is the request.uri. The “now” is a formatted timestamp string.
Inserting the ResponseCache policy once in the request flow, and once in the response flow, after that payload has been assigned, allows me to store and receive cached values. I have included these elements:
<SkipCacheLookup>request.queryparam.action != "cache"</SkipCacheLookup>
<SkipCachePopulation>request.queryparam.action != "cache"</SkipCachePopulation>
In other words, the cache is active if and only if there is a query param named “action” and its value is “cache”.
And this proxy behaves just as I would expect, consistent with the documentation:
| action queryparam |
cache status |
return cached data? |
populate cache? |
| not present |
warm |
no |
no |
| not present |
cold |
no |
no |
| =“cache” |
warm |
yes |
no |
| =“cache” |
cold |
no |
yes |
| !=“cache” |
warm |
no |
no |
| !=“cache” |
cold |
no |
no |
You MAY be running into an already-populated cache. This is a common pitfall when people are testing out the Apigee Edge cache. They fail to set a timeout in the ResponseCache policy, and as a result, the cache never expires.
<ExpirySettings>
<TimeoutInSec ref="flow.variable.here">20</TimeoutInSec>
</ExpirySettings>
To avoid that, include the expiry, and during testing, make the expiry relatively quick, like 10 or 20 seconds.
<ResponseCache name="Cache-1">
<CacheResource>cache1</CacheResource>
<CacheKey>
<Prefix>value</Prefix>
<KeyFragment ref='request.uri' />
</CacheKey>
<Scope>Exclusive</Scope>
<ExpirySettings>
<TimeoutInSec ref="flow.variable.here">20</TimeoutInSec>
</ExpirySettings>
<SkipCacheLookup>request.queryparam.action != "cache"</SkipCacheLookup>
<SkipCachePopulation>request.queryparam.action != "cache"</SkipCachePopulation>
</ResponseCache>
If the cache is already populated though, you will need to modify your policy to use a different cachekey, probably adding a unique prefix, so that you avoid the never-expiring cache entry. The prefix can be any fixed value.
Please find the working proxy attached. apiproxy-cache-skip-logic.zip
