API Connect

Hi Malak,

I concur with Chris to get up to a supported release as I believe DataPower 10.0.1.x is out of support in a few months and as Chris noted API Connect is already out of support at that level.  From a gateway perspective I'm not aware of any changes in DataPower firmware between releases that would impact caching behavior.  The invoke policy provides caching policy options to cache a backend response.  See the cache related properties of the invoke policy at https://www.ibm.com/docs/en/api-connect/10.0.x?topic=invoke-configuring-policy-datapower-api-gateway.  From your APIs perspective, I don't believe you'll know that the response came from cache or from the backend.  Perhaps inspecting the Date response header to determine how latent the response is may give you a clue, assuming NTP of course has the systems' clocks in sync?  The cache is done by the backend url, so the response could be cached by one invoke policy and then read from cache by another invoke policy (may or may not be in the same API).  If you need to have the same backend url response cached separately, there is also a cache key property to provide that additional level of granularity.

Best Regards,

Steve

Hi Steve, Can we not access this cache key from a gateway script for more fine grain control? Cause I also face a similar issue where I can see my cache key in the datapower gateway documents status, however, I cannot tell if the gateway is actually using cache because I still see unnecessary calls to the downstream backend from gateway.

Hi Malak,

I concur with Chris to get up to a supported release as I believe DataPower 10.0.1.x is out of support in a few months and as Chris noted API Connect is already out of support at that level.  From a gateway perspective I'm not aware of any changes in DataPower firmware between releases that would impact caching behavior.  The invoke policy provides caching policy options to cache a backend response.  See the cache related properties of the invoke policy at https://www.ibm.com/docs/en/api-connect/10.0.x?topic=invoke-configuring-policy-datapower-api-gateway.  From your APIs perspective, I don't believe you'll know that the response came from cache or from the backend.  Perhaps inspecting the Date response header to determine how latent the response is may give you a clue, assuming NTP of course has the systems' clocks in sync?  The cache is done by the backend url, so the response could be cached by one invoke policy and then read from cache by another invoke policy (may or may not be in the same API).  If you need to have the same backend url response cached separately, there is also a cache key property to provide that additional level of granularity.

Best Regards,

Steve

Hi Olamide,
I apologize for missing your question and not responding sooner.  This cache key does provide you more granular control than just the backend url.  For example, a backend url that is returning a response for a particular product could use the product id as the key and the data would be cashed using the backend url and the additional key, effectively giving you many cache entries for the same url but with different keys.  The subsequent backend call would need to use that same key and if it is in the document cache it should retrieve it.  Are you sure the subsequent call is using the correct key? What about your cache size and number of documents? Is there any chance that these are too small, resulting in cache entries being discarded by other calls which would then require another backend call to get this particular response back in cache?
Regards,

Steve

Hi Steve, Can we not access this cache key from a gateway script for more fine grain control? Cause I also face a similar issue where I can see my cache key in the datapower gateway documents status, however, I cannot tell if the gateway is actually using cache because I still see unnecessary calls to the downstream backend from gateway.

Hi Malak,

I concur with Chris to get up to a supported release as I believe DataPower 10.0.1.x is out of support in a few months and as Chris noted API Connect is already out of support at that level.  From a gateway perspective I'm not aware of any changes in DataPower firmware between releases that would impact caching behavior.  The invoke policy provides caching policy options to cache a backend response.  See the cache related properties of the invoke policy at https://www.ibm.com/docs/en/api-connect/10.0.x?topic=invoke-configuring-policy-datapower-api-gateway.  From your APIs perspective, I don't believe you'll know that the response came from cache or from the backend.  Perhaps inspecting the Date response header to determine how latent the response is may give you a clue, assuming NTP of course has the systems' clocks in sync?  The cache is done by the backend url, so the response could be cached by one invoke policy and then read from cache by another invoke policy (may or may not be in the same API).  If you need to have the same backend url response cached separately, there is also a cache key property to provide that additional level of granularity.

Best Regards,

Steve

Hi Steve,

