Mock Responses
A MockResponse is where you send the simulated response from the MockService. It holds an actual response to returned from
a MockOperation. The response is very powerful and can be configured in regards to response content, http headers, attachments and dynamic
processing using groovy (for example to process the input or read data from some external source).
MockResponses are added to a MockOperation from their popup menu or from the Request popup/editor
with the "Add to MockService" action/button.
MockResponse Actions
Right clicking a MockResponse node in the navigator or in the MockOperation editor
shows a popup menu with the following actions:
- Open MockResponse Editor - opens the MockResponse Editor, see below
- Open Request - prompts to open the editor for an existing request for this MockResponses MockOperation with
the correct local endpoint.
- Add to TestCase - prompts to add a corresponding MockResponse Step to a TestCase
- Create TestRequest - prompts for TestCase where to create MockResponse TestStep
- Clone - prompts to clone the MockResponse
- Rename - prompts to rename the MockResponse
- Remove - prompts to remove the MockResponse
- Online Help - displays this page in an external browser
|
MockResponse Details Tab
- Name - the name of the MockResponse
- Description - an arbitrary description of this MockResponse
- Message Size - shows the size of the current response message content (in characters)
- Encoding - the encoding to use for the content of the MockResponse message.
- Outgoing WSS : the project-level Outgoing WSS configuration that should be applied to the response
- Enable MTOM/Inline - enables MTOM/Inline processing for MockResponse messages in the same way as
described for Request Attachments
- Force MTOM - always returns MTOM packaged responses, even if there are no MTOM attachments in response.
- Enable Multiparts - enables multiparts in the same way as described for
Multipart Attachments
- Encode Attachments : Tells soapUI to automatically encode attachments that have a corresponding WSDL part with
the xsd-type set to either base6Binary or hexBinary.
- Strip Whitespaces : Strips outgoing responses of any unnecessary whitespaces and xml comments, required by some servers.
- Remove Empty Content : Removes empty elements/attributes from outgoing responses.
- Entitize Properties : Entitize expanded property values
- Response HTTP-Status : (read only) show http response status
- Response Delay : Waits the specified number of milliseconds before returning the response.
- WS-Addressing : enables/disables ws-addressing.
The MockResponse Editor
Double-clicking a MockResponse in the navigator or MockOperation editor opens the
MockResponse editor as seen below:

This editor is more or less a copy of the standard request editor, but shifts focus to the right-hand response area where the MockResponse is configured. The left hand
request area shows the latest request handled by this MockResponse, including its HTTP Headers
and Attachments.
The Response Area contains the same
XML Source editor,
HTTP Headers tab and
Attachments tab
as in the Request Editor (but now all editable). Additionally, a "Response Script" tab is available
that displays a Groovy script editor for creating scripts that should be executed before
returning the actual response content (see more below).
MockResponse Editor Toolbar

The toolbar at the top of the MockResponse editor contains the following actions (left to right):
- Open Request - Opens a new or existing request that can be issued to this MockOperation
when its MockService is running, the request will have the correct local endpoint set automatically.
- Recreate Response - Prompts to create a default response message from the associated WSDL/Schema
definition
- Create Empty Response - Prompts to create an empty SOAP response message
- Create SOAP Fault - Prompts to creates an empty SOAP Fault, if the operation being mocked
defines any faults, soapUI will prompt for which of these to generate en default detail element;
- Toggle Layout - toggles between the available split/tab layouts as described in
Editor Layouts.
- Online Help - shows this document in an external browser.
Response Scripts
The "Response Script" tab shows a standard Groovy editor for a script that will be executed prior
to returning the configured response message, opening for the possibility to create response specific
scripts that can dynamically create content of the outgoing response.

The script has access to the following objects:
log
- a standard log4j Logger for logging arbitrary information to the groovy log
context
- an instance of
MockRunContext
that can hold dynamically user-defined properties. The context is service scoped, i.e. shared between
all MockOperations/MockResponses for a MockService during its lifetime. Since this object implements the Map
interface
it can be accessed using Groovy's built-in collection support (see example screenshot above)
requestContext
- an instance of
MockRunContext
that can hold dynamically user-defined properties. The context is request scoped, i.e. is only available during this
request and not shared with other MockOperations. Use this to pass values from the dispatch script to the handling
MockResponse. Since this object implements the Map
interface
it can be accessed using Groovy?s built-in collection support.
mockRequest
- an instance of
WsdlMockRequest
which provides access to request-related objects, including the underlying HttpServletRequest/HttpServletResponse objects ?
mockResponse
- an instance of
WsdlMockResponse
which provides access to the current MockResponse object (for example for dynamic manipulation of attachments)
The Run button in the script toolbar will attempt to run the script, setting the context to either the currently available
context (if the MockService is running) or an empty one. The MockRequest will be set to the last handled request if available.
Properties set in the context can then be used using standard property expansion in the response, for example the
following script:
context.randomValue = Math.random()
creates a "randomValue" property which can then be "used" in the outgoing response:
<detail>${randomValue}</detail>
WS-A Properties
The WS-A Inspector displays properties used for adding WS-A headers to a MockResponse
according to WS Addressing specification
Enable WS-A AddressingMust understand indicates whether a header entry is mandatory or optional for the recipient to process.Add default WS-A:Action indicates if by default generated action is to be added to request/mock response.Action - specifies the value of the Action property. If not specified, and 'Add default WS-A:Action is checked' ,
default action from WSDL will be generated and added. Although Action property is mandatory by WS-A core specification
by checking previous check box and leaving this empty it is possible for action property to be left unspecified for testing purposes. Add default WS-A:To indicates if default To is to be added to request/mock response.To - OPTIONAL element specifies the value of the To propertyRelatesTo- OPTIONAL element specifies the value of the RelatesTo property. If not specified, and WS-A Settings (see Preferences)
'Use default RelatesTo' is checked , default value of 'http://www.w3.org/2005/08/addressing/unspecified' will be used.RelationshipType- OPTIONAL element specifies the value of the RelationshipType property. If not specified, and WS-A Settings (see Preferences)
'Use default RelationshipType' is checked , default value of 'http://www.w3.org/2005/08/addressing/reply' will be used.From - OPTIONAL element specifies the value of the From propertyFaultTo - OPTIONAL element specifies the value of the FaultTo propertyReplyTo - OPTIONAL element specifies the value of the ReplyTo propertyGenerate MessageID - indicates if messageId should be randomly generatedMessageID - OPTIONAL element specifies the value of the MessageID property. If not specified, and previous check box is
checked , random MessageID will be generated for RequestResponse operation.
Next:
SOAP Monitor