Last Updated on 02/05/2021 by Patryk Bandurski
When it is time to consume the SOAP Web Service mule has a couple of ways to handle this task. There was a time when I would generate stub classes based on the WSDL file, but I wanted to create flows without generating a single line of code. So I found out that we could use a CXF proxy client to handle my wish.
I am going to use following tools:
- Postman to make HTTP calls
- Soap UI to mock soap service
- Anypoint Studio 6.x
We are going to create, in mule, simple service which consumes SOAP Web Service. The client can call our flow by sending a GET request. Then we will route to the service, consume its payload. Based on the response’s status, we return two different kinds of responses.
Time to mock
Soap UI is a great tool that allows us to quickly mock SOAP services based on the WSDL file.
- Open Soap UI
- Create a project based on the local or remote WSDL file
- Right-click at service endpoint and from the context menu choose to Generate SOAP Mock Service
- In Generate MockService windows, choose which operations you would like to mock. I will select only one operation GetObjectList
- In new windows double click on the operation you will mock and then in the next window click Response 1
- It is time to edit your mock response. It will always be returned in the way you define it here.
- The last thing is to start the service by clicking the green play button. Finally, we are ready to write our service.
We start with the HTTP Listener configured to listen at port 8081. When a user sends a GET request for resource /users, the flow is invoked. Then we are setting 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 the SOAP body.
<v1:GetObjectList xmlns:v1="http://www.omninet.de/OtWebSvc/v1"> <v1:Get folderPath="Users"></v1:Get> </v1:GetObjectList>
The next message processor proxy-wsSub_Flow invokes subflow. This subflow is divided into two steps:
- configuring Proxy client – it creates outbound endpoint to send raw XML content,
- sending an HTTP request to the web service endpoint.
To set up the proxy client, you have to set 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 envelop.
To send prepared XML payload we should configure HTTP request connector – like setting host, port, path and method (always POST). When invoking 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)
In order to set up custom headers in the HTTP request connector go to Parameters section and click the button Add Parameter. It will allow adding headers one by one or you can use builder which will hold all custom headers in one place.
Here are examples for mentioned headers:
- SoapAction – http://www.omninet.de/OtWebSvc/v1/ModifyObject
- Content-Type – application/soap+xml;charset=UTF-8
- Authorization –
To hash user name and password we are using Base64’s method encodeBytes. Header after evaluation: Basic c3VlcjpwYXNzd29yZA==
The part with Authorization seems to be a bit complicated so let’s remove it from properties. Http Request Connector’s configuration has tab allowing to configure authentication type. In order to do it edit connector configuration.
As you can see, any transformation is not needed. We provide simply user name and password. One thing to bear in mind is selecting a Preemptive checkbox. By doing this you ensure that the credentials are sent with the first request.
Source code is available at github.