Apologies for responding late. Yes I am sure the subsequent call is using the correct key. The cache config is also correct because i can correctly see the cache in my DP Documents status. However, My main concern is around granular control via a gateway script. Via a gateway script, can I check if a cache exists? can i do sth with a cache value? As an enterprise gateway, it should be possible to do these common tasks right. 

Hi Olamide,
I apologize for missing your question and not responding sooner.  This cache key does provide you more granular control than just the backend url.  For example, a backend url that is returning a response for a particular product could use the product id as the key and the data would be cashed using the backend url and the additional key, effectively giving you many cache entries for the same url but with different keys.  The subsequent backend call would need to use that same key and if it is in the document cache it should retrieve it.  Are you sure the subsequent call is using the correct key? What about your cache size and number of documents? Is there any chance that these are too small, resulting in cache entries being discarded by other calls which would then require another backend call to get this particular response back in cache?
Regards,

Steve

Hi Steve, Can we not access this cache key from a gateway script for more fine grain control? Cause I also face a similar issue where I can see my cache key in the datapower gateway documents status, however, I cannot tell if the gateway is actually using cache because I still see unnecessary calls to the downstream backend from gateway.

Hi Malak,

I concur with Chris to get up to a supported release as I believe DataPower 10.0.1.x is out of support in a few months and as Chris noted API Connect is already out of support at that level.  From a gateway perspective I'm not aware of any changes in DataPower firmware between releases that would impact caching behavior.  The invoke policy provides caching policy options to cache a backend response.  See the cache related properties of the invoke policy at https://www.ibm.com/docs/en/api-connect/10.0.x?topic=invoke-configuring-policy-datapower-api-gateway.  From your APIs perspective, I don't believe you'll know that the response came from cache or from the backend.  Perhaps inspecting the Date response header to determine how latent the response is may give you a clue, assuming NTP of course has the systems' clocks in sync?  The cache is done by the backend url, so the response could be cached by one invoke policy and then read from cache by another invoke policy (may or may not be in the same API).  If you need to have the same backend url response cached separately, there is also a cache key property to provide that additional level of granularity.

Best Regards,

Steve

Hi Olamide,
Perhaps I'm misunderstanding your issue, so let me restate it as I understand it and you can correct me if I'm wrong.
1. You have in your DP document status entries that have been cached using a cache key in addition to the backend url.  May I assume that you're getting those entries into the cache by using an API Connect invoke policy where the cache key (and perhaps other caching properties) was specified?
2. In a separate GatewayScript policy, you're doing a urlopen.open to the same backend, and you're looking for a mechanism to specify the cache key so you get a response from cache instead of going to the backend server?  If so, within your GatewayScript code, are you setting up var://service/cache/dynamic-policies? See the documentation on this variable at https://www.ibm.com/docs/en/datapower-gateway/10.5.x?topic=variables-varservicecachedynamic-policies.  I believe that the invoke policy uses this service variable under the covers to provide the cache information for the cache key and other cache properties provided on the invoke policy, but only for the duration of the invoke policy.  If you want to specify this within your own GatewayScript, you'll need to set this variable before your urlopen.open, and if you don't reset it before your code completes, then that dynamic property will be available for the duration of the transaction unless it is reset by some other policy, perhaps another invoke.  To reset it, you need to set this service variable to a value which removes any child elements, ie sm.setVar('var://service/cache/dynamic-policies', '<dcp:caching-policies xmlns:dcp="http://www.datapower.com/schemas/caching"/>');

As for querying the document cache status, the status provider enumeration service variable is the only mechanism, but I would strongly caution against using it under any transaction load for performance and appliance resource reasons.  If your issue is related to the cache service variable allowing you to set the key, then your urlopen.open should get the response from cache without hitting your backend server if you'd set up the service variable properly.  However, as far as your code is concerned, I don't believe you will have any indication in the response that the response came from the real backend server or cache.

Please let me know if I understand your use case and concerns correctly.

Regards,
Steve

Hi Steve,

Apologies for responding late. Yes I am sure the subsequent call is using the correct key. The cache config is also correct because i can correctly see the cache in my DP Documents status. However, My main concern is around granular control via a gateway script. Via a gateway script, can I check if a cache exists? can i do sth with a cache value? As an enterprise gateway, it should be possible to do these common tasks right. 

Hi Olamide,
I apologize for missing your question and not responding sooner.  This cache key does provide you more granular control than just the backend url.  For example, a backend url that is returning a response for a particular product could use the product id as the key and the data would be cashed using the backend url and the additional key, effectively giving you many cache entries for the same url but with different keys.  The subsequent backend call would need to use that same key and if it is in the document cache it should retrieve it.  Are you sure the subsequent call is using the correct key? What about your cache size and number of documents? Is there any chance that these are too small, resulting in cache entries being discarded by other calls which would then require another backend call to get this particular response back in cache?
Regards,

Steve

Hi Steve, Can we not access this cache key from a gateway script for more fine grain control? Cause I also face a similar issue where I can see my cache key in the datapower gateway documents status, however, I cannot tell if the gateway is actually using cache because I still see unnecessary calls to the downstream backend from gateway.

Hi Malak,

I concur with Chris to get up to a supported release as I believe DataPower 10.0.1.x is out of support in a few months and as Chris noted API Connect is already out of support at that level.  From a gateway perspective I'm not aware of any changes in DataPower firmware between releases that would impact caching behavior.  The invoke policy provides caching policy options to cache a backend response.  See the cache related properties of the invoke policy at https://www.ibm.com/docs/en/api-connect/10.0.x?topic=invoke-configuring-policy-datapower-api-gateway.  From your APIs perspective, I don't believe you'll know that the response came from cache or from the backend.  Perhaps inspecting the Date response header to determine how latent the response is may give you a clue, assuming NTP of course has the systems' clocks in sync?  The cache is done by the backend url, so the response could be cached by one invoke policy and then read from cache by another invoke policy (may or may not be in the same API).  If you need to have the same backend url response cached separately, there is also a cache key property to provide that additional level of granularity.

Best Regards,

Steve

Thank you Steve. You understand me correctly for Point 1 above. And based on your response above, it looks like the Gateway has a limitation when it comes to the indication whether a response came from cache or backend service. In that case, do you think we can get a value from a cache-key directly without using urlopen.open to get backend response directly? e.g sm.getVar('cache-key') leveraging service variables similarly to the way you described above if possible.

Hi Olamide,
Perhaps I'm misunderstanding your issue, so let me restate it as I understand it and you can correct me if I'm wrong.
1. You have in your DP document status entries that have been cached using a cache key in addition to the backend url.  May I assume that you're getting those entries into the cache by using an API Connect invoke policy where the cache key (and perhaps other caching properties) was specified?
2. In a separate GatewayScript policy, you're doing a urlopen.open to the same backend, and you're looking for a mechanism to specify the cache key so you get a response from cache instead of going to the backend server?  If so, within your GatewayScript code, are you setting up var://service/cache/dynamic-policies? See the documentation on this variable at https://www.ibm.com/docs/en/datapower-gateway/10.5.x?topic=variables-varservicecachedynamic-policies.  I believe that the invoke policy uses this service variable under the covers to provide the cache information for the cache key and other cache properties provided on the invoke policy, but only for the duration of the invoke policy.  If you want to specify this within your own GatewayScript, you'll need to set this variable before your urlopen.open, and if you don't reset it before your code completes, then that dynamic property will be available for the duration of the transaction unless it is reset by some other policy, perhaps another invoke.  To reset it, you need to set this service variable to a value which removes any child elements, ie sm.setVar('var://service/cache/dynamic-policies', '<dcp:caching-policies xmlns:dcp="http://www.datapower.com/schemas/caching"/>');

As for querying the document cache status, the status provider enumeration service variable is the only mechanism, but I would strongly caution against using it under any transaction load for performance and appliance resource reasons.  If your issue is related to the cache service variable allowing you to set the key, then your urlopen.open should get the response from cache without hitting your backend server if you'd set up the service variable properly.  However, as far as your code is concerned, I don't believe you will have any indication in the response that the response came from the real backend server or cache.

Please let me know if I understand your use case and concerns correctly.

Regards,
Steve

Hi Steve,

Apologies for responding late. Yes I am sure the subsequent call is using the correct key. The cache config is also correct because i can correctly see the cache in my DP Documents status. However, My main concern is around granular control via a gateway script. Via a gateway script, can I check if a cache exists? can i do sth with a cache value? As an enterprise gateway, it should be possible to do these common tasks right. 

Hi Olamide,
I apologize for missing your question and not responding sooner.  This cache key does provide you more granular control than just the backend url.  For example, a backend url that is returning a response for a particular product could use the product id as the key and the data would be cashed using the backend url and the additional key, effectively giving you many cache entries for the same url but with different keys.  The subsequent backend call would need to use that same key and if it is in the document cache it should retrieve it.  Are you sure the subsequent call is using the correct key? What about your cache size and number of documents? Is there any chance that these are too small, resulting in cache entries being discarded by other calls which would then require another backend call to get this particular response back in cache?
Regards,

Steve

Hi Steve, Can we not access this cache key from a gateway script for more fine grain control? Cause I also face a similar issue where I can see my cache key in the datapower gateway documents status, however, I cannot tell if the gateway is actually using cache because I still see unnecessary calls to the downstream backend from gateway.

Hi Malak,

I concur with Chris to get up to a supported release as I believe DataPower 10.0.1.x is out of support in a few months and as Chris noted API Connect is already out of support at that level.  From a gateway perspective I'm not aware of any changes in DataPower firmware between releases that would impact caching behavior.  The invoke policy provides caching policy options to cache a backend response.  See the cache related properties of the invoke policy at https://www.ibm.com/docs/en/api-connect/10.0.x?topic=invoke-configuring-policy-datapower-api-gateway.  From your APIs perspective, I don't believe you'll know that the response came from cache or from the backend.  Perhaps inspecting the Date response header to determine how latent the response is may give you a clue, assuming NTP of course has the systems' clocks in sync?  The cache is done by the backend url, so the response could be cached by one invoke policy and then read from cache by another invoke policy (may or may not be in the same API).  If you need to have the same backend url response cached separately, there is also a cache key property to provide that additional level of granularity.

Best Regards,

Steve

Hi Olamide,
First I wouldn't necessarily consider that the urlopen.open does not know if the response came from cache or from the actual backend server to be a product limitation.  You're getting that response for a reason, presumably to inspect the response, perhaps make changes to it, before making it available to either a subsequent policy or to be sent to the end user.  Whether the response came from cache shouldn't matter in that the response will be the same in either case, just faster and without burdening the backend every time if it came from the cache.  You can always open an enhancement request if you feel this information would be useful, but from my own experience, the only time I've needed something like this capability was when I was writing system tests to ensure that caching was working properly, but since this capability wasn't available, I used the time stamp in the response payload where I could see that both requests had the identical timestamp and if so the 2nd request had to come from the cache.

The cache-key is nothing more than additional metadata to form the eventual key used to cache the response.   It can be used to ensure uniqueness across many requests using the same backend url.  I'm still not 100% sure what you're asking, but if what you're asking is if the same cache key that was used in the invoke policy of your API transaction could also be used by a GatewayScript policy with a urlopen.open function within the same transaction, you could set an APIGW context variable, either with a setvariable policy or within code using a context function such as the GatewayScript context.set('myKey', 'Steve'); and then in the invoke policy, for your cache key, specify $(myKey) and the variable substitution would take place and the invoke policy would use the variable value as the cache key. Then in your GatewayScript code, you could specify a context.get('myKey') to get the value of Steve which could be used to setup var://service/cache/dynamic-policies so the urlopen.open would use the same cache key as the invoke policy used and so it would pull that response from cache.  Still, if you're really going to the same backend in the same transaction, why not save the invoke response in a unique context via the invoke output property and just use it later in responseOutput.body and not worry about a urlopen to go through the cache in the first place?  The backend response would still be cached by the invoke for use by subsequent transactions.  If instead you're asking about different APIs, I don't believe that is going to be possible.  You will need some type of persisted metadata used in both apis, perhaps an API property that each API would specify the same value, to ensure that the same key was being used in both APIs.

