Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Property sets are not returning any values

I am using Property sets in Apigee Hybrid to store key value pairs. When I try to read the keys it gives null value or returns error.

File Name - myprops.properties
# myProps.properties file
foo=bar

Using ExtractVariables policy -

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ExtractVariables name="ExtractVariables-1">
    <DisplayName>ExtractVariables-1</DisplayName>
    <Source>request</Source>
    <Variable name="myVar">
        <Pattern>{propertyset.myprops.properties.foo}</Pattern>
    </Variable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

This variable returns empty value.

Using AssignMessage Policy - This returns error response as Key is invalid.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="Assign-Message-1">
    <DisplayName>Assign Message-1</DisplayName>
    <Properties/>
    <Set>
        <Payload content-type="application/json">{
                "message": "{myVar}",
                "value": "{propertyset.myprops.properties.foo}"
            }
        </Payload>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

Using Javascript - This also returns error as invalid Key

 var property = context.getVariable('propertyset.myprops.properties.foo');
 print("property is -"+ property);

Is there anything I am missing here.

Solved Solved
1 41 4,506
1 ACCEPTED SOLUTION

I'm happy to report that the Property Set issue at the proxy scope is now fixed.

Attached is an example proxy showing usage for Assign Message, Extract Variables and JavaScript policies.

property-set-proxy-test-rev3-2021-02-26.zip

View solution in original post

41 REPLIES 41

Thanks for the recommendation, however I think I will stick to KVM for the following reasons:

  1. KVM is supported at Org level (this might be better for some customers who have multiple env in a Prod org
  2. Keeping the error mapping config in JSON is code agnostic and more enterprise ready as it can be adopted easily if I change the error handler to a Java based SharedFlow or by other non apigee applications. Putting the mapping into a JS file will limit its usage and adoption
  3. The map will contain the transformed error text, error desc and the error code against the input error code and error desc for multiple backend systems. I believe this is more readable and extendable in a JSON format rather than a object format as required by JS.

Quick question: Can we put the error mapping data in CSV format as the value of a KVM key? A CSV is probably a more easier and non-technical way to hold the error mapping making it easier to update by a wider audience using an Excel Spreadsheet 


@SidDas wrote:

Can we put the error mapping data in CSV format as the value of a KVM key? 


Yes but the "value" part of the KMV entry is a string, so it needs to be valid JSON in the curl request (no newlines, escaped quotes, etc.).