Which part? The documentation regarding Scope is here.
What i mean by "include the product name in the keys"... The Key-Value map stores values, against keys. BAsically its a table of keys and their values.
|
key
|
value
|
|
A
|
Alligator
|
|
B
|
Banana
|
|
C
|
Carousel
|
|
...
|
...
|
This storage structure allows you to lookup "A" and get the value "Alligator".
OK that's not very useful in the context of an API proxy, but it illustrates the point.
How about a more apt example in the API proxy realm? Maybe looking up ... target URIs for a given client. Remember in Apigee, the "client" is the app that is running remotely and is sending in requests. It's an app that runs on a mobile phone, a hardened mobile device, a point-of-sale terminal, a headless app running on a server, and so on.
Suppose you have the scenario in which you are modifying your target servers, maybe you are migrating them from an On-premises datacenter to a cloud VM. And in the process you are refactoring the code in that service, so that it behaves slightly differently. The goal is to make the transition completely backward compatible, but you're not sure about the performance characteristics of the refactored system.
So you want to use Apigee as a "switch", a router, that directs most of the inbound requests to the existing, stable, on-prem service, and some portion of the inbound requests to the new, refactored service running in the cloud. Apigee can do that sort of thing by setting target.url dynamically.
But you don't want to do a random 95/5 split. Instead, just initially, you want to direct load comping from ... maybe an "experimental" client, or a "test client" into then ew service
So within Apigee the logic is:
- verify the client credential (probably an OAuth token)
- based on that client, lookup the target URL
- proxy to the preferred target URL for that client.
OK, now how are you going to differentiate the "experimental" client from all the other clients. Not based on clientid, that isn't a good plan. Instead you could do it based on product name.
Product1 = the mainstream product. Almost All clients use this. To be more precise, the clients embed app credentials (keys, secrets) that are authorized for Product1.
Product1a = the experimental product. This is the new product. Only the experimental clients use this product. It wraps the same set of API Proxies as does Product1.
At runtime, after verifying the client credential, the Apigee runtime loads into the context a set of variables containing information about the app, the developer, and the product. One of those variables is "apiproduct.name" .
Which means, you could have a KVM like this:
One of the nice things about KVM in Apigee is that the keys themselves can be composite values: they combine multiple things. So what I'm showing there is a set of keys that are the composition of the product name and the fixed string "targeturl".
To get the value out, you can use a KVM policy like this:
<KeyValueMapOperations name='KVM-1' mapIdentifier='nameOfMap'>
<Scope>environment</Scope>
<ExpiryTimeInSecs>120</ExpiryTimeInSecs>
<Get assignTo='target.url'>
<Key>
<Parameter ref='apiproduct.name'/>
<Parameter>targeturl</Parameter>
</Key>
</Get>
</KeyValueMapOperations>
And the result of that ^^ policy is to set into the context variable 'target.url' the value corresponding to whichever entry in the table corresponds to the right product.
Does this help clarify?
LinkedIn
Twitter
