This is a correction of my original post, as the forum software corrected the encoding of the XML making it read incorrectly 
For the record, we have a similar issue. We have a SOAP document, containing a ‘transaction results’, that itself contains a separate XML transaction (acknowledge or reject message) based on an industry standard. Quite why this needed to be embedded in a separate results message is lost to time. This is a legacy application that is being replaced and we are trying to replicate it without providing a knock on effect to existing consumers other than a URL change. That being said, it is perfectly valid within the XML spec to embed XML within XML.
Our SOAP message would look something like this (I’ve simplified the content dramatically which is quite large, for illustrative purposes)…
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<tns:getProductsResponse xmlns:tns="http://tempuri.org/">
<tns:getProductsResult><?xml version="1.0" encoding="UTF-8"?><status>SUCCESS</status></tns:getProductsResult>
</tns:getProductsResponse>
</soapenv:Body>
</soapenv:Envelope>
This is obviously incorrect and I would expect webMethods to convert the response to…
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<tns:getProductsResponse xmlns:tns="http://tempuri.org/">
<tns:getProductsResult><?xml version="1.0" encoding="UTF-8"?><status>SUCCESS</status></tns:getProductsResult>
</tns:getProductsResponse>
</soapenv:Body>
</soapenv:Envelope>
However it is returning….
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<tns:getProductsResponse xmlns:tns="http://tempuri.org/">
<tns:getProductsResult><?xml version="1.0" encoding="UTF-8"?><status>SUCCESS</status></tns:getProductsResult>
</tns:getProductsResponse>
</soapenv:Body>
</soapenv:Envelope>
with only the < being encoded. This according to the (purported) software AG response above, is perfectly valid and it certainly validates in XML SPY. It does however look a bit untidy (not a problem in itself) and some of our consumers are saying that their applications can’t parse it.
I’ve tried embedding it in CDATA e.g.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<tns:getProductsResponse xmlns:tns="http://tempuri.org/">
<tns:getProductsResult><![CDATA[<?xml version="1.0" encoding="UTF-8"?><status>SUCCESS</status>]]></tns:getProductsResult>
</tns:getProductsResponse>
</soapenv:Body>
</soapenv:Envelope>
but this doesn’t seem to work. It returns the CDATA correctly if I consume the WSDL directly from the integration server, however if I consume the virtualised service through mediator then webMethods is converting it back to
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<tns:getProductsResponse xmlns:tns="http://tempuri.org/">
<tns:getProductsResult><?xml version="1.0" encoding="UTF-8"?><status>SUCCESS</status></tns:getProductsResult>
</tns:getProductsResponse>
</soapenv:Body>
</soapenv:Envelope>
It’s all very frustrating.
Again, it would appear that there is nothing technically wrong with it. It should be able to be parsed by any XML parsing engine and certainly tools like SOAP UI ‘prettify’ it to restore the CDATA construct. However when you are dealing the with legacy code of a multitude of organisations that you have no technical authority over, sometimes you just want it to respond with what we’ve actually generated rather than what webMethods thinks you want.
