Migrating WSC | MuleSoft Documentation
# 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>
```