Hi @all,

atm. we have a project where I have to connect to a Groovy/Java web service which is answering with an MTOM (multipart) response.

Looking at cClientWebService.pkg in DF 18.2 and 19.1 there are comments about MTOM not being supported:

Code:
    // determines how this service should be MTOM mime encoded.  
    // keep private until MTOM is supported.
Are there any future plans or is there a known workaround?


--
Detailed description:

DF 18.2, SOAP 1.1, request is always pure 'text/xml'.

An example response is looking like that:

Response Content-Type:
Code:
multipart/related; type="application/xop+xml"; boundary="uuid:ce3ee91d-11e3-46a6-8fd3-f87a6392045b"; start="<root.message@cxf.apache.org>"; start-info="text/xml"
Response Content:
Code:
--uuid:ce3ee91d-11e3-46a6-8fd3-f87a6392045b
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <root.message@cxf.apache.org>
 
   <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Body>
         <ns3:startProcessResponse xmlns:ns3="http://web.process.cursor.de/" xmlns:ns2="http://variable.process.common.jevi.cursor.de/">
            <ns2:processWebResult>
               <InstanceId>2823b04a-d307-11e9-9e31-02fadd21c9da</InstanceId>
               <Status>ENDED</Status>
               <ResultParameter/>
            </ns2:processWebResult>
         </ns3:startProcessResponse>
      </soap:Body>
   </soap:Envelope>
--uuid:ce3ee91d-11e3-46a6-8fd3-f87a6392045b--
As you can see, there is no need for a MTOM response in that case (no binary data included), but the software vendor can't change that behavior for us.

The only thing which we needed here is to extract the XML part (<soap:Envelope … </soap:Envelope>) and throw away the rest. Instead of this, Dataflex is treating the whole response as it were pure XML and tries to load it:

Code:
// cXmlHttpTransfer.pkg:
   Function HttpPostXmlNode  String sHost String sFilePath Handle  hoXmlNode Returns Handle
      // ...
           Get HttpPostXmlVar sHost sFilePath vXmlNode to vXml
           // if data is returned (aXML) it is non-zero and content type is correct.
           // if no data, an error has been registered or no data is an ok condition
           If (vXml<>"") Begin
               Get VarianttoXML vXml to hoXml
               If (hoXml=0) Begin
                   // this indicates that data was returned but it could not be loaded as XML
                   Set peXmlTransferStatus to xtsNotXml
                   // store the bad data for debugging purposes. Will store as OEM
                   Get VariantStrToBuffer of hoCharTranslate vXml CP_OEMCP to aXml
                   Set paDataReceived to aXml
                   Set piDataReceivedLength to (VariantStringLength(vXml))
               End
           End
Result of such a service call is always xtsNotXml / wssNotXml - and nothing won't get deserialized into our structures.

Our workaround atm. is, we manually ignore any error if HTTP Status Code was 200 (ResponseStatusCode(hoHttp)=200), indicating that our request was understood. After that we manually have to parse the result stored in paDataReceived(hoHttp)...


Anyone a better idea how to handle that situation?

Regards, Patrick