Nav
You are viewing an older version of this section. Click here to navigate to the latest version.

Web Service Consumer

When developing applications with Mule, users often need to be able to consume a SOAP Web service to acquire data from an external source. In the best case scenario, you can use an existing Anypoint Connector in your Mule application to connect to a specific service provider, such as Zuora or Avalara. However, where no service-specific connector exists to facilitate the connection, the quickest, easiest way to consume a Web service from within a Mule application is to use the Web Service Consumer.

Using the information contained in a service’s WSDL, this connector enables you to configure a few details in order to establish the connection you need to consume a service from within your Mule application. Simply identify the location of the Web service’s WSDL file, then ask the Web Service Consumer to configure itself from the WSDL – host, port, address.  

Before this component existed in Studio, you may have configured an HTTP connector and SOAP Component in a Mule flow to be able to consume a Web service; now you can simply insert the Web Service Consumer connector into your flow. Requiring less effort to configure. The Web Service Consumer also offers extra functionality to help you build out your application:

  • Used in conjunction with a DataWeave transformer, the Web Service Consumer makes use of DataSense functionality to acquire information about the expected format and structure of the input or output, so as to eliminate the guesswork in trying to figure out what to send to, and what you’ll receive from, a SOAP Web service

  • Used in conjunction with a DataWeave transformer, you can visually map the input you receive (SOAP header or body) into another data format or structure for further processing

  • Secure your Web service requests using the functionality embedded within the Web Service Consumer to add a username token to requests, and/or WS-Security timestamp

For example, imagine you wish to build an application in which you need to gather information about the last price at which a stock traded. After accepting an end-user request, you need to consume an external SOAP Web service that checks for the most recent trade of a particular stock, and the price at which it sold, then return a response. Such an application could make use of the Web Service Consumer to consume the stock quote information, then uses a DataWeave to map the results to a format that could be returned to the end-user. See first figure below; a second example follows below it.

Web Service Consumer Studio Flow with callouts

The component formerly known as the SOAP Connector is now known as the CXF Component. It should not be confused with the Web Service Consumer.

Prerequisites

This document assumes that you are familiar with Anypoint Studio; review the chapter on Anypoint Studio Essentials to learn more about developing with Mule ESB’s graphical user interface. This document also assumes you are familiar with DataWeaveGlobal Elements, and DataSense.

Installation

You can install a connector in Anypoint Studio using the instructions in Installing a Connector from Anypoint Exchange.

Limitations

  • The Web Service Consumer interfaces only with SOAP Web services, not REST APIs.  

  • Within Mule, the Web Services Consumer is available for use only in conjunction with the following connectors:

  • FTP

  • File

  • HTTP

  • JMS

  • SFTP

  • HTTPS

Basic Anatomy

To use a Web Service Consumer in your Mule application, you must carry out three tasks:

  1. Add the WSDL file of the service you want to consume to your Mule project.

  2. Embed a Web Service Consumer element in your Mule flow and configure it to define the operation to perform, and identify the Global Web Service Consumer element it references.

  3. Configure the Global Web Service Consumer element in which you reference the service’s WSDL, enable DataSense, and apply any security settings that the service provider demands. To really take advantage of the design-time power of the Web Service Consumer, consider using it in conjunction with the following Mule features:

    • DataSense: When enabled, DataSense uses information in the WSDL to automatically extract metadata about the data structure and format a SOAP Web service delivers or expects. When this functionality is enabled (in the Global Web Service Consumer element), Mule does the heavy lifting of discovering the type of data that is sent or expected by the service.

    • DataWeave transformer: When used in conjunction with a DataSense-enabled Web Service Consumer, DataWeave can automatically extract payload or header metadata from the service that you can map and transform through a visual interface. For example, if you configure a Web Service consumer in your application, then drag a DataWeave transformer after it, DataWeave uses the information that DataSense extracted to pre-populate the input values for mapping, so that you only need to confirm (or adjust) the selections, then proceed to mapping to your desired output.  In other words, DataSense makes sure that DataWeave knows the data format and structure with which it must work so you don’t have to figure it out manually.

For more information on best design-time practices with DataSense and DataWeave, consult the DataSense documentation.

Configuring Web Service Consumer

