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>