Unresolved variable error when trying to retrieve KVM value to use as private key for JWT generation

Hi, I am encountering this error:

"fault": {
"faultstring": "Failed to Resolve Variable : policy(Generate-JWT-Access-Token) variable(private.privateKeyForApigee)",
"detail": {
"errorcode": "steps.jwt.FailedToResolveVariable"
}

Goal: I want to retrieve a KVM value called apigeePrivateKeyForJWT and use that as the private key for generating a JWT token.

What I've done so far:

 I have this shared flow that is attached to the target pre-flow of all proxies in my default-dev environment:

 

 

 

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<KeyValueMapOperations async="false" continueOnError="false" enabled="true" name="KVM-Retrieve-PrivateKey-For-Signing-Apigee-Requests-To-Coursera" mapIdentifier="coursera-kvm-store">
<DisplayName>KVM-Retrieve-PrivateKey-For-Signing-Apigee-Requests-To-Coursera</DisplayName>
<FaultRules/>
<Properties/>
<ExclusiveCache>false</ExclusiveCache>
<ExpiryTimeInSecs>300</ExpiryTimeInSecs>
<Get assignTo="private.privateKeyForApigee">
<Key>
<Parameter>apigeePrivateKeyForJWT</Parameter>
</Key>
</Get>
<Scope>organization</Scope>
</KeyValueMapOperations>


The GenerateJWTToken policy references the above variable like this:

<PrivateKey>
<Value ref="private.privateKeyForApigee"/>
</PrivateKey>

The shared flow is set to execute before the GenerateJWTToken policy and I can verify that the name of the store is correct and it contains a key called apigeePrivateKeyForJWT.

I'm not sure if I am missing a step or if there is anything I am not considering here.

I would appreciate any sort of help or guidance on the matter. Thanks for taking a look!


 

Solved Solved
0 2 603
2 ACCEPTED SOLUTIONS

The error message you are getting from the GenerateJWT policy is telling you that the variable you referenced, "private.privateKeyForApigee", is empty or not defined. This means the KVM Get policy has not retrieved the value that you think you have retrieved. You can verify this by examining the information provided in an Apigee Debugsession, and observing that the KVM GET did not retrieve the expected data. Because variables with the "private." prefix are not shown in the debugsession, you may need to insert a simple AssignMessage policy  after the KVM Get to reveal the value of the variable.  Something like this will work:

 

<AssignMessage name-"AM-Diags">
  <AssignVariable>
    <Name>diagnostics</Name>
    <Ref>private.privateKeyForApigee</Ref>
  </AssignVariable>
</AssignMessage>

 

This policy just assigns from one variable to another.  Its only purpose is to reveal the private value in the debugsession. I suspect it will show you that there is no value in that variable.

Why would that occur?

The most common reason I have seen is a misunderstanding of the Scope element in the KVM Get.  Your KVM Get shows an "organization" scope and you've asserted that there is a value associated to the expected key in that KVM Map.  But

  1. how did you verify that fact? (Can you provide details)
  2. are you certain you are using a consistent scope, when you load and retrieve the value?  If you use the Apigee UI to verify the presence of the key, then you will be viewing environment scoped KVM. But your policy referenced an organization scoped KVM. You might want to change your KVM policy to use

    <Scope>environment</Scope>​

When something isn't working the way you expect, you need to back up and examine all the assumptions. So just take your time, and verify each step along the way. Is it the right scope? Is the KVM Map name correct? Does the sharedflow actually execute? Does the expected value get loaded? (The AssignMessage policy I showed above will help verify this). etc.

View solution in original post

I think I was able to get it working by changing the scope from organization to environment, thank you for such a detailed and helpful response. I really appreciate it!

View solution in original post

2 REPLIES 2

The error message you are getting from the GenerateJWT policy is telling you that the variable you referenced, "private.privateKeyForApigee", is empty or not defined. This means the KVM Get policy has not retrieved the value that you think you have retrieved. You can verify this by examining the information provided in an Apigee Debugsession, and observing that the KVM GET did not retrieve the expected data. Because variables with the "private." prefix are not shown in the debugsession, you may need to insert a simple AssignMessage policy  after the KVM Get to reveal the value of the variable.  Something like this will work:

 

<AssignMessage name-"AM-Diags">
  <AssignVariable>
    <Name>diagnostics</Name>
    <Ref>private.privateKeyForApigee</Ref>
  </AssignVariable>
</AssignMessage>

 

This policy just assigns from one variable to another.  Its only purpose is to reveal the private value in the debugsession. I suspect it will show you that there is no value in that variable.

Why would that occur?

The most common reason I have seen is a misunderstanding of the Scope element in the KVM Get.  Your KVM Get shows an "organization" scope and you've asserted that there is a value associated to the expected key in that KVM Map.  But

  1. how did you verify that fact? (Can you provide details)
  2. are you certain you are using a consistent scope, when you load and retrieve the value?  If you use the Apigee UI to verify the presence of the key, then you will be viewing environment scoped KVM. But your policy referenced an organization scoped KVM. You might want to change your KVM policy to use

    <Scope>environment</Scope>​

When something isn't working the way you expect, you need to back up and examine all the assumptions. So just take your time, and verify each step along the way. Is it the right scope? Is the KVM Map name correct? Does the sharedflow actually execute? Does the expected value get loaded? (The AssignMessage policy I showed above will help verify this). etc.

I think I was able to get it working by changing the scope from organization to environment, thank you for such a detailed and helpful response. I really appreciate it!