How to work with SOAP in Frends

Sending and receiving SOAP messages with Frends.

This guide explains how to send SOAP messages and publish web services (WSDL) using Frends. While Frends doesn't have direct native support for SOAP, you can work with SOAP effectively since it fundamentally consists of XML messages sent over HTTP.

Prerequisites

Before you begin, you'll need editor access to your Frends Tenant to access the Process Editor View, as well as an Agent Group and Environment setup to run Processes.

Making SOAP Calls

To make a SOAP call in Frends, you can use the standard HTTP Request Task. The approach is straightforward: you simply need to include a proper SOAP envelope in the request body along with the correct HTTP headers. For SOAP 1.2, configure the HTTP Request Task with Content-Type: application/soap+xml and charset=utf-8 in the headers section. The SOAP envelope in the request body should contain your message with the appropriate namespaces and structure required by the target web service.

It's important to note that the HTTP Request Task does not support more advanced SOAP message types such as WS-Security out of the box. However, if you need to sign XML documents for security purposes, you can use the SignXml Task to add this functionality.

Publishing Web Services (WSDL)

To mimic web services in Frends, you need to create Processes with HTTP Triggers for each SOAP endpoint you want to expose. While one Process could contain multiple HTTP Triggers, it makes more sense to split the web service operations into their own Processes.

Frends doesn't currently include specific Tasks for SOAP specifically, but since SOAP messages are XML-based, handling them in a Frends Process is straightforward and doesn't require any special processing.

Your HTTP endpoints would typically follow a structure where you have a main endpoint for serving WSDL and separate endpoints for each operation, such as example.com/ws/ for the WSDL itself, and example.com/ws/operation1, example.com/ws/operation2, and so on for each operation.

example.com/ws/             (WSDL is served here)
example.com/ws/operation1
example.com/ws/operation2 
example.com/ws/operation3
example.com/ws/operation4
example.com/ws/operation5

When it comes to serving WSDL documents, you have a few different approaches to consider. If you want to publish WSDL from a dedicated URL like example.com/ws/, you need to create a Process with HTTP Trigger that serves the WSDL document when that endpoint is accessed.

Alternatively, if you prefer to serve WSDL when a caller includes a URL parameter such as example.com/ws/operation1?wsdl=true, you'll need to add logic to each Process to detect the wsdl parameter and return the WSDL document when it's detected. For this approach, it's generally best to add this kind of recurring logic in a Frends Subprocess for reusability, which ensures consistency across all your endpoints and reduces code duplication.

Similarly, if WSDL needs to be served from a root endpoint like example.com/ws?wsdl=true, you must create a dedicated HTTP Trigger, preferably in its own Process, for this endpoint and add parameter detection logic to identify the wsdl query parameter and return the appropriate WSDL document when it's present.