Simple Object Access Protocol or SOAP is a protocol for exchanging information between a client and a server in a structured format over a variety of application layer protocols, such as HTTP. As this course focuses on consuming the most common types of services over HTTP, we focus on SOAP with the HTTP perspective.

SOAP defines the mandatory HTTP request and response payloads to be formatted with XML and containing specific parts like envelope encapsulating the entire request or response payload with headers and body. In addition to the payload, SOAP utilizes also HTTP headers indicating what SOAP operation is in question with the HTTP request. The SOAP payloads are always mandatory with POST as the HTTP method. Below is an example of a SOAP payload as XML.

In short, SOAP with HTTP defines a set of rules how to format the payload and headers to exchange a formatted response between client and server.

As consuming SOAP services with HTTP requires the request payload and responses to be XML, we must use Web HttpRequest Task. Now that we know which Task to use, we must understand how to create the request payload, where to send the request and what HTTP headers to use. Usually SOAP services provide a Web Services Description Language (WSDL) file which helps the service consumers understand how the SOAP service works. Below is an example of a WSDL file of a service that takes two numbers as input (x,y) and returns their sum (sum).

WSDL files are usually interpreted with software which generate the needed payloads, hence helping the development and SOAP consumption. Frends do not provide a functionality to generate payloads or URLs from WSDL files, therefore we must use some 3rd party software like SoapUI. Once that WSDL above has been imported to SoapUI, we can check how the different parameters would look, like in the picture below.

Then we can start configuring the needed parameters in the Task:

Like with all HTTP requests, we need to set the server address and this we can derive from the SoapUI and set it to Url field with value http://www.examples.com/SumNumbers/. This can of course be determined from the WSDL too.

Query parameters are not that common with SOAP but if the SOAP documentation states those are needed, they can be configured like any query parameter in the Uri field.

Like said, with SOAP over HTTP the method is always POST.

Commonly SOAP requires the SOAP operation or action to be stated in HTTP header. In this case that would be SOAPAction: Sum. Additionally we need to set the Content-Type: application/soap+xml; charset=utf-8. Always remember to refer the SOAP documentation for correct HTTP headers.

We can copy the payload from SoapUI and conveniently SoapUI renders the values for any input with a question mark. In the message field of the HttpRequest Task we can use handlebars to reference variables or hard code if necessary.

Usually authentication with SOAP is handled with Basic Auth which can be configured in the Options parameter tab by setting Authentication to Basic and referencing the Username and Password from Environment Variables. Also, an OAuth flow is possible method of authentication which requires setting authentication information to the HTTP Headers.

Connection timeout should be set according to the SOAP service's or the consumers needs but usually the default value should be just fine.

Throwing exceptions with an error response depends on the solution as there are many types of exception handling possibilities to implement.

Now that we have our parameters configured, the HttpRequest Task would look like in the picture below.

As the SOAP service would return a response as XML, we would need to handle it accordingly by transforming it to JToken or using XPathQuery or XSLT or whatever the integration use case would require.

The exception handling of SOAP services depends on the use case itself and how the SOAP service works. The same rules apply as with consuming REST APIs.

The next article is Introduction to Consuming GraphQL APIs