Mule How-To: CXF Proxy Client

When it is time to consume SOAP web services, Mule has a couple of ways to handle this task. There was a time when I would generate stub classes based on a WSDL file, but I wanted to create flows without generating a single line of code, so I found out that we could use the cxf proxy client to handle my wish.

The Mule versions used are Mule ESB EE and Mule ESB CE.

I am going to use following tools:

• Postman to make HTTP calls.
• Soap UI to mock a SOAP service.
• Anypoint Studio.

Background

We are going to create a simple service in Mule which consumes SOAP web services. Clients can call our flow by sending a GET request; then we will route to the service, consume its payload, and, based on the response's status, we will return two different kinds of response.

Time to Mock

Soap UI is a great tool which allows us to quickly mock SOAP services based on a WSDL file.

1. Open the SOAP UI.
2. Create a project based on a local or remote WSDL file.
3. Right click the service endpoint and, in the context menu, choose "Generate SOAP Mock Service."
4. In the "Generate Mock Service" window, choose which operations you would like to mock. I will select only one operation: GetObjectList.
5. In the new window, double-click on the operation you will mock and then, in the next window, click Response 1.
6. It is time to edit your mock response. It will be always returned in the way you define it here.
7. The last thing is to start the service by clicking the green play button. We are ready to write our service.

Code Sample

We start out with the HTTP Listener configured to listen to port 8081. When a user sends a GET request for the resource /users , a flow will be invoked. Then we set the payload statically- here, we could either set a SOAP envelope or SOAP body; it is up to you which one is better for the specific use case. I have decided to set only a SOAP body.

<v1:GetObjectList xmlns:v1="http://www.omninet.de/OtWebSvc/v1">
  <v1:Get folderPath="Users">
  </v1:Get>
</v1:GetObjectList>

Next, the message processor proxy-wsSub_Flow invokes a subflow. This subflow is divided into two steps:

1. Configuring the proxy client: it creates an outbound endpoint to send raw XML content.
2. Sending an HTTP request to the web service endpoint.

To setup the proxy client, you have to set the Operation to Proxy client. In the Proxy Client section, you should specify what part of the SOAP message you are going to send. The body is the default option- as I mentioned earlier, it could be set to envelope.To send the prepared XML payload, we should configure the HTTP request connector - like setting host, port, path, and method (always POST). When invoking a web service, we are required to provide headers like:

• SoapAction- which operation we would like to invoke.

• Content Type- what is the type of content.

• Authorization- username and password in case of basic authorization (optional).

To set up custom headers in the HTTP request connector, go to the Parameters section and click the button to Add Parameter. It will allow you to add headers one by one, or you can use the builder which will hold all custom headers in one place. Here are some examples for the mentioned headers:

• SoapAction- http://www.omninet.de/OtWebSvc/v1/ModifyObject

• Content-Type- application/soap+xml;charset=UTF-8

• Authorization- Basic #[org.mule.util.Base64.encodeBytes("user:password".getBytes())]

To hash the username and password, we are using Base64's method encodeBytes. The header after evaluation: Basic c3VlcjpwYXNzd29yZA==

Code View

The code is available on GitHub.