The WSD auto generation tool appears to ignore the response/output message schema definition as defined in the WSDL. Anybody doing top down WSDL development? Look at the output message in a tool like SoapUI and you will see that webMethods IS is adding a top level root element in the SOAP body. It’s the input message with Response appended to it.

Here is an example:

<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<ser-root:sendRequestResponse xmlns:ser-root="http://www.wm.com">
<webm:sendRequestResponse xmlns:webm="http://www.wm.com">
<webm:RequestResponse>
<webm:LastName>BeB</webm:LastName>
</webm:RequestResponse>
</webm:sendRequestResponse>
</ser-root:sendRequestResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Several problems with this:

1-Doesn’t match the schema definition which means other tools like .Net which try to import the WSDL aren’t going to work because the classes are not going to be defined correctly.

2-Can’t override it in IS, it’s locked down.

Why is it doing this? As far as I can tell it’s putting the entire reference document into the WSD Response/Body Document instead of just the payload. To see an example of what I’m seeing take a look at Mark C’s DocLitWebServiceExample7.1.

Look at the OrderService WSD. Take a look at the createOrder service. The response definition has a document reference to ResponseStatus which is the payload of the output message. If you run the createOrder you get this as the output:

<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<ser-root:createOrderResponse xmlns:ser-root="urn:wmusers.com.services.OrderService">
<ResponseStatus>
<ReturnCode>0000</ReturnCode>
<ResponseMessage>
<Code>OK</Code>
<Severity>Info</Severity>
<Description>OrderID 1 created successfully</Description>
</ResponseMessage>
</ResponseStatus>
</ser-root:createOrderResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Which is what you would expect if you look at the webMethods auto generated WSDL. However if you take that WSDL or any other WSDL you created by hand and auto generate the WSD, you get a different message definition. Instead of ResponseStatus as the document reference for the createOrder/Response body message definition, you get createOrderResponse as the document reference and here is the problem. When you then run the service, here is the output:

<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<ser-root:createOrderResponse xmlns:ser-root="urn:wmusers.com.services.OrderService">
<tns:createOrderResponse xmlns:tns="urn:wmusers.com.services.OrderService">
<ResponseStatus>
<ReturnCode>sdf</ReturnCode>
<ResponseMessage>
<Code>334</Code>
<Severity>3</Severity>
<Description>test</Description>
</ResponseMessage>
</ResponseStatus>
</tns:createOrderResponse>
</ser-root:createOrderResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Notice the extra Node that webMethods IS has thrown in.

I can hand code the provider in IS to match the WSDL and make it work correctly. But we shouldn’t have to do this. Anybody found anything different? Is there a magic switch I’m missing here?

It has been fixed in 7.1.1 of developer and IS. :happy:

Thanks for debugging this for me before I get there!

well I do what I can do :lame:.

webMethods has managed to break to the fix with one of their fix packs that was required for us. They have reintroduced a bug with the soap response. I have a ticket open with them, I’ll post back the findings. It’s a slightly different version of the same problem I reported earlier. This time the root element of the response message is having it’s name change.

Here is an example of the correct response prior to the patch:

        <webm:sendResponse xmlns:webm="http://www.wm.com">
<webm:Response>
<webm:firstname>bob</webm:firstname>
</webm:Response>
</webm:sendResponse>

Here is an example of the incorrect response after the patch:

<webm_x003A_sendResponse xmlns:webm="http://www.wm.com">
<webm:Response>
<webm:firstname>bob</webm:firstname>
<webm:address>asdf</webm:address>
<webm:state>asdf</webm:state>
</webm:Response>
</webm_x003A_sendResponse>

Notice the webm_x003A_sendResponse. It would appear it’s getting confused on the : which is required for a prefix. 3A is hex for the :

The other thing the fix pack introduced was namespace bloat. This is the fix that is the problem - IS_7-1-1_SrvPrtcl_Fix4.zip. You have to look at the soapResponse on the wire to see this happening.

A sample element of the soap message on the wire prior to the fix:

<webm:firstname>bob</webm:firstname>

A sample element of the soap message on the wire after the fix:

<webm:firstname xmlns:webm="http://www.wm.com">bob</webm:firstname>

That can get pretty hefty for large documents. I’ll let you know what I find out.

Mark,

I faced the same problem with 7.1.1 IS but on the other side of the equation i.e. when I created the WSD consumer from client’s WSDL the flow service was generating the request with those extra prefixes in the field tags :

code:

Following was the code generated by SOAPUI:

I opened the SR with webMethods and they acknowledged it as a bug and told me that their developer are working on it. I created my own flow service with some tweaks to call client’s webservice to resolve it.

i am having a wsdl from which I generated the provider as well as consumer.
Inside the provider’s flow service (representing 1 of my webservice operations) i invoked some service and mapped its response to the output of that flow service.

Now, when I run this service it seems to be working fine…No issues !!!

But, when I created a consumer from the same wsdl (which I used for generating provider) and tried to invoke the same operation, I am getting an empty response; rather just some with some headers in it…I have applied srvprtcl_fix5 and all other fixes that are required for it…
Has anyone faced this problem before?

OK…so that was some thing going wrong momentarily…i re-created the consumer and it seems to be working fine for me…
though, now i am getting response prefixed with tns_x003A
Any luck with ticket for you guys till now?

Product support folks have been able to duplicate the problem. It has been sent over to the development maintenance team.

IS_7-1-1_WebSvcsXML_Fix7 corrects the issue.

Good grief, my ticket is open for 3 months now, although the priority is low, they haven’t told me about this fix, they said that development team is working on it and told me a workaround which I did applied before opening the ticket, but never mentioned this fix. I will try this out and see if this fixes the issue. Thanks for the update Mark.

Don’t feel bad, I had to escalate to the world just to get a response that someone was working on my ticket. Support has been hit or miss lately.

I’ve had to put another one about arrays with this same WSD process.