Receiving an attachment via MTOM by consuming webservice

1
On consuming a webservice, I get a response in SoapUI like shown below: an XOP attachment with the requested file (MTOM, base64-encoded). In Mendix however, the stream results into an empty String or an empty FileDocument (Binary) when the response is mapped using the XML import mapping. Should Mendix be able to handle these webservice responses with attachments? Or is there an alternative to receive these responses? __ Edit 20 May 2017: with help of the Mendix support team, the issue is resolved. It appeared that the MTOM implementation of the publishing party was not fully according specifications. Mendix is picky about the content-type header returned, the publishing party returned at first: content-type: multipart/related; boundary="MIMEBoundary_d332ab067c0ccd8ca3f288cda61b94c481a05e875d98194f"; start-info="text/xml"; type="text/xml"; start="<0.c332ab067c0ccd8ca3f288cda61b94c481a05e875d98194f@apache.org>" But this is now updated to: content-type: multipart/related; boundary="MIMEBoundary_a355e2e848c3f59a60a85f9beff04c53caa92dc315e74dc2"; start-info="text/xml"; type="application/xop+xml"; start="<0.b355e2e848c3f59a60a85f9beff04c53caa92dc315e74dc2@apache.org>"        
asked
2 answers
2

What I usually do is create a non-persitable entity with an unlimited string attribute, and map the binary attribute to that string attribute. Mendix will then convert the MTOM attachment to a Base64 string, which you can then convert to a filedocument, using the CommunityCommons java action Base64DecodeToFile.
 

 

 

Also, make sure you have the MTOM option enabled in the Consumed webservice configuration.

answered
0

Mendix supports MTOM/XOP, so it should be possible.

Maybe you can try not to use a FileDocument but a new Entity with it's own Binary attribute.

answered