To prepare an application to use a Web Service as in one of the examples above, you must first add the Web service’s WSDL to your Mule project, then configure, at minimum, the required parameters for the Web Service Consumer element and a Global Web Service Consumer element. The diagram and section below describe how to address these requirements.

Flow chart on when to use WS consumer with DataWeave

  1. Begin by acquiring the WSDL file for the SOAP Web service you intend to consume, or identifying the URL of the WSDL.

  2. If you are using a WSDL file, copy the file into the src/main/resources folder of your Studio project. (You can drag and drop the file to copy it to the folder.) If using a URL, there is no need to copy anything to your Studio project.

  3. Drag a Web Service Consumer connector into a flow in your application. Click the Web Service Consumer icon to open its Properties Editor, then change the default value of the Display Name of the connector, if you wish.

  4. Define a global configuration for the connector: click the plus sign next to the Global Configuration field. 

  5. In the window that opens, begin by entering a value in the WSDL Location field. Populate this field first. To do this either:

    • Type the WSDL’s URL in the field

    • Click the …​ button to provide a filepath and filename of the WSDL file you copied into the src/main/resources folder of your project.

      Upon filling this field, you give Studio the opportunity to read the contents of the WSDL and automatically populate the remaining empty fields — Service, Port and Address — using information contained in the WSDL file. Alternatively, you can manually populate these fields with the appropriate information about the Web service. 

      Studio Global Element screen with sample info

  6. Confirm that the Enable DataSense box is checked, then click OK to save.

  7. Notice that Studio auto-populates the following fields in the Properties Editor of the Web Service Consumer element in your flow:

    • Global Configuration - name of the Global Web Service Consumer that you just created.

    • Operation - name of an operation that the Web service supports for its consumers. 

  8. Choose an available operation in the Web Service Consumer element, if you wish (and if the SOAP Web service indeed offers more than one operation), then click inside the canvas to auto-save your configuration.

wsc_local

  1. Begin by acquiring the WSDL file for the SOAP Web service you intend to consume, or identifying the URL of the WSDL.

  2. If you are using a WSDL file, copy the file into the src/main/resources folder of your Studio project. (You can drag and drop the file to copy it to the folder.) If using a URL, there is no need to copy anything to your Studio project.

  3. Above all the flows in your application, add a global ws:consumer-config element to your application. Configure its attributes according to the code sample below to define how to connect to the Web service you intend to consume. For a full list of elements, attributes and default values, consult  Web Service Consumer Reference.


    
            
         
1
<ws:consumer-config name="Web_Service_Consumer1" wsdlLocation="src/main/resources/sample_wsdl_2.txt" service="StockQuoteService" port="StockQuotePort" serviceAddress="http://example.com/stockquote" doc:name="Web Service Consumer"/>
  1. Add a ws:consumer element to a flow in your application. Configure its attributes according to the code sample below to define the global Web Service Consumer to reference, and the operation to perform with a request to the Web service. For a full list of elements, attributes and default values, consult  Web Service Consumer Reference.


    
            
         
1
<ws:consumer doc:name="Web Service Consumer" config-ref="Web_Service_Consumer1" operation="GetLastTradePrice"/>

Web Service Consumer and DataWeave

As stated above, when used in conjunction with a DataSense-enabled Web Service Consumer, DataWeave can automatically extract payload or header metadata that you can use to map and or transform to a different data format or structure through the DataWeave language. When you have a configured DataSense-enabled Web Service Consumer in your flow, you can drop a DataWeave transformer next to it – preceding or following it – and DataWeave automatically extracts the information that DataSense collected from the WSDL about the expected format and structure of the message. 

  • If DataWeave follows the fully-configured Web Service Consumer, DataWeave has access to its Input values and you can use these as inputs to create your custom output. 

  • If DataWeave precedes the fully-configured Web Service Consumer, DataWeave creates a scaffolding that produces an output that matches what the Web Service Consumer expects to receive (see below).


         
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "item_amount": "????",
  "payment": {
    "currency": "????",
    "installments": "????",
    "payment-type": "????"
  },
  "product": {
    "model": "????",
    "price": "????"
  },
  "salesperson": "????",
  "shop": "????"
}

