KVM Variables are not getting assigned.

Hi All,

I was implementing KVMs in my proxy. I've manually added Key-Value pairs using administrative APIs using cloud terminal. PFB for reference.

Image1Image1

But During runtime, the values are not showing up in the traces and not getting appended with the variables assigned.

image2image2

Could someone help, please?

Thanks,
Manoj.

1 2 159
2 REPLIES 2

Sure I can try to help. Please show the KVM step configuration. I see from the trace, that It seems the step is reading? variables like Genesys_UrlForLogin , Genesys_UrlForGenericOps , etc. That is somewhat surprising, because I think maybe you want to SET those variables with the values retrieved from KVM. Is that right?

Why would a KVM GET Step try to READ values from context variables?

Let's take a look. A typical configuration for a KVM Step to perform a GET (aka, retrieve the value stored for a given key) might look like this:

 

<KeyValueMapOperations name='KVM-Get-1'>
  <!-- 
   If you are storing your values via a REST URI like 
   apigee.googleapis.com/v1/organizations/ORG/environments/ENV/keyvaluemaps/MAPNAME
   then you should use environment scope here.
  -->
  <Scope>environment</Scope>
  <MapName>KVM-GenesysConfigs</MapName>
  <ExpiryTimeInSeconds>300</ExpiryTimeInSeconds>
  <Get assignTo='variable-to-set'>
    <Key>
      <!-- use a fixed ("hard coded") key -->
      <Parameter>Genesys_UrlForLogin</Parameter>
    </Key>
  </Get>
</KeyValueMapOperations>

 

The above would SET the value retrieved from the KVM, in. your case the value is https://login.usw2.pure.cloud/oauth/token , into the variable variable-to-set . This policy won't READ any context variables.

One mistake people can sometimes make in configuring the KeyValueMapOperations step, is to specify the Key Parameter incorrectly. For example, this probably won't work:

 

<KeyValueMapOperations name='KVM-Get-2'>
  <Scope>environment</Scope>
  <MapName>KVM-GenesysConfigs</MapName>
  <ExpiryTimeInSeconds>300</ExpiryTimeInSeconds>
  <Get assignTo='variable-to-set'>
    <Key>
      <!-- ref implies, use a variable to specify the key parameter -->
      <Parameter ref='Genesys_UrlForLogin'/>
    </Key>
  </Get>
</KeyValueMapOperations>

 

This latter policy tells Apigee to read the context variable Genesys_UrlForLogin to get a value for the key parameter.  If Apigee finds no context variable by that name, then the key parameter is empty, and the KVM Step won't retrieve anything. In this case you will see a trace, something like what you showed in your post.  So maybe that is what is happening with your policy. 


@dchiesa1 wrote:

....... I see from the trace, that It seems the step is reading? variables like Genesys_UrlForLogin , Genesys_UrlForGenericOps , etc. That is somewhat surprising, because I think maybe you want to SET those variables with the values retrieved from KVM. Is that right?

Why would a KVM GET Step try to READ values from context variables?

.....


Based on my observation, this is how the Classic debug UI works at the moment, ie. it's a bit tricky to see the difference between get and sets. So the screenshot we see does not necessarily means that those variables were configured to be GET and not to be SET.

1. When a value was assigned to the variable, you see it as "= assignedVariableValue"

2. When no (new)value was assigned to the given (new)variable, the field remains empty without "=" sign.

3. When a variable's existing value is read, you see it without =, just the assignedVariableValue.

4. When you try to read an existing variable, that eg. cannot be resolved, the field also remains empty (just like in the scenario in point2.)

We can download the debug session, where you can make a difference even without knowing the policies: those variables and their values are placed in different objects like "GET" and "SET".

OR use the new debug UI that shows you the type (GET/SET) as well in the 'Access' column.

sh.PNG

 

It's also true that if the variable to assign has the 'private' prefix, you won't see the assigned value in the debug session - just like when data masking/hiding configuration was set.

Anyway, @themj it would be great to see your KVM policy configs.

Br,

Marcello