I noticed when we receive SOAP responses, attributes such as xsi:type =“String” have been added to all the elements in the SOAP body such as:
<item xsi:type=“sc1:SharedDataPoolType”>
<fieldName xsi:type=“xsd:string”>majorActivityDescription</fieldName>
<value xsi:type=“xsd:string”>This business distributes bananas.</value>
</item>
However, using the WSDL and associated schemas used for the input/output parameters these attributes weren’t there. So now instead of IS representing an XML element as a string it’s representing it as a document with 2 attributes (*body and @xsi:type) so nothing’s mapping correctly. Is this standard encoding practice in SOAP and if so is there a way to account for this in the flow. (ie we don’t want to have to remap everything)

Hi Will,
I faced the same problem. I had GLUE as soap generator and webMethods IS as a web service provider . I used the default SOAP processor provided by webMethods to process my soap requests. I used documentToRecord to convert the soap data into webMethods records.
May be we shouldnt be using it for SOAP for the simple reason that documentToRecord doesnt seem to understand XML or SOAP in the terms we expect.
anyway… If youre trying to do a similar thing the following may be of help to you.
i. Suppress the xsi:type information itself. For glue I changed a few soap-optimization parameters which can remove this xsi:type info.

     (or) 

ii.         Create a new Record by making Make all string fields to records and add a *body to all these new record fields    
= fieldName 
*body 


Now map * body to to your Original String field of your orignal records.  So you have two records. One to get the soap data come into and one for remaining flow.

Thanks for the response Sudheer! Unfortunately our client is adding the xsi:type stuff and won’t change it. For us to create new records with the *body is what we’re trying to avoid. I’d like something like telling webMethods to ignore the attributes of those types but I don’t think it can be done.