To take advantage of the Web Service Consumer-DataSense-DataWeave magic, be sure to configure these elements in the following order:

  1. The Global Web Service Consumer element, with DataSense enabled

  2. The Web Service Consumer connector in a flow in your application, which references the Global Web Service Consumer connector 

  3. The DataWeave transformer, dropped before or after the Web Service Consumer connector in your flow

Adding Custom Headers

SOAP headers should be created as outbound properties. You can do that through the Property transformer

Outbound properties that begin with a soap. prefix are treated as SOAP headers and ignored by the transport. All properties that aren’t named with a soap. prefix are treated as transport headers (by default, the WSC uses the HTTP transport).

properties_soap

<set-property propertyName="soap.myProperty" value="#[payload]" doc:name="Property"/>

When configuring the header manually, the value you pass should have the structure of an XML element, it shouldn’t be a plain pair of key and value. Using a set property element, for example, the value of the property must contain the enclosing XML tags, like so:


               
            
1
2
3
<set-property propertyName="soap.Authorization"
value="<auth>Bearer
MWYxMDk4ZDktNzkyOC00Z</auth>"/>

The example above works, the one below doesn’t:


               
            
1
2
<set-property propertyName="soap.Authorization" value="Bearer
MWYxMDk4ZDktNzkyOC00Z"/>

Mapping SOAP Headers

When used in conjunction with a Web Service Consumer, a DataWeave offers you the option of mapping and transforming a message’s payload, properties or variables by picking different inputs.

  1. First, be sure you have configured a DataSense-enabled Web Service Consumer in your flow and set a DataWeave transformer to follow it. Click the DataWeave icon in the canvas to open its Properties Editor.

  2. If the SOAP service returns a response with headers, the tree in the input section of the DataWeave transformer has multiple inbound properties in it. Each header enters the Mule flow as an inbound property. You can double click it to open this property in a different tab and provide test data.

  3. In the transform’s input directives you can see how this input is being referenced, use this as part of the path when refering to one of the elements in the header.

With DataWeave, you can use multiple inputs in a single transform, so you can take information from both the SOAP body and the SOAP headers to produce your output.

To produce multiple outputs, you must create separate transforms, but these can be hosted in a single DataWeave transformer on your flow. So in a single DataWeave transformer you could host a transform that populates the SOAP body and another that populates a SOAP header.

Web Service Consumer and DataSense Explorer

Use the DataSense Explorer feature in Studio to gain design-time insight into the state of the message payload, properties, and variables as it moves through your flow. The DataSense Explorer is most useful in understanding the content of a message before it encounters a Web Service Consumer, and after it emerges so as to better understand the state of the data your application is working with.

The DataSense Explorer in the example below offers information about the Payload, Variables, Inbound Properties and Outbound Properties contained that comprise the message object at the moment the message encounters the Web Service Consumer. Use the In-Out toggle at the top of the DataSense Explorer to view metadata of message as it arrives at, or leaves the message processor.

Message State Before Web Service Consumer

metadata_in

Message State After Web Service Consumer

metadata_out

Securely Connecting to a SOAP Web Service

Depending upon the level of security employed by a SOAP Web service, you may need to correspondingly secure the requests your Web Service Consumer sends. In other words, any calls you send to a Web service have to adhere to the Web service provider’s security requirements. To comply with this requirement, you can configure security settings on your Global Web Service Consumer connector.

The WSC allows you to:

  • Add an expiration to messages

  • Add username and password header to outgoing messages

  • Add a signature header to outgoing messages

  • Verify incoming messages for signature headers

  • Encrypt outgoing messages (at SOAP level)

  • Decrypt incoming messages (at SOAP level)

  1. Within the Global Web Service Consumer element’s Global Element Properties panel, click the Security tab:

wsc_security

  1. Based on the security requirements of the Web service provider, select to apply Username Token security, or a WS-Security Timestamp or both.

  2. Enter values in the required fields.

    For a full list of elements, attributes and default values, consult the Web Service Consumer Reference.

  3. Click OK to save your security settings.

