MTOM Streaming through HTTP.

Dear all,

webMethods service has to send some xml message as a content along with MTOM attachment ( .cif/.pdf/.csv file) through http post.

Am using below steps to send the attachment but subscription client didn’t receives any attachments.

  1.   Trying to create:mime.
    
  2.   Tyring to convert the files (( .cif/.pdf/.csv file)) to stream.
    
  3.   Adding it to the BodyPart.
    
  4.   Converting “xml” to stream
    
  5.   Adding it to the bodypart.
    
  6.   Creating the mime envelope
    
  7.   Passing the mime envelope to mimestream. in (pub.Client.http)
    

But couldn’t able to get the attachment in subscription side. Please let me know ways to achieve it

Thanks in advance,
Kind Regards,
Raj

MTOM is a method to efficiently send binary data to and from Web services. MTOM is usually used with the XOP.

In your sender application (usually where webservice provider resides), perform below:

  1. create a service whose output is a XOPObject
  2. get content of file as stream using “pub.file:getFile”
  3. create XOP object using “pub.soap.utils:createXOPObject” and map the outcome to service output
  4. expose your service as a webservice provider
  5. set “Attachments enabled” to “true” on the provider
  6. set “watt.server.SOAP.MTOMThreshold=” property with the appropriate value. This property specifies the field size, in kilobytes.

On your consumer application:

  1. create a webservice consumer for above webservice
  2. write a flow service which calls connector
  3. get the XOP object as response and use “pub.soap.utils:getXOPObjectContent” to get the stream content
  4. convert stream to file back

If you want to allow streamed MTOM attachments in inbound messages, configure the following server configuration parameters:

  1. Set the watt.server.SOAP.MTOMStreaming.enable server configuration parameter to true to enable MTOM streaming.
  2. Configure the watt.server.SOAP.MTOMStreaming.cachedFiles.location server configuration parameter to identify the location where Integration Server temporarily caches the MTOM attachments.
  3. Configure the watt.server.SOAP.MTOMStreaming.threshold server configuration parameter to specify the number of bytes an MTOM attachment in an inbound SOAP message must be before Integration Server uses MTOM streaming for the MTOM attachment.
1 Like

Thank you Prasad for taking your time to reply:)

Actually we are able to do MTOM Stream with webServices but the problem here is subscription application doesnot supports to webServices it only support HTTP POST. so kindly help us with how to achieve the same using HTTP POST.

Please do let me know if you want any more information in detail.

Thank you so much for you help:)

Kind Regards,
Raj

Did you try smtp which supports attachments ? Is your client supports it ?

Thanks,

Hi All,

Can you please let me know how to read the attachment data in flow service?

I am using SOAP UI to test the service. And i am attaching the attachments in using attachment tab.

Please look into the screenshot. Can you please suggest on this.

Regards,
Jacob B
ticket.PNG

Are you receiving via WS-SOAP request ie MTOM based?

HTH,
RMg

Hi Jacob,

put the following two lines at top of your flowservice:

  • pub.flow:savePipelineToFile
  • pub.flow:restorePipelineToFile

When you have invoked the service once, disable the savePipeline and debug the service in Designer.

By doing so you will find out how the attachment is represented in the flow service.

Regards,
Holger

Hi,

I could not see the attachment in file.

Can you please let me know how to implement MTOM attachment.

Regards,
Jacob B

Do you have WmMtomStreamingSample package available in your environment so you get some idea for implementing?

HTH,
RMG

1 Like

Hi RMG,

I dont have the WmMtomStreamingSample package in the server.

Can you please advice how to get this.
Regards,
Jacob B

Hello

Please use the cid: 887989226097 in the property panel, currently its value is Test inp…

As per the documentation also:-

When using MTOM streaming, the messageContext variables and/or XOPObject fields will
not be available in the pipeline that is saved when using:
? Audit logging when the pipeline is included
? Service caching
? pub.flow:savePipeline or pub.flow:savePipelineToFile services
? Transient error handling for a service

Hi Sasank,

I have tried by specifying the cid in the request and i can see the base64 encoding of the attachment in the request string. But the requirement is to send the attachment as MTOM, not as field.

Below is the same request structure.

------=_Part_224_1880766616.1458031354993
Content-Type: application/xop+xml; charset=UTF-8; type=“text/xml”
Content-Transfer-Encoding: 8bit
Content-ID: rootpart@soapui.org

<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:san=“http://euzdsag001/Sandbox.Jacob.DaimlerNMF.AttachmentPOC”>
soapenv:Header/
soapenv:Body
san:normalAttachment

<inc:Include href=“cid:http://www.soapui.org/12363165705270” xmlns:inc=“http://www.w3.org/2004/08/xop/include”/>
</san:normalAttachment>
</soapenv:Body>
</soapenv:Envelope>
------=_Part_224_1880766616.1458031354993
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: http://www.soapui.org/12363165705270

Please check attachment as well…

Can you suggest any idea how to capture the request in webMethods?

Regards,
Jacob B

raw.PNG

As the SOAP message itself is contained in one part, and the binary content is in a separate part. The content element in the SOAP message just has a reference to the binary part. Hence you should use the same reference ( ContentID in attachment should be same as XOPObject tag cid: value.

Regards

Hi Sasank,

I have got the attachment in webMethods. PFA the SOAP UI screenshot. But i have to use built in service pub.soap.utils:getXOPObjectContent to view the content.

Do you have any other service to view the actual MTOM request received?

Regards,
Jacob B

Hi All,

The issue resolved. Please refer web services developers guide. All the information is present in it.

Regards,
Jacob B

Jacob,

Thanks for updating the final closing info back in this thread!! :smiley:

HTH,
RMG