if there is a management API to do something like a KVM operations PUT for any KVM or some other way to mimic the PUT.
Confirming: there is none.
I can try 5 minutes, won’t that lead to - one call every 5 minutes to be slower and also open up a 5 minute window where we can have errors due to the old value read from the cache?
Well it depends on what you update the KVM value to. Let’s suppose the item in the KVM is an identifier to … something. A discount code, a marketing program. The set of possible identifiers is: {X123, Y456}. In my scenario, when the value in the KVM entry is X123, then the API Proxy retrieves that value, then calls a SErviceCallout with the value X123 in the request, and receives back… something… through which the API Proxy operationalizes further flow.
Now you update the KVM to hold Y456. Before the cache is refreshed, the KVM Cache still contains X123. So the ServiceCallout is sent out with the value X123. We can design the system to continue to work, even though the KVM backing store has been updated, if the remote service gives a valid answer for X123. Eventually (5 minutes?) the KVM Cache gets refreshed and the ServiceCallout gets sent out with Y456. And the response from that is also valid. So all is good. There were no errors in the API Proxy.
I am not sure if I followed the second approach you suggested.
Let me try explaining again. I think it may be useful for you.
Let the KVM have these values at time T0:
| key |
value |
| currentCredId |
ABC123 |
| cred__ABC123 |
{“any” : “json”, “here” : true } |
| cred__DEF780 |
{“any” : “different json”, “here” : true } |
Now the API Proxy is running. It has a KVM policy like this:
<KeyValueMapOperations name='KVM-GetCurrent' mapIdentifier='map1'>
<Scope>environment</Scope>
<ExpiryTimeInSecs>300</ExpiryTimeInSecs>
<Get assignTo='currentCredId' >
<Key>
<Parameter>currentCredId</Parameter>
</Key>
</Get>
</KeyValueMapOperations>
After this executes, the context variable currentCredId holds “ABC123”. Then there is a second KVM policy like this:
<KeyValueMapOperations name='KVM-GetCred' mapIdentifier='map1'>
<Scope>environment</Scope>
<ExpiryTimeInSecs>300</ExpiryTimeInSecs>
<Get assignTo='cred'>
<Key>
<Parameter>cred</Parameter>
<Parameter ref='currentCredId'/>
</Key>
</Get>
</KeyValueMapOperations>
<br>
After this policy executes, “cred” holds the Json {“any” : “json”, “here” : true }
At time T1, you update the KVM store (via the mgmt API or UI) to be
| key |
value |
| currentCredId |
DEF789 |
| cred__ABC123 |
{“any” : “json”, “here” : true } |
| cred__DEF780 |
{“any” : “different json”, “here” : true } |
Notice the currentCredId has been updated. And as you know, the KVM policies continue to retrieve the value in their hot cache, which is ABC123. At some point at time T2, the entries in that hot cache expire and the policies begin to read the new data. At which point currentCredId will hold DEF789 and the cred variable will hold {“any” : “different json”, “here” : true }
There is no need for any “error”. Your APIs will just get updated data when they get updated data.
]