Add child elements to the global ws:consumer-config element you configured in your application. Configure the child elements' attributes according to the code sample below. For a full list of elements, attributes and default values, consult Web Service Consumer Reference.


    
            
         
1
2
3
4
5
6
7
8
...
    &lt;ws:consumer-config name="OrderWS" wsdlLocation="enterprise.wsdl.xml" service="OrderService" port="Soap" serviceAddress="https://login.orderservice.com/services/Soap/c/22.0" doc:name="Web Service Consumer"&gt;
        &lt;ws:security&gt;
            &lt;ws:wss-username-token username="test" password="test" passwordType="DIGEST" addCreated="true" addNonce="true"/&gt;
            &lt;ws:wss-timestamp expires="30000"/&gt;
        &lt;/ws:security&gt;
    &lt;/ws:consumer-config&gt;
...

Verify the Response Timestamp

Not all web services provide a timestamp in their responses.
You need to verify this with the security requirements of your Web Service Provider.

You can determine the freshness of the response’s security semantics to your ws request by instructing Mule to verify the response’s timestamp using the mule.ws.checkWssResponseTimestamp attribute:

  • You can set it when starting Mule passing the following argument:

    
                 
              
    1
    
    -M-Dmule.ws.checkWssResponseTimestamp=true
  • Or you can set it as a wrapper configuration in your ${MULE_HOME}/conf/wrapper.conf file:

    wrapper.java.additional.<n>=-mule.ws.checkWssResponseTimestamp=true
Learn more about passing JVM arguments to your Mule instance here.

Using Basic Authentication and SSL

If the web service you’re connecting to requires basic authentication, you can easily provide your username and password as part of the URL when you reach out to it.

The URL should follow the structure below:

http://myUserName:myPassword@hostService

In the Web Service Consumer’s Global Element, add a reference to an http-request-config element:

  1. Enter the Web Service Consumer’s global configuration element

  2. Open the References tab

  3. Create a new reference by clicking the green plus sign


    
            
         
1
2
3
4
5
&lt;http:request-config host="localhost" port="${port}" name="customConfig"&gt;
        &lt;http:basic-authentication username="user" password="pass" /&gt;
    &lt;/http:request-config&gt;

    &lt;ws:consumer-config wsdlLocation="Test.wsdl" service="TestService" port="TestPort" serviceAddress="http://localhost:${port}/services/Test" connectorConfig="customConfig" name="globalConfig"/&gt;

By default, the WSC runs over a default configuration for the HTTP Request Connector. If you need it to instead run over a configuration of the connector that uses HTTPS (or an HTTP configuration that is different from the default) follow the steps below:

  1. Click the Global Elements tab, below the canvas and create a new Global Element global_elements1

  2. For the Global Element type, select HTTP Request Configuration

http_global_element

  1. Complete the required fields in the General tab (host and port)

  2. Then select the TLS/SSL tab and configure the fields related to the HTTPS authentication

ssl_tls

  1. In your instance of the Web Service Consumer in your flow, click on the green plus sign next to Connector Configuration

adding_https_ref

  1. In the References tab, select your newly created HTTPS Global Element for the Connector Ref field

adding_https_ref2

  1. Add an HTTP Connector global element in your project, configure it with the necessary security attributes


    
            
         
1
2
3
4
5
6
&lt;http:request-config name="HTTP_Request_Configuration" host="example.com" port="8081" protocol="HTTPS" doc:name="HTTP_Request_Configuration"/&gt;       
        &lt;tls:context&gt;
            &lt;tls:trust-store path="your_truststore_path" password="your_truststore_password"/&gt;
            &lt;tls:key-store path="your_keystore_path" password="your_keystore_path" keyPassword="your_keystore_keypass"/&gt;
        &lt;/tls:context&gt;
&lt;/http:request-config&gt;
  1. In your ws:consumer-config element, include a connectorConfig attribute to reference to this HTTP connector configuration element:


    
            
         
1
&lt;ws:consumer-config name="Web_Service_Consumer" wsdlLocation="tshirt.wsdl.xml" service="TshirtService" port="TshirtServicePort" serviceAddress="http://tshirt-service.qa2.cloudhub.io/tshirt-service" connectorConfig="HTTP_Request_Configuration"/&gt;

Referencing the Deprecated HTTP Transport

In order to set alternate HTTP settings, instead of referencing an instance the new HTTP Connector, you can reference an instance of the deprecated HTTP transport and accomplish the same. To add this reference, add a connector-ref attribute to the WSC configuration element. The connectorConfig and connector-ref attributes are mutually exclusive, and both optional.

