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!
LinkedIn
Twitter
