Some time ago i posted a problem about IS adding strange xml-elements to a soap response (see: [URL]wmusers.com).
I finally upgraded to version 7.1.2, but the problem is not resolved.

I have made a short example that illustrates the problem. I have attached a zip containing the wsdl, xsd, package and the faulty response to this post. Following is the description of what i did:

• Created a WSDL and XSD outside of Developer (document/literal/wrapped).
• Imported the WSDL using Developer (New => Web Service Descriptor => WSDL URL).
• Complete the FLOW service.
• Called the web service using SOAPUI (see Request.xml and Response.xml).

The problem is that the response contains some ser-root elements which do not belong there.
Finally I took the same wsdl and created an implementation using AXIS2 and everything
works as expected.

I would like to know, whether someone has experienced similar problems with
Top-Down-Development of WebServices using the wm Developer or can confirm the problem.
Maybe there is already a work-around for the problem, or made a mistake somewhere.

Thank you in advance,

tom
problem.zip (16.4 KB)

I think “ser-root” is just the default namespace name WM generate for the root element of the response body. The corresponding namespace is the targetNameSpacce you specified in WSDL.
The interface fields are what defined under this root node. Those are what you really care about, right?
I guess your client code can alway assume the root will have ser-root as the namespace. But if there is way to customize it will be nice.
HTH,
Tong
I’m also

thanks for your reply. You’re right that i only care about the elements under the ser-root:Messages_LoadMessage_Output element. And if i would code my client myself (including deserialisation), i would just ignore it.

The real problem is that the prefix ser-root isn’t defined anywhere so the soap message produced isn’t even well-formed! On top, the Messages_LoadMessage_Output type is not part of the wsdl. The result is that no client generated from the wsdl will accept the soap response.

Since i’m not sure whether i made a mistake somewhere, i would like to know if anybody has experienced similar problems using developer with a wsdl containing complex types.

It turned out, that the problem is actually a bug. The bug is fixed with Fix IS_7-1-2_WebSvcsXML_Fix2.

Thanks for following up, Tom!

Hello tom1299, I am encountering the same problem and I have IS_7-1-2_WebSvcsXML_Fix8 with WM7.1.2 Any suggestions please?

uh, it’s been more than three years since the problem came up. I have to admit that we abandoned IS a little later because of other problems we had. Back then we submitted the bug to SAG and they fixed it with IS_7-1-2_WebSvcsXML_Fix2. The example that is part of this thread worked with this fix. The fix along with the bug id was documented in the release notes of that patch. I will try to find those release notes and the bug id so that you could contact IS support.

Thanks tom1299. Wainting for your reply.

Hi All

I need to know what fix will solve the issue in webMethods 8.0

Plz suggest

ser-root is a prefix to a namespace what issue are you having with it?

Hi Griffima

thanks for the reply

whenever im passing a Soap request in the Soap UI with certain prefix of the namespace, that prefix is changed to ser-root in the Soap response(ser-root is mentioned no where in the Soap Request).

Reading the posts below i got to know that is the default prefix generated by webMethods and that SAG provided a fix as it was a bug.

I need to know whether we have any solution to change this in webMethods 8.0 or whether it still is a bug and that we need to use a fix to solve the issue.

I’d call it a quirk rather than a bug. Prefix is irrelevant, it’s just a shorthand for the actual namespace. The fact that the IS generated WSDL uses tns as the prefix shorthand versus the runtime IS using ser-root is just a quirk rather than a bug. A calling client should not expect to find a hardwired prefix, that would actually be a bug or a flawed implementation of a web services stack on the calling client side. As long as the shorthand points to the correct namespace, then the interpretation is correct.

If SoftwareAG releases a “fixed” for this it would be for convenience sake to help out legacy web services stacks that don’t handle namespaces correctly.

Thanks a lot for the clarifiaction Mark.

-Mayank