SOAP to Rest: Convert Content-Type: application/xop+xml;charset=utf-8;type="text/xml"

Not applicable

Trying to parse the response from an existing soap service and convert it to json. What's the best way to achieve this? Obviously I could manipulate the string to get just the xml I need, but that seems like the least desirable way to do that. Here's an example of the response body:

--uuid:febc4b8f-0619-4212-b6ce-ac4d82510195+id=4
Content-ID: 
<http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
        <s:Body>
            <PingResponse xmlns="***snipped***">
                <PingResult xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
                    <ResponseCode>100</ResponseCode>
                    <ResponseText>INT\WU1007APG sent: Hello</ResponseText>
                </PingResult>
            </PingResponse>
        </s:Body>
    </s:Envelope>
--uuid:febc4b8f-0619-4212-b6ce-ac4d82510195+id=4--
0 2 3,727
2 REPLIES 2

adas
Participant V

@Joe Maher There's an out of the box mediation policy provided by Apigee Edge "XMLToJSON" which can convert your soap/xml response to JSON. If you want to further filter specific elements in the response, there are multiple approaches.

Approach 1: You could use the XSLT policy to modify and filter the original xml response. Once the transformation is done, you could do a simple XMLToJSON policy to convert into json response.

Approach 2: Use the XMLToJSON on your original soap/xml response. If you want to filter additional elements in the resulting json response, you could do a javascript policy to filter the json response using json parse or json path.

Let me know if this answers your question.

This is an old question, but I thought I'd provide some additional context here in case future searchers land here.

XOP refers to XML binary Optimized Processing, about which you can read here. In short, this standard was defined as part of the SOAP-related specifications, as a way to allow transmission of a SOAP document, which contains a binary image (like a PDF, PNG, ZIP etc) in an optimized manner.

XOP describes how to format a single HTTP message, which contains multiple parts. One part is an XML document, another part is the binary file.  The XML document refers to the binary attachment via an agreed-upon mechanism. That's XOP. The benefit of XOP is the message sender no longer needs to base64-encode the binary blob directly into the XML document. Instead, the sender inserts a reference element into the XML document, which points to the binary attachment.  The IBM tech article describes this well here.  This approach can reduce the size of the message, which makes it faster to transmit. 

There is no analogue, that I know of, that describes how to package JSON and a binary attachment in an HTTP message.  

If the goal is,  "I want Apigee to accept a XOP response, convert the XML to JSON, and send the JSON and the binary attachment to the caller," that seems easy enough to say.   But how?  You need to decide what form you expect the response message to take.  There is no established standard, so you'll need to design that yourself, and the calling client will need to conform to your choice. 

Some options I see

  1. parse the XOP package, extract the XML into a JSON message.  Then extract the binary attachment, base64-encode it, and then embed that into the JSON document in the new message. Send the new message to the original caller.
  2. parse the XOP package, extract the binary attachment and return it.  Discard the XML portion of the message. 
  3. parse the XOP package, extract the XML and return it.  Discard the binary portion of the message. 

Some of these are possible with this callout.

Option 1 preserves all the information in the XOP response. The problem with that is, it will require some extra memory at runtime on the Apigee gateway.  The other two options are probably not ideal as the caller doesn't get all the information in the original response.  But these may be interesting for some scenarios.

An alternative  is to separate these responses, so that the text (xml or JSON) is sent in a different response from the binary. But this requires a change to the upstream system, to store the binary attachment and send the reference that way.