Using 'any' types in WSDL seem to confuse the MTOM mechanism
Hi
We see this problem in both of:
- soapUI 4.5.1
- soapUI 3.6.1
under Windows7 SP1.
We want to test a SOAP over HTTPS service which expects MTOM attachments in one WSDL field, either a TIF or an XML file. It's a repeatable field so there can be multiple TIF and XML attachments in the final request.
Elsewhere in the WSDL there is an 'any' field. This lets us insert a data structure of another complex type, we have one called OrderData which has levels of structure such as Person, Address, OrderInformation etc. Fields under those levels are mostly simple string fields such as firstName, name, street and city. There are also non-string fields, e.g. a Person/birthday has type date. Essentially this:
with these straightforward string fields included in 'Content':
The expected MTOM attachments get generated ok but the problem is that EVERY field used inside the 'any' structure somehow also seems to get treated as an MTOM reference, even though they just contain normal stuff such as "Sherlock", "Holmes" and nothing like 'cid:xxx' supposedly linked to an actual attachment. We see separate MIME attachments for each firstName, name, street, etc! Every filled OrderData field is affected. Worse, at the receiving side, each field's content has been changed to base64 binary, so all of our OrderData values are no longer human-readable. Non-string fields also get converted: if we try to fill the dateOfBirth date field with a valid date, the receiving service throws an exception as it can't parse the new mangled base64 binary content against the WSDL schema.
This is what we see under the 'Raw' tab after sending the request:
and this is what arrives at the service which receives the request:
All other fields which were not inside the 'any' arrive ok, i.e. those in 'Header' or 'Document' all have their original unchanged content.
Setting the 'enable MTOM' property to 'false' fixes the 'any' fields but then we can't attach our MTOM TIFs and XMLs to our test request in soapUI.
Is there some property we should be setting to stop this from happening?
As a workaround so that we can keep on testing our service, I'll change the soapUI concrete WSDL to have the OrderData structure in-line without the 'any', this should work but it means that we're not testing the actual service WSDL (which we're not able to change). It also means we'll have to create a new in-line workaround WSDL each time a new 'any' structure is introduced. There will be many of these, so it's not a viable longer term solution.
I've played around with the properties but couldn't find anything to fix this. Any help in resolving this appreciated, thanks!
We see this problem in both of:
- soapUI 4.5.1
- soapUI 3.6.1
under Windows7 SP1.
We want to test a SOAP over HTTPS service which expects MTOM attachments in one WSDL field, either a TIF or an XML file. It's a repeatable field so there can be multiple TIF and XML attachments in the final request.
Elsewhere in the WSDL there is an 'any' field. This lets us insert a data structure of another complex type, we have one called OrderData which has levels of structure such as Person, Address, OrderInformation etc. Fields under those levels are mostly simple string fields such as firstName, name, street and city. There are also non-string fields, e.g. a Person/birthday has type date. Essentially this:
<OrderRequest>
<Header>
...
</Header>
<Body>
<Content>
(any)
</Content>
<Documents>
<Document>
<docId>cid:file.tif</docId>
<docType>...</docType>
...
</Document>
</Documents>
</Body>
</OrderRequest>
with these straightforward string fields included in 'Content':
<OrderData>
<Person>
<firstName>Sherlock</firstName>
<name>Holmes</name>
<!--birthday>1854-01-06T02:21:02</birthday-->
</Person>
<Address>
<houseNr>221b</houseNr>
<street>Baker Street</street>
...
</Address>
...
</OrderData>
The expected MTOM attachments get generated ok but the problem is that EVERY field used inside the 'any' structure somehow also seems to get treated as an MTOM reference, even though they just contain normal stuff such as "Sherlock", "Holmes" and nothing like 'cid:xxx' supposedly linked to an actual attachment. We see separate MIME attachments for each firstName, name, street, etc! Every filled OrderData field is affected. Worse, at the receiving side, each field's content has been changed to base64 binary, so all of our OrderData values are no longer human-readable. Non-string fields also get converted: if we try to fill the dateOfBirth date field with a valid date, the receiving service throws an exception as it can't parse the new mangled base64 binary content against the WSDL schema.
This is what we see under the 'Raw' tab after sending the request:
<typ:Content>
<ns1:OrderData xmlns:ns1="http://www.xxx.com/2013/xxxxxxx/Order/DataTypes">
<ns1:Customer>
<ns1:Person>
<ns1:FirstName><inc:Include href="cid:http://www.soapui.org/271853968957230" xmlns:inc="http://www.w3.org/2004/08/xop/include"/></ns1:FirstName>
<ns1:Name><inc:Include href="cid:http://www.soapui.org/271853969235906" xmlns:inc="http://www.w3.org/2004/08/xop/include"/></ns1:Name>
</ns1:Person>
...
<ns1:Customer>
...
and this is what arrives at the service which receives the request:
<ns1:OrderData xmlns:ns1="http://www.xxx.com/2013/xxxxxxx/Order/DataTypes">
<ns1:Customer>
<ns1:Person>
<ns1:FirstName>U2hlcmxvY2s=</ns1:FirstName>
<ns1:Name>SG9sbWVz</ns1:Name>
</ns1:Person>
<ns1:Address>
<ns1:HouseNr>MjIxYg==</ns1:HouseNr>
<ns1:Street>QmFrZXIgU3RyZWV0</ns1:Street>
...
</ns1:Address>
...
<ns1:Customer>
</ns1:OrderData>
All other fields which were not inside the 'any' arrive ok, i.e. those in 'Header' or 'Document' all have their original unchanged content.
Setting the 'enable MTOM' property to 'false' fixes the 'any' fields but then we can't attach our MTOM TIFs and XMLs to our test request in soapUI.
Is there some property we should be setting to stop this from happening?
As a workaround so that we can keep on testing our service, I'll change the soapUI concrete WSDL to have the OrderData structure in-line without the 'any', this should work but it means that we're not testing the actual service WSDL (which we're not able to change). It also means we'll have to create a new in-line workaround WSDL each time a new 'any' structure is introduced. There will be many of these, so it's not a viable longer term solution.
I've played around with the properties but couldn't find anything to fix this. Any help in resolving this appreciated, thanks!
