ExtractVariable : Extracting Path Segment Not Working

[#1]

I need to extract a variable named "product_code" from a path parameter.

My proxies are configured with a "*" wildcard at the specific path segment where I have my path parameter :

<BasePath>/product_definition/v1/product/*/sales_attributes</BasePath>

The right proxy is called when tested with Postman.

In order to extract the "product_code", I am using the following ExtractVariable policy in the Proxy Request PreFlow :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ExtractVariables name="Extract-Product-Code">
    <DisplayName>Extract Product Code</DisplayName>
    <Source>request</Source>
    <URIPath>
        <Pattern>/product_definition/*/product/{product_code}</Pattern>
        <Pattern>/product_definition/*/product/{product_code}/*</Pattern>
        <Pattern>/product_definition/*/product/{product_code}/**</Pattern>
    </URIPath>
    <VariablePrefix>urirequest</VariablePrefix>
</ExtractVariables>

While looking through the Trace, no variable "product_code" is defined in the context after executing the policy.

[zubermohammad]

Hi Alexis,

If you remove variable prefix element from your policy definition the variables will be shown in trace tool.

This is a short fall of trace tool that it doesn't display prefixed variables.

Cheers!

[#3]

No luck,

I tried removing the "VariablePrefix" and / or using a JavaScript policy to print the value, but nothing worked.

[hanselm]

You can also use an AssignMessage policy after the ExtractVariables to confirm the path param is extracted and verify it in the Trace tool when the AM policy executes:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="Assign-Message">
    <DisplayName>Assign Message</DisplayName>
    <Properties/>
    <AssignVariable>
        <Name>pcode</Name>
        <Ref>urirequest.product_code</Ref>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

[zubermohammad · Accepted solution]

Hi @Alexis Brodeur,

Got the problem.

Extract Variables policy take the URI after your basepath as pattern component. That means it will work on only proxy.pathsuffix elements.

Example:

Proxy basepath : /v1/products

if you make a request like GET /v1/products/12345/sales_attributes

then proxy.pathsuffix will be /12345/sales_attributes and in extract variable you can give pattern as

<Pattern>/{product_code}/sales_attributes</Pattern>

Since in your case the basepath is a generic the proxy path suffix will be empty hence the pattern you gave is not matching anything.

For a better design please make your basepath as /product_definition/v1/product and in extract variables policy give specific path without any * or **.

Example:

for base path /product_definition/v1/product give patterns as below

<Pattern>/{product_code}/sales_attributes</Pattern>

<Pattern>/{product_code}</Pattern>

<Pattern>/{product_code}/sales_attributes/{sale_attribute}</Pattern>

Extract variable policy will match longest path pattern and populate the variables.

Also for checking variables in trace you need to remove

<VariablePrefix>urirequest</VariablePrefix>

Hope this helps 🙂

[#6]

This works, thanks

[#7]

I got it to work with my initial Proxy Endpoint configuration using the following ExtractVariable policy :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ExtractVariables name="Extract-Product-Code">
    <DisplayName>Extract Product Code</DisplayName>
    <Variable name="proxy.url">
        <Pattern>**/product_definition/*/product/{product_code}/**</Pattern>
        <Pattern>**/product_definition/*/product/{product_code}</Pattern>
    </Variable>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</ExtractVariables>

@Mohammed Zuber , I am keeping your answer as accepted because I believe this is more of a hack around the way Apigee works. This solution requires parsing the full URL of the proxy including the protocol and domain, which is why I have to use "**" at the start of my patterns.

[zubermohammad]

@Alexis Brodeur Cool hack man 🙂