Use case: SOAP

Create a SOAP project

Creating a new mocked SOAP project is easy! Click on the "New project" button on the project overview page to start creating a new SOAP project. Choose the project type to "SOAP", give the project both a name and a description and then click on the OK button.

Congratulations! You have just created your first SOAP mock project!

Import WSDL file

Mocked SOAP services are created by importing the WSDL which defines the SOAP services. On the SOAP project page, click on the "Upload WSDL" button to either upload a WSDL from your local storage or provide a direct URL to the WSDL file.

The upload WSDL page also contain the option to generate mocked response for every new mocked service being created. When checked, new mocked responses will be created upon uploading the WSDL file.

A WSDL file can be uploaded multiple times. The services that are already defined will be left untouched. Castle Mock will create new mocked SOAP services if the WSDL contains new service definitions. Services that once existed in the WSDL file but has been removed, will be removed from Castle Mock as well.

Create mocked responses

Multiple mocked responses can be created for each SOAP web service. Each mocked response has its status code and the response message. Header can also be defined and overwritten for mocked responses. The service can be configured that use different response strategy. A response strategy is the strategy of choosing which mocked response should be returned in the event of multiple mocked responses has been defined. There are currently two different response strategies:

  • Random: The random response strategy will choose a mocked response randomly.
  • Sequence: The sequence response strategy will return the mocked responses in a sequence. The sequence is defined in which order the mocked responses were created. The sequence will start from the beginning when it has reached its end.
  • XPath: SOAP projects can be configured to use XPath as a response strategy. The incoming request will match a predefined XPath definition for a mocked response (See XPath section for more information).

A mocked web service has a mode. The mode will determine how the mocked web service will act. There are currently six different modes available:

  • Mocked: The Mocked mode will use the defined mocked responses.
  • Disabled: The Disable mode will disable the service. A service consumer will receive an error message if trying to invoke a disabled web service.
  • Forwarded: The Forwarded mode will forward all incoming requests for a web service to an external endpoint. This mode can be used when only some web service should be mocked, while the rest should go to the original endpoint.
  • Recording: The Recording mode will forward all incoming requests for a web service to an external endpoint and create a mocked response for the responses returned from the external endpoint.
  • Recording once: The Recording once mode will do the same as the Recording mode, but will only do it one time. Once it has been done, the web service will switch to Mocked mode instead.
  • Echo: The Echo mode will return the request as a response.

Mocked responses can use expressions. Expressions are used to define how data in a response can be generated. An expression will be parsed and replaced with generated random data each time a mocked response is being returned. For more information on how expressions works, please go to the expression page.


SOAP projects can be configured to use XPath as a response strategy. The incoming request will match a predefined XPath definition for a mocked response. The mocked response’s XPath that matches the incoming request will be chosen as the response.

A default mocked response can be configured in case the incoming request would not match any of the defined XPaths in the mocked responses.

<soapenv:Envelope xmlns:soapenv="" xmlns:web="">

Forward requests and record responses

A web service can be configured to forward all incoming requests to the original endpoint and record all responses. This will allow you to quickly and easily create mocked responses.


All incoming requests and outgoing responses will be logged. All these can be viewed on the event page or on the event tab for each individual web service. Each logged event will contain information such as date, status code, body and headers.


Castle Mock will store a copy of the uploaded WSDL when mocking SOAP web services. This WSDL will become a resource and can be viewed under the project page. The WSDL file can also be accessed for each individual SOAP port by adding ?wsdl at the end of the URL.