If none of the two reference attributes are specified, a default instance of the new HTTP connector is used. For backwards compatibility, you can change this behavior and make an instance of the deprecated HTTP Transport the default configuration.  There’s a global configuration property that has been added in Mule runtime 3.6, that allows you to change this default behavior:


          
       
1
2
3
<configuration>
  <http:config useTransportForUris="true"/>
</configuration> 

The deafult value for this attribute is false. When setting this flag to true, Mule falls back to the deprecated HTTP transport to resolve URIs when no transport/connector is specified.

Complete Code Example

Code Example section’s flow diagram in Studio


    
            
         
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mule xmlns:dw="http://www.mulesoft.org/schema/mule/ee/dw" xmlns:file="http://www.mulesoft.org/schema/mule/file" xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:ws="http://www.mulesoft.org/schema/mule/ws" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
    xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.7.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/ws http://www.mulesoft.org/schema/mule/ws/current/mule-ws.xsd
http://www.mulesoft.org/schema/mule/file http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd
http://www.mulesoft.org/schema/mule/ee/dw http://www.mulesoft.org/schema/mule/ee/dw/current/dw.xsd"&gt;
&lt;ws:consumer-config name="Web_Service_Consumer" wsdlLocation="http://tshirt-service.cloudhub.io/?wsdl" service="TshirtServicePortTypeService" port="TshirtServicePortTypePort" serviceAddress="http://tshirt-service.cloudhub.io/" doc:name="Web Service Consumer"/&gt;

  &lt;http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration"/&gt;

    &lt;flow name="orderTshirt" &gt;
        &lt;http:listener config-ref="HTTP_Listener_Configuration" path="orders" doc:name="HTTP"&gt;
            &lt;http:response-builder statusCode="200"/&gt;
        &lt;/http:listener&gt;
        &lt;set-variable variableName="apiKey" value="#['abc12345']" doc:name="Set API Key"/&gt;
        &lt;dw:transform-message doc:name="Transform Message"&gt;
            &lt;dw:input-variable doc:sample="string.dwl" variableName="apiKey"/&gt;
            &lt;dw:set-payload&gt;&lt;![CDATA[%dw 1.0
%output application/xml
%namespace ns0 http://mulesoft.org/tshirt-service
---
{
    ns0#OrderTshirt: {
        size: payload.size,
        email: payload.email,
        name: payload.name,
        address1: payload.address1,
        address2: payload.address2,
        city: payload.city,
        stateOrProvince: payload.state,
        postalCode: payload.postal,
        country: payload.country
    }
}]]&gt;&lt;/dw:set-payload&gt;
    &lt;dw:set-property propertyName="soap.header"&gt;&lt;![CDATA[%dw 1.0
%output application/java
---
flowVars.apiKey]]&gt;&lt;/dw:set-property&gt;
        &lt;/dw:transform-message&gt;
        &lt;ws:consumer config-ref="Web_Service_Consumer" operation="OrderTshirt" doc:name="Order Tshirt"/&gt;
        &lt;dw:transform-message doc:name="Transform Message"&gt;
            &lt;dw:set-payload&gt;&lt;![CDATA[%dw 1.0
%output application/json
---
payload]]&gt;&lt;/dw:set-payload&gt;
        &lt;/dw:transform-message&gt;
    &lt;/flow&gt;
 
    &lt;flow name="listInventory" &gt;
        &lt;http:listener config-ref="HTTP_Listener_Configuration" path="inventory" doc:name="HTTP"&gt;
            &lt;http:response-builder statusCode="200"/&gt;
        &lt;/http:listener&gt;
        &lt;ws:consumer config-ref="Web_Service_Consumer" operation="ListInventory" doc:name="List Inventory"/&gt;
        &lt;dw:transform-message doc:name="Transform Message"&gt;
            &lt;dw:set-payload&gt;&lt;![CDATA[%dw 1.0
%output application/java
---
{
}]]&gt;&lt;/dw:set-payload&gt;
        &lt;/dw:transform-message&gt;
    &lt;/flow&gt;
&lt;/mule&gt;

See Also