If I'm still not understanding the requirement, please let me know.

Regards,

Steve

Thank you Steve. You understand me correctly for Point 1 above. And based on your response above, it looks like the Gateway has a limitation when it comes to the indication whether a response came from cache or backend service. In that case, do you think we can get a value from a cache-key directly without using urlopen.open to get backend response directly? e.g sm.getVar('cache-key') leveraging service variables similarly to the way you described above if possible.

Hi Olamide,
Perhaps I'm misunderstanding your issue, so let me restate it as I understand it and you can correct me if I'm wrong.
1. You have in your DP document status entries that have been cached using a cache key in addition to the backend url.  May I assume that you're getting those entries into the cache by using an API Connect invoke policy where the cache key (and perhaps other caching properties) was specified?
2. In a separate GatewayScript policy, you're doing a urlopen.open to the same backend, and you're looking for a mechanism to specify the cache key so you get a response from cache instead of going to the backend server?  If so, within your GatewayScript code, are you setting up var://service/cache/dynamic-policies? See the documentation on this variable at https://www.ibm.com/docs/en/datapower-gateway/10.5.x?topic=variables-varservicecachedynamic-policies.  I believe that the invoke policy uses this service variable under the covers to provide the cache information for the cache key and other cache properties provided on the invoke policy, but only for the duration of the invoke policy.  If you want to specify this within your own GatewayScript, you'll need to set this variable before your urlopen.open, and if you don't reset it before your code completes, then that dynamic property will be available for the duration of the transaction unless it is reset by some other policy, perhaps another invoke.  To reset it, you need to set this service variable to a value which removes any child elements, ie sm.setVar('var://service/cache/dynamic-policies', '<dcp:caching-policies xmlns:dcp="http://www.datapower.com/schemas/caching"/>');

As for querying the document cache status, the status provider enumeration service variable is the only mechanism, but I would strongly caution against using it under any transaction load for performance and appliance resource reasons.  If your issue is related to the cache service variable allowing you to set the key, then your urlopen.open should get the response from cache without hitting your backend server if you'd set up the service variable properly.  However, as far as your code is concerned, I don't believe you will have any indication in the response that the response came from the real backend server or cache.

Please let me know if I understand your use case and concerns correctly.

Regards,
Steve

Hi Steve,

Apologies for responding late. Yes I am sure the subsequent call is using the correct key. The cache config is also correct because i can correctly see the cache in my DP Documents status. However, My main concern is around granular control via a gateway script. Via a gateway script, can I check if a cache exists? can i do sth with a cache value? As an enterprise gateway, it should be possible to do these common tasks right. 

Hi Olamide,
I apologize for missing your question and not responding sooner.  This cache key does provide you more granular control than just the backend url.  For example, a backend url that is returning a response for a particular product could use the product id as the key and the data would be cashed using the backend url and the additional key, effectively giving you many cache entries for the same url but with different keys.  The subsequent backend call would need to use that same key and if it is in the document cache it should retrieve it.  Are you sure the subsequent call is using the correct key? What about your cache size and number of documents? Is there any chance that these are too small, resulting in cache entries being discarded by other calls which would then require another backend call to get this particular response back in cache?
Regards,

Steve

Hi Steve, Can we not access this cache key from a gateway script for more fine grain control? Cause I also face a similar issue where I can see my cache key in the datapower gateway documents status, however, I cannot tell if the gateway is actually using cache because I still see unnecessary calls to the downstream backend from gateway.

Hi Malak,

