Creating a Simple Object Access Protocol (SOAP) service using MuleSoft

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

This article is aimed at Mule 4 users, since the procedure used to be different for Mule 3.

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 of this process is available here. However, if you’re the type who learns better with visual instructions and needs a bit more context, keep reading.

APIKit in Mule 4

More popularly, MuleSoft offers an APIKit module to expose a REST service by reading a RAML (API description for REST services). Similarly, MuleSoft 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, we have chosen a Google AdWords API (available here). Alternatively, you can create your own WSDL.

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’s possible to put these configurations in a properties file and reference these values to adhere to Mule 4 standards.

We’re 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 sent 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’ll want to test if everything is working as it should. We’ll see how that’s 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’s 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’s try editing another operation. This time, let’s work on “mutate”.

This is the existing script.

And here’s 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’re receiving from the request. So, after changing the namespace and the response body to reflect that, we have the new script.

Let’s 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’s also possible to capture the headers from the request. For details on that, check the MuleSoft Documentation.

Wrapping up

Exposing a SOAP API in Mule 4 is 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’ve seen how to do that, as well as how to test the exposed API.

If you’ve made it this far, congratulations! You’ve created your first SOAP API!

— By Suraj Kumar and Oishi Bhattacharyya