---
schema_version: "1"
id: 9e854230b8ae4fea50250f8c470db0f528cdeeeed8ab91273df9a311fa8a6287
title: Migrating WSC
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.4/migration-module-wsc.md
canonical_url: https://docs.mulesoft.com/mule-runtime/4.4/migration-module-wsc
source_site: docs.mulesoft.com
content_type: documentation
content_hash: d3fd679e8264abd4fb5bacb65431e1e1b33d740c06b88a1cc8a42f054bbc32ae
description: MuleSoft Documentation Site
release: "4.4"
latest: false
---
---
product: Mule Runtime
version: 4.4
---

# Migrating WSC

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

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.

> [!NOTE] 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.

```xml
<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.

```xml
<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).

```xml
  <!-- 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.

```xml
<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.

```xml
<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.

```xml
<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

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

And now, in Mule 4

```xml
<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.

> [!NOTE] the mtomEnabled parameter was moved from the operation to the connection.

```xml
<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)

```xml
<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.

```xml
<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:

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