SOAP Execute snap enhancement request

My company needs to interact with some legacy SOAP services that are not strongly typed. As such, we make heavy use of the Customize Envelope functionality in the SOAP Execute snap. While the variable substitution seems to work fine for values, we need to use it to insert XML snippets into the envelope.

For example, I have a Script snap that constructs and stores a string in the document that looks something like:

"AddPersonPayload" : "<Name><Person><First>Kevin</First><Last>Kelley</Last></Person></Name><Address><NonStandardUS><Line1>5000 Riverside Dr</Line1><City>Austin</City><State>TX</State><Zip>78105</Zip></NonStandardUS></Address>"

In the Customize Envelope dialog box, I do something like:

<Message>$.AddPersonPayload</Message>

This almost works but the inserted content is “encoded” (but the surrounding content is not) so that it looks something like this:

<Message>&lt;Name&gt;&lt;Person&gt;...</Message>

The server is rejecting this because it is treating the content as a value rather than XML. It would be nice if there were a mechanism to mark a particular variable substitution so that the content would not be XML encoded prior to inserting it…

I’m wondering why you’re using a Script snap to generate a string - could that be part of the problem? Couldn’t you use a JSON generator or even just a Mapper snap to create the string and then Join or Union the document, and then reference the JSON path in your SOAP Execute? I have several SOAP Execute snaps with custom envelopes, and I’ve thrown some pretty gnarly text in there without having any encoding issues.

I can see the string generated by the script in the payload going into the SOAP Execute snap and it is not XML-encoded. The problem seems to be how variable substitution works in the SOAP Execute snap’s Customize Envelope window. Let me try to explain…

Our Case Management system has a SOAP API that has existed for many years (i.e., we have no plans to change it) and that API is “loosely-typed”. That is, all of the operations are “meta-operations” that take XML payloads that vary depending on the “case management function” that the caller wants to perform.

As such, the SOAP envelope generated by the SOAP Execute snap looks something like this:

<SOAP-ENV:Body>
    <tyl:OdysseyApiTxnExecutionSync>
        <tyl:apiMessageData>$apiMessageData</tyl:apiMessageData>
    </tyl:OdysseyApiTxnExecutionSync>
</SOAP-ENV:Body>

The problem is that what needs to replace the $apiMessageData variable is full-blown XML with tags. If I set the apiMessageData variable to a string that contains “< name >Yosemite Sam< /name >” (without the extra spaces) what the SOAP Execute snap sends to the server looks like this:

<SOAP-ENV:Body>
    <tyl:OdysseyApiTxnExecutionSync>
        <tyl:apiMessageData>
           &lt;name&gt;Yosemite Sam&lt;/name&gt;
        </tyl:apiMessageData>
    </tyl:OdysseyApiTxnExecutionSync>
</SOAP-ENV:Body>

This causes the server to reject the message.

The XML Generator has an “Escape special characters” property to control this:

Unfortunately, the SOAP Execute snap has no such setting – it always escapes. It needs a setting to control this.