How to modify a SOAP request before being sent

Blueriq supports many features of the SOAP standard, but not all of them. If you want to modify a SOAP request before being sent, but after the payload has been generated, this article gives you pointers of how to do it.. Example use cases for this include adding support for WS-Security or WS-Addressing enabled web services or adding custom SOAP headers for custom web service processors.

The operations currently available are:

add new namespaces to the SOAP request;
add/modify existing SOAP headers;
get the existing SOAP body;
replace the entire body contents.

Replacing the body contents is not intended to be used for post-processing individual parts of the body (like replacing attributes and formatting values, this is the responsibility of the mapping).

At the moment, hooks do not exist for processing the SOAP response. These hooks are used for processing the request only.

Step-by-step guide

Create a class that implements com.aquima.interactions.communication.ISoapMessageHandler

import com.aquima.interactions.communication.ISoapMessageContext;
import com.aquima.interactions.communication.ISoapMessageHandler;

public class WSSTimestampSoapHandler implements ISoapMessageHandler {
	@Override
	public void handle(ISoapMessageContext context) {}
}

Three demo ISoapMessageHandler implementations are attached to this page. The code is provided for demonstration purposes only and should not be used in a production environment.

Annotate the class with com.aquima.web.config.annotation.AquimaSoapMessageHandler

Make sure you provide a unique name to the handler:

import com.aquima.interactions.communication.ISoapMessageContext;
import com.aquima.interactions.communication.ISoapMessageHandler;
import com.aquima.web.config.annotation.AquimaSoapMessageHandler;
 
@AquimaSoapMessageHandler(value = "WSSTimestamp")
public class WSSTimestampSoapHandler implements ISoapMessageHandler {
	@Override
	public void handle(ISoapMessageContext context) {}
}

Using the AquimaSoapMessageHandler annotation will instantiate the handler using the default factory that searches the Spring context for these annotations. You can provide your own factory implementation if wanted by implementing com.aquima.interactions.communication.ISoapMessageHandlerFactory and annotating the class with com.aquima.web.config.annotation.AquimaSoapMessageHandlerFactory.

The AquimaSoapMessageHandler annotation makes the class a Spring bean. Make sure the Spring configuration scans the package the handler resides in for component annotations (using context:component-scan for example).

Implement the handle(ISoapMessageContext) method

The following code is adapted from com.aquima.web.communication.WSSTimestampSoapHandler and demonstrates adding the WS-Security Timestamp header:

@AquimaSoapMessageHandler(value = "WSSTimestamp")
public class WSSTimestampSoapHandler implements ISoapMessageHandler {

	final String WSSE = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
	final String WSU = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
	final String SOAPENV = "http://schemas.xmlsoap.org/soap/envelope/";
	final SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");

	@Override
	public void handle(ISoapMessageContext context) {
		Calendar calendar = Calendar.getInstance();
 
        // Add custom namespaces
		context.setNamespace("wsu", WSU);
		context.setNamespace("wsse", WSSE);
 
        // Add a new SOAP header
		IXmlElementContext security = context.addHeader(new QualifiedName(WSSE, "Security"));
		security.setAttribute(new QualifiedName(SOAPENV, "mustUnderstand"), "1");
 
        // Add a child to the Security header
		IXmlElementContext timestamp = security.addElement(new QualifiedName(WSU, "Timestamp"));
		timestamp.setAttribute(new QualifiedName(WSU, "Id"), "TS-" + GUID.generate());
		IXmlElementContext created = timestamp.addElement(new QualifiedName(WSU, "Created"));
		created.setValue(dateFormat.format(calendar.getTime()), false);
		IXmlElementContext expires = timestamp.addElement(new QualifiedName(WSU, "Expires"));
		calendar.add(Calendar.MINUTE, 5);
		expires.setValue(dateFormat.format(calendar.getTime()), false);
	}
}

Specify the SoapServiceCall objects that should use this handler by modifying aquima.properties

blueriq.soap-service-calls.<service_call>.handlers=<comma_separated_list_of_handler_names>

For example, assuming that a SoapServiceCall object named wss_greet exists and 3 handlers have been defined as above, the following configuration entry will execute all of them for every SOAP request:

blueriq.soap-service-calls.wss_greet.handlers=WSSTimestamp,WSSUsernameToken,WSAddressing

The ordering matters. The handlers are called in the order specified in the configuration.

Before Blueriq 12.8

Before Blueriq 12.8, the property was called soap_service_calls.<service_call>.handlers.

Test the result

Capturing the SOAP request or setting the log level to debug will show the request having a new header. It should look something like:

<?xml version="1.0"?>
<soapenv:Envelope xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
	<soapenv:Header>
		<wsse:Security soapenv:mustUnderstand="1">
			<wsu:Timestamp wsu:Id="TS-930e7809-2cde-415b-ad5c-0af0b9127083">
				<wsu:Created>2015-04-02T09:46:58.824Z</wsu:Created>
				<wsu:Expires>2015-04-02T09:51:58.824Z</wsu:Expires>
			</wsu:Timestamp>
		</wsse:Security>
	</soapenv:Header>
	<soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
	   ...
	</soapenv:Body>
</soapenv:Envelope>

.NET registration

In the .NET runtime, the usual registration mechanism is used to register a SOAP message handler:

namespace Example
{
	public class ExamplePlugin : IWebApplicationPlugin
	{
		// ...
 
		public void Register(IRegistrationContext context)
		{
			// register SOAP message handlers for the wss_greet service call, one by one
			context.Register("wss_greet", "WSSTimestamp", new WSSTimestampSoapHandler());
			context.Register("wss_greet", "WSSUsernameToken", new WSSUsernameTokenSoapHandler());
			context.Register("wss_greet", "WSAddressing", new WSAddressingSoapHandler());
		
			// or register a SOAP message handler factory
			context.Register(new ExampleSoapMessageHandlerFactory());
		}
	}
}

The ISoapMessageHandler and ISoapMessageHandlerFactory interfaces are implemented in .NET in the same way as in Java.

For more flexibility, the service call names and SOAP message handler names can be configured in a Web.config configuration section for your plugin.