Hi again,
I am still struggling with the reception of SOAP Attachment messages. I have no control over the sender. They simply do a HTTP post with a SOAP message containing attachment. The Content type of the HTTP POST is multipart/related (reported by getTransportInfo).
The rest of my environment is 6.01/6.5 and we use reverse invoke proxy. I have installed a stand-alone wM 7.1 on the same server as the reverse invoke on the DMZ (we have no extra license cost for this). This 7.1 server are acting as a “SOAP Attachment proxy”. The only this IS should do is detach the attachment from the SOAP message (the attachment is plain XML) and forward (https post) it to the reverse invoke proxy on the same server. This way we reuse rest of our infrastructure the normal way: TN will recognize the XML, the business model will start, etc.
I have created a small service called soapAttachmentReceive and registered this as a SOAP preprocessor. But when our partner are trying to post to this we receive the following error:
[2856]2008-01-29 14:38:45 MET [ISC.0088.0001E] SOAPException: [ISS.0088.9134] Exception occurred while processing the body of the message
[2855]2008-01-29 14:38:45 MET [ISC.0088.9327E] MTOM Attachments Processing Failed: Cannot de-serialize the input MIME Stream; value of the ‘Content-Type’ header of the MIME message is not equal to ‘multipart/related’
I have also tried to add a Web Service Descriptor on the soapAttachmentReceive service and enabled attachment. But no use. (note: I am not so into webservices in wM).
But if we skip the SOAP preprocessor and our partner are posting to http://****/invoke/ReverseInvoke:soapAttachmentReceive I am able to get the SOAP message and attachment into my pipeline by reading the contentStream. But now I have to create a java service extracting the XML from this raw data. Even though it is not a very good solution, I will do this if we don’t get the SOAP reception working.
See the attachment for server logs on both scenarios.
Any ideas??
attachment_wmusers.txt (5.93 KB)
#webMethods#soa#API-Management