wsdl:http://www.webservicex.net/stockquote.asmx?WSDL&method=GetQuote
WSDL Connectors
Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version. |
If you plan to connect to an external web service that exposes a WSDL file, the recommended connector to use is the Web Service Consumer. |
The Axis and CXF transports provide WSDL connectors that can be used for invoking remote web services by obtaining the service WSDL. Mule creates a dynamic proxy for the service and then invokes it. Web Service Consumer.
Generic WSDL Endpoints
A WSDL endpoint enables you to easily invoke web services without generating a client. At startup, it reads the WSDL to determine how to invoke the remote web service during runtime. When a message is sent through the WSDL endpoint, it is able to construct a SOAP message using the message payload and its knowledge of the expected payload format from the WSDL.
You must provide the full URL to the WSDL of the service to invoke, and you must supply a method
parameter that tells Mule which operation to invoke on the service:
The WSDL URL is prepended with the wsdl:
prefix. Mule checks your class path to see if there is a WSDL provider that it can use to create a client proxy from the WSDL. Mule supports both Axis and CXF as WSDL providers. If you want to use a specific one, you can specify it on the URL as follows:
wsdl-cxf:http://www.webservicex.net/stockquote.asmx?WSDL&method=GetQuote
or
wsdl-axis:http://www.webservicex.net/stockquote.asmx?WSDL&method=GetQuote
In general, you should use the CXF WSDL endpoint. The one limitation of the CXF WSDL provider is that it does not allow you to use non-Java primitives (objects that are not a String, int, double, and so on). Sometimes the Axis WSDL generation will not work (incorrect namespaces are used), so you can experiment with each one to see which works best.
Note that there are no specific transformers to set on WSDL endpoints.
Specifying an Alternate WSDL Location
By default, the WSDL provider will look for your WSDL by taking the endpoint address and appending ?wsdl
to it. With the CXF transport, you have the option of specifying a location for the WSDL that is different from that specified with the ?wsdl
parameter. This may be useful in cases where the WSDL isn’t available the normal way, either because the SOAP engine doesn’t provide it or the provider does not want to expose the WSDL publicly.
In these cases, you can specify the wsdlLocation
property of the CXF endpoint as follows:
In this case, the WSDL CXF endpoint works as it normally does, except that it reads the WSDL from the local drive.
Example of the CXF WSDL Endpoint
This example demonstrates how to take multiple arguments from the console, invoke a web service, and print the output to the screen.
This service requires two arguments: the "from" currency code and the "to" currency code. When the CXF dispatcher prepares arguments for the invocation of the service, it expects to find a message payload of Object[]
– that is, an Object array. In the case of the Currency Converter, this should be an array of two Objects - the "from" currency and the "to" currency.
There are several ways to construct this object array, but the easiest way is to use the custom transformer
, which translates a delimited String into an Object array. In the example below, you simply type in a String in the format of <fromCurrency>,<toCurrency>
.
For example, type "EUR,USD" to get the conversion rate for Euros to US Dollars, and you’ll get something like this: