{ Community }
  • Academy
  • Docs
  • Developers
  • Resources
    • Community Articles
    • Apigee on GitHub
    • Code Samples
    • Videos & eBooks
    • Accelerator Methodology
  • Support
  • Ask a Question
  • Spaces
    • Product Announcements
    • General
    • Edge/API Management
    • Developer Portal (Drupal-based)
    • Developer Portal (Integrated)
    • API Design
    • APIM on Istio
    • Extensions
    • Business of APIs
    • Academy/Certification
    • Adapter for Envoy
    • Analytics
    • Events
    • Hybrid
    • Integration (AWS, PCF, Etc.)
    • Microgateway
    • Monetization
    • Private Cloud Deployment
    • 日本語コミュニティ
    • Insights
    • IoT Apigee Link
    • BaaS/Usergrid
    • BaaS Transition/Migration
    • Apigee-127
    • New Customers
    • Topics
    • Questions
    • Articles
    • Ideas
    • Leaderboard
    • Badges
  • Log in
  • Sign up

Get answers, ideas, and support from the Apigee Community

  • Home /
  • Edge/API Management /
avatar image
7

How do I "easily" insert variables into JSON Payloads?  

  • Export to PDF
pbhogill created · Apr 03, 2015 at 09:39 PM · 47.2k Views · Dino edited · Jan 09, 2017 at 08:38 PM

Often you get into a situation where within an API Proxy you may need to insert some variable data into a JSON payload that is needed by your back-end or target service. You can leverage the AssignMessage policy to do that. For eg:

<AssignMessage name="AssignMessage">
    <Set>
      <Payload contentType="application/json">
      	{"name":"foo", "type":"bar"}
      </Payload>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

The above is ok so long as you are not using any variables to populate the JSON payload. But there's no fun in sending static payloads! how do I then insert variable data in the payload?

It's very easy, like this:

<AssignMessage name="AssignMessage">
    <Set>
      <Headers/>
      <Payload contentType="application/json">
{
  "prop1":"foo", 
  "prop2":"{variable_name}",
  "prop3":"{system.timestamp}"
}
</Payload>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Each of the strings surrounded by {curly braces} is interpreted as a variable name. The rule is: if there is an open curly and a close curly, and all the characters between are legal characters for a variable name (alphanumerics plus dot and underscore), then the sequence is treated as a variable reference.

So, something like this:

{variable_name}

...is treated as a variable name, when it appears inside the Payload element.

Something like this:

