Hi Chaitanya,
Many thanks for the suggestion.
However, unfortunately that by itself doesn't work for me.
The reason I have used JObject and then pulling out the "Value" attribute is because KeyVault returns the secret as a JSON response body within the RESTful call to retreive the secret from vault.
So , when I changed the set-variable line to
<set-variable name="processedSecret" value="@(((IResponse)context.Variables["cached-secret"]).Body.As<string>())" />
.. and then stored in cache (which is Azure Redis in my case) the value was stored (and retrieved) similar to below :
"\x18\x01\x00\x00\xda\x01\x94\x02\n\x91\x02{\"value\":\"fictonalcompany-secret-dev-cloudws07aa259c-43f1-4e3f-98ab-e3cc7d4422f8\",\"id\":\"https://dev-fictionalproduct-kv.vault.azure.net/secrets/apimSharedSecret/3ed1fafed7da4c3f98d160d7a14bd656\",\"attributes\":{\"enabled\":true,\"created\":1602681357,\"updated\":1602681357,\"recoveryLevel\":\"Purgeable\"}}
I also tested the cache store/retrieval in isolation (just to eliminate any confusion regarding the Keyvault value retrieval) by adding the following simple additional key/store line in the inbound policy as follows :
<cache-store-value key="d1" value="123456" duration="12000" />
The cache value stored from the above policy line , when examined in Redis was as follows :
"\x0b\x00\x00\x00\xda\x01\b\n\x06123456"
... it was stored in a key named 2_d1
So, it is clear to me that the external cache integration between APIM and Redis is somehow serializing even basic string values with this preamble/binary format/header preceding the actual value that the policy code is supposed to be storing in the cache.
It looks to me like the first two bytes are perhaps some indication of content length but I could be wrong.
The 0x18 , 0x01 that was generated when storing the longer (full JSON body) looks like some least significant byte, most significant byte encoding to indicate content length or offsets.
Also, I managed to deploy an API Management resource on my Azure subscription on the development pricing tier (which includes inbuilt cache - no need for Redis).
I verified that strings are stored in the internal cache as expected with no binary preamble/header bytes.
Though, interestingly the key name that I request when storing the value using <cache-store-value> always gets prefixed with 2_ so that appears to be a general API Management/Cache implementation behaviour.