I concur with Chris to get up to a supported release as I believe DataPower 10.0.1.x is out of support in a few months and as Chris noted API Connect is already out of support at that level.  From a gateway perspective I'm not aware of any changes in DataPower firmware between releases that would impact caching behavior.  The invoke policy provides caching policy options to cache a backend response.  See the cache related properties of the invoke policy at https://www.ibm.com/docs/en/api-connect/10.0.x?topic=invoke-configuring-policy-datapower-api-gateway.  From your APIs perspective, I don't believe you'll know that the response came from cache or from the backend.  Perhaps inspecting the Date response header to determine how latent the response is may give you a clue, assuming NTP of course has the systems' clocks in sync?  The cache is done by the backend url, so the response could be cached by one invoke policy and then read from cache by another invoke policy (may or may not be in the same API).  If you need to have the same backend url response cached separately, there is also a cache key property to provide that additional level of granularity.

Best Regards,

Steve

Hi Steve,

I think you understand the problem but just a little of out of context. Let's forget about Url.Open for a second. Let me use a Pseudocode to explain this:

1. Use invoke policy to connect to an endpoint on Service:

# Service A             - invoke:                    title: invoke some endpoint                    timeout: 60                    verb: GET                    cache-response: protocol                    cache-key: my-cache-key                    stop-on-error: []                    version: 1.5.0                    target-url: '{{{TARGET_URL}}}'                    output: response

// Service Bconst apim = require('apim');//check if cache key exists. I don't want to call a backend serviceconst myCacheKey = apim.get('my-cache-key');if(myCacheKey ){// do sth with a valuelet setCacheFlag = myCacheKey.body.flag;}else{//my-cache-key does not exist. skipping further operations. //don't call any backend service, just terminate this script.}

Hi Olamide,
First I wouldn't necessarily consider that the urlopen.open does not know if the response came from cache or from the actual backend server to be a product limitation.  You're getting that response for a reason, presumably to inspect the response, perhaps make changes to it, before making it available to either a subsequent policy or to be sent to the end user.  Whether the response came from cache shouldn't matter in that the response will be the same in either case, just faster and without burdening the backend every time if it came from the cache.  You can always open an enhancement request if you feel this information would be useful, but from my own experience, the only time I've needed something like this capability was when I was writing system tests to ensure that caching was working properly, but since this capability wasn't available, I used the time stamp in the response payload where I could see that both requests had the identical timestamp and if so the 2nd request had to come from the cache.

The cache-key is nothing more than additional metadata to form the eventual key used to cache the response.   It can be used to ensure uniqueness across many requests using the same backend url.  I'm still not 100% sure what you're asking, but if what you're asking is if the same cache key that was used in the invoke policy of your API transaction could also be used by a GatewayScript policy with a urlopen.open function within the same transaction, you could set an APIGW context variable, either with a setvariable policy or within code using a context function such as the GatewayScript context.set('myKey', 'Steve'); and then in the invoke policy, for your cache key, specify $(myKey) and the variable substitution would take place and the invoke policy would use the variable value as the cache key. Then in your GatewayScript code, you could specify a context.get('myKey') to get the value of Steve which could be used to setup var://service/cache/dynamic-policies so the urlopen.open would use the same cache key as the invoke policy used and so it would pull that response from cache.  Still, if you're really going to the same backend in the same transaction, why not save the invoke response in a unique context via the invoke output property and just use it later in responseOutput.body and not worry about a urlopen to go through the cache in the first place?  The backend response would still be cached by the invoke for use by subsequent transactions.  If instead you're asking about different APIs, I don't believe that is going to be possible.  You will need some type of persisted metadata used in both apis, perhaps an API property that each API would specify the same value, to ensure that the same key was being used in both APIs.

If I'm still not understanding the requirement, please let me know.

Regards,

Steve

Thank you Steve. You understand me correctly for Point 1 above. And based on your response above, it looks like the Gateway has a limitation when it comes to the indication whether a response came from cache or backend service. In that case, do you think we can get a value from a cache-key directly without using urlopen.open to get backend response directly? e.g sm.getVar('cache-key') leveraging service variables similarly to the way you described above if possible.

