A variable called var.colour is fine, but creating another one called var.colour.again is not. Why is that?

Google Cloud Apigee
1

I am using an Extract Variable policy to extract a query parameter and save it in a variable called ‘var.colour’. If I try to extract the same query parameter (or even a different one, it doesn’t matter) into another variable called ‘var.colour.hue’, Apigee does not set the second variable and returns an error. This is what we see in the trace:

2790-apigeevariable.png
2790-apigeevariable.png590×241 9.6 KB

As you notice, Apigee has no issue in saving the variable named ‘var.colour1’. Also, none of these variables would be created if there were another variable called ‘var’.

Below is the error we see.

{
    "fault": {
        "faultstring": "Failed to set variable var.colour.again value blue from ExtractVariables: Extract-Variable",
        "detail": {
            "errorcode": "steps.extractvariables.SetVariableFailed"
        }
    }
}

So basically, I can name a variable with a dot in the name (e.g. variable.name) without any issues, but if another variable name contains the same variable name in it (e.g. variable.name.1), it fails.

I found this by accident and saw that this has not been documented in Apigee Docs. Can someone validate this and confirm if this is an issue or if this is by design?

1 Like
2

Here are some findings on how the dot-notation work in Apigee Edge implementation and mechanics of the original post’s failures.

The doc on http://docs.apigee.com/api-services/content/introduction-flow-variables says:

“dot-notation convention is strictly for naming purposes. For example, request.content does not refer to a parent variable or object called “request”.”

It is not technically correct. Internally, variables dot notation is implemented in a tree-like structure.

When assigned, a variable name is parsed into dot-separated tokens and non-leaf elements are stored as Java maps. Leaf tokens will be an object type.

When accessed, the dot-separated name goes through a similar recursive process and all non-leaf nodes expect to encounter a map, containing either next ‘path’ element or a leaf object.

A first assignment would define a type of a node. Therefore, all consecutive assignments/retrievals shall respect the originally assigned type.

For example, if you create/assign

node1.leaf

then your leaf is an object node. Therefore, following assign

node1.node2.leaf will fail as it is impossible to allocate map node2, because leaf is already allocated.

As we are talking about a recursive variable name parsing function, the same applies for deeply nested dot.separated names:

node1.node2.node3.node4.leaf

will work, but the following assignment

node1.node2.node3.node4.node5.leaf

will fail.

While accessing variables, during path traversal retrieval process checks if nodes are maps and if they are not, silently fails, by returning nothing. As a result, we can see that not-equal Unicode character and are left puzzled by the behaviour.

In a nutshell: a success of using variables defined with dot notation is dependent on an order of creation of the variables.

Attn: @Hari

1 Like