Consume an attachment service (Swaref and MTOM)

, ,
1

Hi,

I have to consume an existant WS that returns a PDF attachment (Swaref with MTOM enabled).
I’ve created the Web descripter consumer in webMethods and the type of attributes that returns the data is :

swaRef {Index of /profiles/basic/1.1/xsd}

How may I do to wrap the swaref to base64Binary please ?

Testing the initial WS in SoapUI, I can see the PDF, but testing my webMethods service I do not succeed to see it.

WSDL part :


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://www.mif.com/service/" xmlns:swaRef="http://ws-i.org/profiles/basic/1.1/xsd" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.mif.com/service/">

<xs:import namespace="http://ws-i.org/profiles/basic/1.1/xsd" schemaLocation="http://ws-i.org/profiles/basic/1.1/swaref.xsd"/>

...
<xs:element name="docAttache" type="swaRef:swaRef"/>

Regards

2

Hi,

When you test the Mtom compressed file in webMethods you will get null values.

We cannot do testing and debugging for this as this will be encoded string.

One suggestion:

we can do writetofile and save it in file system to validate the PDF file.

also after consuming the WSDL you need to set the property attachment enabled as true.

Regards,
Syed

3

Thanks for your reply.
I set the Attachment property of my Descriptor service to true, but when I’m testing the WS in SoapUI, I still do not see the attachment link.
(when I test the initial WS in SoapUI, I can see the link in the attachment tab)

Am in not missing anything else, I do not have to convert my swaref attribute ?

Regards
Cédric

4

Hi Cedric,

You can check here for MTOM related problems: Issue with pub.soap.utils:getXOPObjectContent ..... MTOM objects - webMethods - Software AG Tech Community & Forums

Also there are other threads on the Tech Community regarding this.

FYI: You won’t see the contents of the xopObject in debug mode. It will appear as null.

Hope it helps.
Vlad Turian

5

Hi Cedric,

  1. While consuming the WSDL in wM you need to select enable MTOM check box.
  2. By doing the objects will come in “XOPObject” format.
  3. then we need to decode this XOPObject.

After this you can perform your operations like writeToFile and all.

as Vlad said we wont be able to debug this service because the content will be visible as null.

Regards,
Syed Faraz Ahmed

6

Hi,

I have never succedeed in getting byte data from Swaref attribute. Enabling MTOM did the not change the issue.
I’ve tried to write the file on the file system, but the file was invalid.

The only solution i’ve found, is to change the source Consumer attribute and make it “base64Binary” to receive a XOPObject :

<xsd:element name="docAttache2" type="xsd:base64Binary" xmime:expectedContentTypes="application/pdf"/>

After that, writing the file on the filesystem works… or transmit the PDF in attachment from my new web service works too…

Regards

7

Dear Cedric,

Glad to hear you are able to resolve the issue.

For any MTOM implementation the data type which you want to receive in compressed format should be set as base64Binary and then while importing we need to select the check box in order to make it an XOP object.

I have attached a comparison file which show what will happen even if we set the data type as base64Binary and didn’t select the check box while consuming the WSDL.

Regards,
Syed Faraz Ahmed

MTOM.jpg
MTOM.jpg907×347 61.5 KB

8

Hi Syed,

Very interesting. Thanks for that complement information.

Regards

9

Hi All,

I am also facing the same issue and even after enabling the MTOM while creating the consumer, I am unable to get the pdf documents in the XOP object.I have also enabled extended settings on IS needed for MTOM.

Following error is thrown from pub.client.soapClient call:

S.0088.9139] Output parameters do not conform to targetOutputSignature:
errorCode=VV-004
pathName=/tns:getResultResponse/tns:ServiceResult/tns:Document
errorMessage=[ISC.0082.9033] Java type mismatch; expected com.wm.util.XOPObject, got com.wm.app.b2b.services.CValues

errorCode=VV-004
pathName=/tns:getResultResponse/tns:ServiceResult/tns:Report
errorMessage=[ISC.0082.9033] Java type mismatch; expected com.wm.util.XOPObject, got com.wm.app.b2b.services.CValues

errorCode=VV-004
pathName=/tns:getResultResponse/tns:ServiceResult/tns:Signature
errorMessage=[ISC.0082.9033] Java type mismatch; expected com.wm.util.XOPObject, got com.wm.app.b2b.services.CValues
10

Hi,

For me to have my service working, I’ve had to change the external service called (the one which sends me the PDF) with this :

<xs:element name="docAttache" type="xs:base64Binary" xmime:expectedContentTypes="application/pdf"/>

(before, the attribute was a Swaref type, but the webMethods support confirmed me, that Swaref is no supported)

In my new webMethods service, I’ve added an attribute of type XOP :
Java wrappers type = com.wm.util.XOPObject

Did you configure this option for the Web service Descriptor ?
Attachment enabled = true

Regards

11

Hi Ajit,

There seems to be signature mismatch in this case.
It seems you are trying to pass an array of values and expected value is XOP object.

Regards,
Syed Faraz Ahmed

12

Hi Cedric,

In my case I cannot change the service that is sending the data.It is some service provider. I have created connectors using the provider’s WSDL . And yes i have enabled the attachment to true. The data they are sending are 3 attachements .I have attached the success I received from SOAP UI. The data that connector is expecting is of type XOP objects. From Soap UI sucess the attachments have XOP as a type(as per my understanding). I don’t understand why it is not getting populated. Can I do some response processing to map what is returned by provider to correct data type.

Regards,
Ajit

authentidate.PNG
authentidate.PNG1515×567 71.8 KB

13

Hi Syed,

I am the consumer in this case and what I am expecting is XOP. But getting some other data type from provider.

Regards,
Ajit