Hi Olamide,
Perhaps I'm misunderstanding your issue, so let me restate it as I understand it and you can correct me if I'm wrong.
1. You have in your DP document status entries that have been cached using a cache key in addition to the backend url.  May I assume that you're getting those entries into the cache by using an API Connect invoke policy where the cache key (and perhaps other caching properties) was specified?
2. In a separate GatewayScript policy, you're doing a urlopen.open to the same backend, and you're looking for a mechanism to specify the cache key so you get a response from cache instead of going to the backend server?  If so, within your GatewayScript code, are you setting up var://service/cache/dynamic-policies? See the documentation on this variable at https://www.ibm.com/docs/en/datapower-gateway/10.5.x?topic=variables-varservicecachedynamic-policies.  I believe that the invoke policy uses this service variable under the covers to provide the cache information for the cache key and other cache properties provided on the invoke policy, but only for the duration of the invoke policy.  If you want to specify this within your own GatewayScript, you'll need to set this variable before your urlopen.open, and if you don't reset it before your code completes, then that dynamic property will be available for the duration of the transaction unless it is reset by some other policy, perhaps another invoke.  To reset it, you need to set this service variable to a value which removes any child elements, ie sm.setVar('var://service/cache/dynamic-policies', '<dcp:caching-policies xmlns:dcp="http://www.datapower.com/schemas/caching"/>');

As for querying the document cache status, the status provider enumeration service variable is the only mechanism, but I would strongly caution against using it under any transaction load for performance and appliance resource reasons.  If your issue is related to the cache service variable allowing you to set the key, then your urlopen.open should get the response from cache without hitting your backend server if you'd set up the service variable properly.  However, as far as your code is concerned, I don't believe you will have any indication in the response that the response came from the real backend server or cache.

Please let me know if I understand your use case and concerns correctly.

Regards,
Steve

Hi Steve,

Apologies for responding late. Yes I am sure the subsequent call is using the correct key. The cache config is also correct because i can correctly see the cache in my DP Documents status. However, My main concern is around granular control via a gateway script. Via a gateway script, can I check if a cache exists? can i do sth with a cache value? As an enterprise gateway, it should be possible to do these common tasks right. 

Hi Olamide,
I apologize for missing your question and not responding sooner.  This cache key does provide you more granular control than just the backend url.  For example, a backend url that is returning a response for a particular product could use the product id as the key and the data would be cashed using the backend url and the additional key, effectively giving you many cache entries for the same url but with different keys.  The subsequent backend call would need to use that same key and if it is in the document cache it should retrieve it.  Are you sure the subsequent call is using the correct key? What about your cache size and number of documents? Is there any chance that these are too small, resulting in cache entries being discarded by other calls which would then require another backend call to get this particular response back in cache?
Regards,

Steve

Hi Steve, Can we not access this cache key from a gateway script for more fine grain control? Cause I also face a similar issue where I can see my cache key in the datapower gateway documents status, however, I cannot tell if the gateway is actually using cache because I still see unnecessary calls to the downstream backend from gateway.

Hi Malak,

I concur with Chris to get up to a supported release as I believe DataPower 10.0.1.x is out of support in a few months and as Chris noted API Connect is already out of support at that level.  From a gateway perspective I'm not aware of any changes in DataPower firmware between releases that would impact caching behavior.  The invoke policy provides caching policy options to cache a backend response.  See the cache related properties of the invoke policy at https://www.ibm.com/docs/en/api-connect/10.0.x?topic=invoke-configuring-policy-datapower-api-gateway.  From your APIs perspective, I don't believe you'll know that the response came from cache or from the backend.  Perhaps inspecting the Date response header to determine how latent the response is may give you a clue, assuming NTP of course has the systems' clocks in sync?  The cache is done by the backend url, so the response could be cached by one invoke policy and then read from cache by another invoke policy (may or may not be in the same API).  If you need to have the same backend url response cached separately, there is also a cache key property to provide that additional level of granularity.

Best Regards,

Steve