Calling a WCF-WSHttp service from SOAPUI

SOAPUI is a great free tool that helps you to frame up request messages generated based on a service’s metadata and use them to call on HTTP based SOAP services as well amongst other advanced features.

One of the most common questions I have been approached for recently is how to use SOAPUI to call on a WCF service with a WCF-WSHttp binding.  If you create a SOAPUI project based on your service’s WSDL and try running one of the requests without changing any of the advanced options then you will get an error message like the following – “The message with To ” cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher.  Check that the sender and receiver’s EndpointAddresses agree.”  You would not face this problem with a default WCF-BasicHttp binding.

The reason for this is that the WCF-WSHttp binding makes use of WS-Addressing which is an advanced feature that allows for messages to be easily routed through firewalls and other intermediaries.  In order to support WS-Addressing you need to set a few advanced properties in SOAPUI which aren’t enabled by default when you generate your project from a WSDL.

The first thing you need to do is focus on your request message and click on the WS-A (at least that is what it is called in SOAPUI 3.6) tab as highlighted in the below screenshot.

You now need to ensure that you’ve checked the tickbox against Enable/Disable WS-A addressing, set the Must understand dropdown box value to True, and ticked the Add default wsa:To tickbox as highlighted in the below screenshot.

If you call on the service now that should work (assuming you don’t have any security turned on for the service, you might need to apply more advanced settings to enable this).

Do also note that if you choose to use Message based security and you enable the Establish Security Context tickbox (the below screenshot is from a BizTalk WCF-WSHttp send port) then you will always get a failure from SOAPUI like the following – “The message could not be processed. This is most likely because the action xxx is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint’s binding.”  This happens because SOAPUI doesn’t appear to support this setting, you will need to turn it off while you are testing from SOAPUI or use an alternative testing tool.