Migrating WSC

Here we are going to cover a couple of common cases using the Web Service Consumer how they were done in Mule 3 and how are they made now in the new Mule 4 release.

The Web Service Consumer Connector in Mule 4 does not support the JMS transport feature.

Connecting with a web service

Mule 4 introduces the concept of connection parameters, separating them from the other config parameters, that’s why you now are going to see a new <wsc:connection> tag in the configuration. Since all the parameters required for the web service consumer are used to create the connection all of them were moved to the <wsc:connection> group.

A Simple web service configuration

The parameters are the same ones, the only difference is that we added a new parameter mtomEnabled to the configuration that used to live in the operation.

In mule 3.x we defined all the elements in the configuration like this.

<ws:consumer-config name="config" serviceAddress="http://company.com/Service" wsdlLocation="http://company.com/Service?wsdl" service="Service" port="Port"/>

Now all of the parameters are defined in the connection.

<wsc:config name="config">
    <wsc:connection wsdlLocation="http://company.com/Service?wsdl" service="Service" port="Port" soapVersion="SOAP_11" address="http://company.com/Service/endpoint"/>
</wsc:config>

Defining a custom http configuration to send the messages

It was very common in Mule 3 to define a custom <http:requester> configuration that the web service consumer can use to send the messages through the HTTP protocol with a custom configuration (TLS, different HTTP Authentications types, etc), of course you can still do this in Mule 4.

The connector-ref configuration parameter was used before to set the connector configuration we wanted to send the messages (this only worked for HTTP and JMS).

  <!-- this is the http configuration used to send the messages -->
  <http:connector name="http-config"/>

  <ws:consumer-config name="config" wsdlLocation="local.wsdl" service="Service" port="Port" connector-ref="http-config"/>

To do the same in the new WSC you will need to add a <wsc:custom-transport-configuration> parameter the connection and specify the http configuration desired. This will only work with HTTP requester configurations and will fail at runtime if not configured properly.

<wsc:config name="config">
   <wsc:connection wsdlLocation="local.wsdl" service="Service" port="Port">
     <wsc:custom-transport-configuration>
       <wsc:http-transport-configuration requesterConfig="http-config"/>
     </wsc:custom-transport-configuration>
   </wsc:connection>
 </wsc:config>

 <!-- this is the http configuration used to send the messages -->
 <http:request-config name="http-config">

Consuming a Web Service

In Mule 3 the WSC expected that the payload was an already created XML body, so in most of the cases the WSC component was used after a Transform component.

<flow name="Mule3">
  ...
  <ee:transform>
    <set-payload>
      #[
        %dw 1.0
        output application/xml
        ns con http://service.soap.service.mule.org/
        ---
        con#echo: {
           text: "Hello!"
        }
      ]
    </set-payload>
  </ee:transform>
  <ws:consumer operation="echo" />
  ...
</flow>

Now you don’t need that extra component the consume operation enables you to build the body XML directly as an operation parameter using DataWeave, take a look at the example below.

<flow name="Mule4">
  ...
  <wsc:consume config-ref="config" operation="echo">
    <wsc:message>
        <wsc:body>
        #[
          %dw 2.0
          output application/xml
          ns con http://service.soap.service.mule.org/
          ---
          con#echo: {
             text: "Hello!"
          }
        ]
        </wsc:body>
    </wsc:message>
  </wsc:consume>
...
</flow>

Sending Headers

The way the WSC works with attachments in Mule 3 is by collecting all the outboundProperties that starts with the soap. prefix, for example: if we added a variable soap.CrazyHeader when the WSC executes it will get the content of the variable and put the variable content in the SoapHeaders element of the envelope. That’s not a pretty behavior, that’s why in Mule 4, the Headers are just another parameter (and of course you have metadata for those also).

Let’s look a sample XML of Mule 3

<flow name="Mule3">
  ...
  <set-property propertyName="soap.aHeader" value="#[vars.headerContent]"/>
  <ws:consumer operation="withHeaders" mtomEnabled="true"/>
</flow>

And now, in Mule 4

<flow name="Mule4">
  <wsc:consume config-ref="config" operation="echoWithHeaders">
    <wsc:message>
      <!-- here we assume there is not required body parameters -->
      <wsc:headers>
        #[
        %dw 2.0
        output application/xml
        ns con http://service.soap.service.mule.org/
        ---
        "headers": {
            con#aHeader: {
              text: "Hello!"
            },
            con#anotherHeader: "Hello! says another header"
        }]
      </wsc:headers>
    </wsc:message>
  </wsc:consume>
</flow>

The headers can be constructed directly inside the operation with a DataWeave script, and since you have metadata for this, is super easy to do.

Adding Attachments

Adding attachments is much more easier now, in Mule 3 when working with MTOM attachments the set-attachment component was used to create a new outbound attachment and the envelope body should be constructed adding a reference an XOP reference to that added attachment.

the mtomEnabled parameter was moved from the operation to the connection.

<flow name="Mule3">
  ...
  <set-attachment attachmentName="attach" value="Hello!" contentType="text/plain"/>
  <ee:transform>
    <set-payload>
      #[
        %dw 1.0
        output application/xml
        ns con http://service.soap.service.mule.org/
        ns xop http://www.w3.org/2004/08/xop/include
        ---
        con#echo: {
           attachment: {
            xop: "cid:attach"
           }
        }
      ]
    </set-payload>
  </ee:transform>
  <ws:consumer operation="uploadAttachment" mtomEnabled="true"/>
  ...
</flow>

If working with Soap With Attachments instead of MTOM, it was responsibility of the mule developer to build the body with the inner attachment encoded in Base64 (DataWeave provided a function to do this)

<flow name="Mule3">
  ...
  <set-attachment attachmentName="attach" value="Hello!" contentType="text/plain"/>
  <ee:transform>
    <set-payload>
      #[
        %dw 1.0
        output application/xml
        ns con http://service.soap.service.mule.org/
        ns xop http://www.w3.org/2004/08/xop/include
        ---
        con#echo: {
           attachment: {
            xop: "cid:attach"
           }
        }
      ]
    </set-payload>
  </ee:transform>
  <ws:consumer operation="uploadAttachment" mtomEnabled="true"/>
  ...
</flow>

In Mule 4 it doesn’t matter if it’s MTOM or SWA, the dev always works the same way with attachments, he just creates a new attachment and assigns the content to it (the mimetype used is the one that is associated to content).

For example, here we read a JSON file using the file connector and then create a new attachment passing the content returned by the file:read operation in the payload.

<flow name="Mule4">
  ...
  <file:read config-ref="file" path="#[vars.pathToAJsonFile]"/>
  <wsc:consume config-ref="config" operation="uploadAttachment">
    <wsc:message>
      <!-- here we assume there is not required body parameters -->
      <wsc:attachments>
        #[{ attach: payload } ]
      </wsc:attachments>
    </wsc:message>
  </wsc:consume>
  ...
</flow>

To use the Web Service Consumer, simply add it to your application using the Studio palette or add the following dependency in your pom.xml file:

<dependency>
  <groupId>org.mule.connectors</groupId>
  <artifactId>mule-wsc-connector</artifactId>
  <version>1.1.0</version> <!-- or newer -->
  <classifier>mule-plugin</classifier>
</dependency>