{ "prop1 : "foo" }

...is not treated as a variable reference. Notice there are spaces, quotes, and a colon between those curlies. Even if the variable reference appears between double quotes, like this:

"{variable_name}"

...the variable will be de-referenced. You can also combine multiple variables in a single line, like this:

{ "prop1 : "foo-{variable1}-{variable2}" }

If the referenced variable name can be resolved, then at runtime, the reference is replaced with the value of the variable. If variable name cannot be resolved then... based on the "true" value of the IgnoreUnresolvedVariables element, then the unknown variable name is replaced with a blank string. On the other hand if IgnoreUnresolvedVariables is false, the policy will throw the proxy into Fault status if there are unresolved variable references.

You can use built-in variables like system.timestamp, or custom variables that the proxy has filled via other policies, like ExtractVariables, KVM-Get or PopulateCache. The same approach works for populating XML payloads, of course.

Creating dynamic JSON messages used to be trickier. Previously the logic that handled the message template was somewhat naive; it interpreted any open curly brace as being the start of a variable reference. To get around that, the AssignMessage policy allowe the "variablePrefix" and "variableSuffix" properties. You might see some older examples employing this. They might look like this:

<AssignMessage name="AssignMessage">
    <Set>
      <Headers/>
      <Payload contentType="application/json" variablePrefix="@" variableSuffix="#">
      	{"prop1":"foo", "prop2":"@variable_name#"}
      </Payload>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

This works the same as the example above that used curlies. It still works today, but we have made AssignMessage smarter so that you no longer have to set the variablePrefix and variableSuffix. Just use curlies, and keep no spaces between the curlies and the variable names, and you should be good.

That's it. I hope this short writeup was helpful. Go JSON!

thub.nodes.view.add-new-comment
json
Add comment Show 7
10 |5000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by Apigeeks only
  • Viewable by the original poster
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image sgilson ♦♦ · Apr 07, 2015 at 02:15 PM 0
Link

Hi Prithpal,

Do you always have to precede JSON payloads with "\"?

Stephen

avatar image sgilson ♦♦ sgilson ♦♦ · Apr 08, 2015 at 06:10 PM 1
Link

You do not. In older versions of Apigee Edge, it was necessary. As of 2017, you do not need to use a leading "\" to escape the leading "{" in the JSON payload.

avatar image joshua.r.butler · Jul 03, 2015 at 02:42 PM 0
Link

For me, variablePrefix="$" variableSuffix="%" seem to break use of the escape before the first curly brace - e.g.

<Payload contentType="application/json; charset=utf-8" variablePrefix="$" variableSuffix="%">
\{
  "fault": {
    "faultstring": "Request Failed",
    "detail": {
      "message": "Parameters were valid but request failed."
    }
  },
  "apiReturn": $someJSON.content%
}
</Payload>

...results in a payload full of escape chars - very ugly.

However, removing the variablePrefix="$" variableSuffix="%" makes it work fine.

Additionally, adding any variables still seems to work by just inserting the variable name within double quotes as the value for any property in the json - e.g.:

<Payload contentType="application/json; charset=utf-8">
\{
  "fault": {
    "faultstring": "Request Failed",
    "detail": {
      "message": "Parameters were valid but request failed."
    }
  },
  "apiReturn": "{someJSON.content}"
}
</Payload>

Results in the payload being returned, without any escape chars and with the variable value inside the curly brackets...

This seems different to the way it should work as described above...

avatar image pbhogill ♦ · Jul 03, 2015 at 06:30 PM 0
Link

Hi @joshua.r.butler if you are using the variable prefix of "$" & variable suffix of "#" you shouldn't need to escape your first "{" like {\". If you do not specify the variable prefix & suffix the interpreter starts interpreting the first "{" it encounters as a variable.

avatar image joshua.r.butler · Jul 06, 2015 at 10:19 AM 0
Link

@Prithpal Bhogill - thanks. It took me a bit of playing around to get it working - but yes, you're right. This is now working for me:

<Payload contentType="application/json" variablePrefix="$" variableSuffix="%">
    {
      "fault": {
        "faultstring": "$walletAdjustment.ReturnString%",
        "detail": {
          "message": "Parameters were valid but request failed."
        }
      },
      "apiReturn": "$purchaseJSON.content%"
    }
</payload>

MOST IMPORTANT THING TO NOTE:

Make sure to include the variables inside double quotes in cases where that variable might return json - otherwise it comes out with all the horrible escape chars. Took me a while to work that out.

avatar image Sujith Mathew · May 16, 2016 at 03:47 PM 0
Link

Is it possible to do the same with SOAP?

avatar image Dino ♦♦ Sujith Mathew   · Jan 09, 2017 at 08:47 PM 0
Link

yes, you can dynamically populate SOAP messages. It looks like this:

<AssignMessage name="AssignMessage-Title">
    <AssignTo createNew="false" transport="http" type="request"/>
    <Set>
        <Verb>POST</Verb>
        <Payload contentType="text/xml">
            <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
                <s:Header/>
                <s:Body>
                    <urn:findEntriesByTitle xmlns:urn="urn:librarysample.services.apigee.com">
                        <urn:title>{urielement.title}</urn:title>
                    </urn:findEntriesByTitle>
                </s:Body>
            </s:Envelope>
        </Payload>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

You can see a screencase on this, here.

Article

Contributors

avatar image avatar image

Follow this article

13 People are following this .

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Navigation

How do I "easily" insert variables into JSON Payloads?

Related Articles

Tutorial: Service Virtualization - Dynamic Field Filtering of JSON responses

Converting between XML and JSON with Apigee Edge: what you need to know

How can you Extract all values from a JSON hash into context variables?

  • Products
    • Edge - APIs
    • Insights - Big Data
    • Plans
  • Developers
    • Overview
    • Documentation
  • Resources
    • Overview
    • Blog
    • Apigee Institute
    • Academy
    • Documentation
  • Company
    • Overview
    • Press
    • Customers
    • Partners
    • Team
    • Events
    • Careers
    • Contact Us
  • Support
    • Support Overview
    • Documentation
    • Status
    • Edge Support Portal
    • Privacy Policy
    • Terms & Conditions
© 2021 Apigee Corp. All rights reserved. - Apigee Community Terms of Use - Powered by AnswerHub
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Create an article
  • Post an idea
  • Spaces
  • Product Announcements
  • General
  • Edge/API Management
  • Developer Portal (Drupal-based)
  • Developer Portal (Integrated)
  • API Design
  • APIM on Istio
  • Extensions
  • Business of APIs
  • Academy/Certification
  • Adapter for Envoy
  • Analytics
  • Events
  • Hybrid
  • Integration (AWS, PCF, Etc.)
  • Microgateway
  • Monetization
  • Private Cloud Deployment
  • 日本語コミュニティ
  • Insights
  • IoT Apigee Link
  • BaaS/Usergrid
  • BaaS Transition/Migration
  • Apigee-127
  • New Customers
  • Explore
  • Topics
  • Questions
  • Articles
  • Ideas
  • Badges