HELP Required on WebServices

Hi There,

We need to invoke a webservice [from webMethods] which takes 2 parameters as input and provides 3 fields as output and is hosted on a application server . The webService team is not providing us the WSDL file.

Can you help us out on - how to invoke a webService[which has no WSDL File] from webMethods. Any help with the code is very much appriciated.


Atleast they are going to provide the url for the wsdl file.Create a webservice connector specifying this url and you are ready to go.


Hi Ramesh,

Thanks for the reply.

No. They are not providing any URL for the WSDL file.It will be a xml over HTTP response for the webService request.


“…webService team is not providing us the WSDL file…”

What kind of “webService team” refuses to provide WSDL files? Seems a bit absurd. One way or another, the “webService team” is going to have to provide some information for how to properly invoke their service. A WSDL is the easiest way to do this.

From the webMethods Web Services Developer’s Guide, page 16:

“If you do not have a WSDL document and you would like to use Developer to create one, see the chapters in this guide for generating WSDL documents that use the SOAP RPC, SOAP Message, HTTP POST, or HTTP GET protocols.”

You should be able to find what you need there.

That is the most ridiculous thing I have heard of.

It brings to mind my favorite Cool Hand Luke quote: “What we’ve got here is failure to communicate!” (click on the second link to listen to the quote)

If they have created a WSDL but won’t provide it to your team, you can stop trying to invoke their service. Why go to the trouble of exposing something as a web service if you are not going to share the WSDL that describes the service with the people that need to consume it?

What do they want to you do, send random XML messages to their server (you’ll have to guess the endpoint URL, too) for a billion years or so hoping for some spontaneous evolution to occur?

At least, they need to send you an XML Schema (XSD) that describes the input and output messages of the service. From the XSD, you can generate the document types that can be used to create a soap request and to parse the soap response.


This is ridiculous, but this is reality. I just finished integrating
our application with a outside company who still say their services
as “custom webservices” but in layman’s term what I did is used the
http client provided by webMethods to send XML request based on their
schema to get get back a response XML based on their schema. I created
document types in web methods out of their schemas and just at the
layer of invoking the 3rd party service converted those to XML string
using webMethods XML processing services.

Shashwata’s approach is what you are left with when someone claiming to provide a web service won’t give you a WSDL. You basically need to exchange schemas that contain definitions for the request and response messages associated with each operation or method to be invoked. Defining the elements contained in these messages is one of the functions of the WSDL file (contained in the types section).

WSDL files generated by webMethods Developer can currently only contain a single operation. This is a limitation, and not a best practice, but is technically correct from an interoperability standpoint. Hopefully, this will be addressed in an upcoming IS release. (BTW, the Developer web services connector will generate Flow to invoke all of the operations in a multi-operationn WSDL, you just can’t create one)