Authors: Suraj Kumar and Oishi Bhattacharyya

Much the same way as one would expose a REST service using Mulesoft, they can do the same for SOAP services. The procedures are very similar but not without nuances. In this article, we’ll get into the nitty-gritty of the process, and also test the service we will be exposing.

This article is aimed towards Mule 4 users, since the procedure used to be different for Mule 3. If you are a Mule 3 user, you should take a look at this post

A couple of prerequisites to keep in mind before we start: please ensure you have Mule 4 runtime and Anypoint Studio 7+ installed in your system. 

The Mulesoft Documentation on this process is available here. However, if you’re the type who learns better with visual instructions, and needs justa bit more context on things, keep reading.

APIKit in Mule 4

More popularly, Mulesoft offers an APIKit moduleto expose a REST service by reading a RAML (API description for REST services). Similarly, Mulesoft also offers an “APIKit for SOAP” module to expose a SOAP service, by reading a WSDL (Web Service Definition Language)(API description for SOAP services). 

We can either add these modules to a project manually from the Mule Palette, or we can configure it while creating our project. We’ll be using the latter method in the sections below.

Exposing the Service
Creating the Mule Application

First things first, we need to get our hands on a WSDL. There are several SOAP services available for free on the internet. For this article, I have chosen a Google AdWords API (available here). Alternatively, you can create your own WSDL as well. 

Next, we need to open up Anypoint Studio and create a New Mule Project.

In the “Specify API Definition” section paste the URL of the WSDL of your choice. Alternatively, you can link the local WSDL that you’ve created.

The Service and Port will automatically be picked up. 

You should now be seeing something like this. The “APIKit for SOAP” module, which you can now find in your Mule Palette, automatically generates the flows for your application based on the operations defined in the WSDL. 

By default, the HTTP Listener is configured to listen locally to port 8081, on the path /{Service}/{Port}.It is possible to put these configurations in a properties file and reference these values to adhere to Mule 4 standards.

We are now ready to run our project. 

Customizing Responses

Although our Mule Application is at a deployable stage, we should take care of our responses first.

By default, each operation has a pre-defined XML output in the Transform Message section. This is called a SOAP fault. For more details, take a look at Mulesoft’s documentation on this. 

If we were to send a request to this application the way it is right now, we’d get this response.

We need to edit the Dataweave script to prevent this SOAP fault and adjust the response to our liking. Make the following changes:

  • Change the namespace to your chosen web service. This can usually be found in the documentation of the web service. 
  • Change the body of the response, referring to the elements available in the WSDL.

Now save your project and let Anypoint Studio re-run your application.

Testing the Service

After your Mule application is re-deployed in Anypoint Studio, you will want to test if everything is working as it should. We’ll see how that is done in this section. 

Download SoapUI here

Create a “New SOAP Project”.

Paste the link to your service in the “Initial WSDL” section in this format
http://localhost:{port}/{Service}/{Port}?wsdl

You should be able to see the new project on the left with all the available operations expanded in the tree view.

Let us check the response from our “get” operation. 

Recall how we had changed the response body in Dataweave? Our response is successfully reflecting the change. Let us try editing another operation. This time, let’s work on “mutate”. 

This is the existing script.

And here is the corresponding response. Note that we have edited the request in the SoapUI project to send “add” as the operator. 

Now that just won’t do, will it? We need to capture what operation we are receiving from the request. So, after changing the namespace and the response body to reflect that, we have the new script. 

Let us send the request from SoapUI and check if our script works. 

Yes it does!. 

We can do this for all the operations as well as for any element in the request. It is also possible to capture the headers from the request. For details on that check the MuleSoft Documentation on it.

Wrapping Up

Exposing a SOAP API in Mule 4 is very similar to exposing a REST API in Mule 4; we use the respective APIKit modules offered by Mulesoft, and present a WSDL as the API description instead of a RAML. In this article, we have seen how to do exactly that, as well as how to test the exposed API. 

If you have made it this far, congratulations! You have created your first SOAP API! For more such articles, keep an eye out on this blog. 

Leave a Comment