Advantage Technical Article - SOAP MTOM Support in IS 7.1.x

[wMusers.Com1 (wMusers.Com)]

Originally posted as Advantage Article ID 1614326864

Issue

explain how MTOM attachments should work in IS 7.1.2.
Resolution

To use MTOM in an IS 7.1 Provider service you would do it much like the MTOMSample in the WMSoapSamples.

Your input document to the Service that you are using as the Operation of the Web Service would have it’s normal Non-MTOM fields defined along with the 2 String fields, theSignedForm and theCrashPhoto (from your example shown below). Those 2 string fields would be defined in the IS DocumentType record with a Constraint property that sets the ContentType to base64Binary. Similar to what the inputData field does in the service in receiveAndSendMtomAttachments MTOM example.

<?xml version='1.0' ?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> 
<SOAP-ENV:Body> 
<claim:insurance_claim_auto id="insurance_claim_document_id" 
xmlns:claim="http://schemas.risky-stuff.com/Auto-Claim"> 
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/> 
<theCrashPhoto href="cid:claim061400a.jpeg@claiming-it.com"/> 
<!-- ... more claim details go here... --> 
</claim:insurance_claim_auto> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
  
--MIME_boundary 
Content-Type: image/tiff 
Content-Transfer-Encoding: base64 
Content-ID: <claim061400a.tiff@claiming-it.com> 
  
...Base64 encoded TIFF image... 
--MIME_boundary 
Content-Type: image/jpeg 
Content-Transfer-Encoding: binary 
Content-ID: <claim061400a.jpeg@claiming-it.com> 

When your client formats and sends the request with a valid MTOM usage to use attachments for both of those fields, the client side code would replace the content of the field in the request with the correct MTOM/XOP include statement referring to the actual attachment part containing the data.

Something like

 <inputData><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:45f7daa62eca20d911d455d3530"></xop:Include> 

Where the href= is referring to the ream Mime attachment:

Something like:

------=_Part_7_29473574.1227024350026 

content-type: application/octet-stream 

content-transfer-encoding: binary 

content-id: <45f7daa62eca20d911d455d3530> 

hi how are you?  

When this MTOM request is received by the IS Soap Processor, the processor will automatically extract the data from the MIME attachments and replace the XOP include placeholders in the request with the data contained in the referenced mime part. What the underlying service receives would be the base64Binary string representing the data in the MIME attachment. The underlying service simply accesses the field from the Document type, like it would any other field with Flow Map steps etc. The data in the field at this point is the base64Binary encoded string. To decode the Base64Binary string back to its true binary form, you could use the pub.string:base46Decode service to convert the encoded string back into its binary object representation.

Because the Provider Web Service is using MTOM/XOP, all of the MIME and/or attachment access is automatically performed by the IS Soap Processor along with the rest of the SOAPMessage unmarshalling. The underlying IS services do not have to bother with MIME attachments, or even soapMessages. They simply make use of IS Document Types that have fields with base64Binary constraints.

Hope this helps to explain how MTOM attachments should work in IS 7.1.2.

[amrendra.verma]

Hi Mark,

Could you please throw some light on how MTOM can be used to exchange messages in chunks.

Regards,
Amrendra