For those who find this later and are looking for a solution to a similar problem I recommend the following pattern:
- An Extract Messages policy to pull the relevant fields for your SOAP call into flow variables from queryParams, headers, and/or payload. I typically name these ExtractResourceVariables where resource is the API exposed resource (eg. /v1/coupons/1234 where coupons is the resource).
- A Javascript callout policy to build the optional soap query elements and store these snippets of XML as flow variables. Javascript allows us to handle complex conditions that we could not achieve with a simpler policy.
- A BuildResourceQuery.xml file using the AssignMessage policy to assemble the bits into a backend query. The bit of magic here is we can include all of the potential query snippets realizing that some will return blank when they are not required (see example below).
- From there the target runs the query. This allows one single flow to service many different possible combinations.
Examples:
ExtractCouponVariables
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<ExtractVariables async="false" continueOnError="false" enabled="true" name="extractCouponVars">
<DisplayName>extractCouponVars</DisplayName>
<URIPath>
<Pattern ignoreCase="true">/{version}/coupons/{coupon.code}</Pattern>
</URIPath>
<URIPath>
<Pattern ignoreCase="true">/{version}/profile/{profile.aliasId}/coupons/{coupon.code}</Pattern>
</URIPath>
<QueryParam name="couponcode">
<Pattern ignoreCase="true">{coupon.code}</Pattern>
</QueryParam>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>The Javascript code that builds the optional query elements for the SOAP message:
var filterOptions = "";
var entitled=context.getVariable("request.queryparam.entitled");
if(entitled==="true") entitled="Entitled";
else if(entitled==="false") entitled="NotEntitled";
if (entitled) {
if (filterOptions === "") filterOptions = "<Option type=\"filter\">EntitlementState==" + entitled;
else filterOptions += "&&EntitlementState=" + entitled;
}
var propogationState = context.getVariable("request.queryparam.propagation");
if (!propogationState || propogationState === "") propogationState = "true";
switch (propogationState) {
case "true":
if (filterOptions === "")
filterOptions = "<Option type=\"filter\">[CustomProperties.href^propagationState&&CustomProperties==true]";
else
filterOptions += "&&[CustomProperties.href^propagationState&&CustomProperties==true]";
break;
case "false":
if (filterOptions === "")
filterOptions = "<Option type=\"filter\">[CustomProperties.href^propagationState&&CustomProperties==false]";
else
filterOptions += "&&[CustomProperties.href^propagationState&&CustomProperties==false]";
break;
}
if (filterOptions !== "") filterOptions += "</Option>";
context.setVariable("coupon.filterOptions", filterOptions);
And finally the build SOAP policy (edited for privacy):
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<AssignMessage name="buildCouponLookup">
<DisplayName>buildCouponLookup</DisplayName>
<AssignTo createNew="true" type="request">request</AssignTo>
<Set>
<Headers>
<Header name="Content-Type">text/xml; charset=utf-8</Header>
</Headers>
<Payload contentType="text/xml">
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<fetchCoupon xmlns="http://soap.foo.com/v4_2/Coupon">
<auth>
<version>4.2</version>
<login>{target.username}</login>
<password>{target.password}</password>
</auth>
<couponId>{coupon.code}</couponId>
{coupon.filterOptions}
</fetchCoupon>
</soap:Body>
</soap:Envelope>
</Payload>
<Verb>POST</Verb>
</Set>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
Of note here is the IgnoreUnresolvedVariables option in the AssignMessage policy - this allows the policy to execute even if we don't have a value for coupon.filterOptions - that line is blank in that case allowing us to achieve an optional filtered query with the same policy as an unfiltered query for all coupons matching a particular code.
The downside of this approach is the JSC can get fairly complex when you have many different options. In cases where this complexity is too great we find it worthwhile to replicate the build policies and live with the redundancy of the configuration in favor of readability and reduced complexity.
LinkedIn
Twitter
