Unresolved Variable in JSON

Not applicable
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout async="false" continueOnError="false" enabled="true" name="AddCustomerRSS">
    <DisplayName>AddCustomerRSS</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="addCustomerRSS">
        <Set>
            <Headers>
                <Header name="Content-Type">application/json</Header>
            </Headers>
            <Verb>POST</Verb>
            <Payload contentType="application/json">
                 {"PortId":"SEARSCA", "Folder":"Receive","Filename":"test.xml","Content":"base64blob"}
            </Payload>
        </Set>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>calloutResponse</Response>
    <HTTPTargetConnection>
        <Properties/>
        <URL>HIDDEN_FOR_SECURITY</URL>
    </HTTPTargetConnection>
</ServiceCallout>

I have a really strange error occurring in a service callout policy. The code is above.

When the flow reaches this policy it returns an error:
{
  "fault": {
    "faultstring": "Unresolved variable : \"PortId\"",
    "detail": {
      "errorcode": "messaging.runtime.UnresolvedVariable"
    }
  }
}
I have verified using a json verifier that it is a valid json. Strangely though, if I copy this exact policy into another api proxy in a different account it works. If I copy it into another api proxy but on the same account I get the same error. It only seems to work on that account (or maybe only that specific api proxy on that specific account).
Any suggestions on how we might fix this?
Thank you,
Aleks
Solved Solved
0 7 3,973
1 ACCEPTED SOLUTION

adas
New Member

@aleks1 This is a bug in Apigee Edge. For now you can do this:

<Payload contentType="application/json">
                 \{"PortId":"SEARSCA", "Folder":"Receive","Filename":"test.xml","Content":"base64blob"}
</Payload>

This is escape the curly brace and not try and resolve the PortId as a variable. There is a fix that we are going to deploy in few days. For now just go with this workaround, you might have to change this later to remove the "\" escapte character.

View solution in original post

7 REPLIES 7

Dear @aleks1 ,

Welcome to Apigee Community 🙂

In Apigee Policies, you will reference flow variables using {} "Curly Braces" notations. Earlier versions of Apigee Edge use to do this same with Json payload too. We use to escape same using "\" notation while using JSON Payloads in policies. I believe it's fixed with latest Apigee Edge Cloud version.

It might be an issue with Apigee Edge versions, Can you please post buidInfo (Apigee Edge Version) of two accounts you are talking about ?

You can access build info by navigating to , https://YOUR-MANAGMENT-PORTAL-URI/buildInfo , that will provide more information to understand your issue.

adas
New Member

@aleks1 This is a bug in Apigee Edge. For now you can do this:

<Payload contentType="application/json">
                 \{"PortId":"SEARSCA", "Folder":"Receive","Filename":"test.xml","Content":"base64blob"}
</Payload>

This is escape the curly brace and not try and resolve the PortId as a variable. There is a fix that we are going to deploy in few days. For now just go with this workaround, you might have to change this later to remove the "\" escapte character.

@arghya das , I have seen payload working without "\" in Edge cloud, Is it an issue with OnPrem ? OP Says, it works with one account but not other. Just curious, which one is other here.

The fix was rolled out to the trial pods, so it is working there. The fix is not yet rolled out to paid customers yet including on-prem so that might be the problem. I just tried it on my trial org in production and it works there, the same doesn't work for the paid orgs.

Thank you @arghya das for the update, that summarizes why it's working in few accounts.

@arghya das I've tried your suggestion and it is working now. The other account that it was working on is indeed a trial account. Thank you for the help.

The fix broke few customers who were implementing this workaround of having a "\" as escape character so unfortunately we had to revert it. It also has few performance implications so the fix has not been rolled out yet. It might get there by end of May.