Response Match Options
The Match Options section determines what requests will match this response. In other words, it decides which requests this response will be executed for.
There are three main match conditions:
1 HTTP Method
2 Operation (URI, SOAP Action, etc.)
If any of the conditions are undefined, it is not used in the match.
All defined conditions must be true for the response to match the request.
To match, the incoming request must use the specified HTTP Method.
Possible HTTP Methods are:
The pseudo-method “Any” matches any HTTP method and effectively disables this check.
The operation is only strictly defined for SOAP requests. For the rest, the name operation is used loosely.
The operation can be one of the few types:
SOAPAction is a value that is sent with SOAP requests.
MockMotor supports both the SOAPAction HTTP header (SOAP 1.1) and action component of the Content-Type HTTP header (SOAP 1.2).
First Element of XML Payload
For some SOAP services, the action field is not defined or defined as an empty string for all operations. We then cannot use the SOAPAction condition to select a response that fits the operation. However, for such services, the first element under SOAP Body usually has a unique name and we can use this instead.
For example, for this request
<soapenv:Envelope ...> <soapenv:Header/> <soapenv:Body> <bt:SubmitActivity> ...
We can configure the response to match the first element of the payload when it is at SubmitActivity:
Note that SOAP Envelope elements (body, header) are not considered a part of the payload.
The same match will also work for plain XML requests, where the SOAP Envelope doesn’t exist:
<bt:SubmitActivity> ... </bt:SubmitActivity>
Relative URI match is mostly aimed at REST services, though sometimes it can be useful for SOAP or XML services too.
The relative URI is the part of the request URL past the service URL.
For instance, when a request with URL
http://127.0.0.1:7080/SelfTest/REST/products comes to a service with URL
http://127.0.0.1:7080/SelfTest/REST, the relative URL is
products. We can then configure the match like this:
Parameters in the URL
For many REST services the URL contains parameters, such as account ID. MockMotor allows you to specify such parameters using the common
The matched parameters are then placed into the
rest variable and are available to script everywhere in the response. See REST Variable for details.
This option effectively disables the match by operation.
Normally, it is only needed in default responses that should match no matter what request has been received. Such default responses use HTTP Method = <Any>, Operation = Not Used and an empty script.
A match by a script allows fine-grained access to any property of the incoming request.
The most common types of match by script include (but are not limited to):
Match by Particular Request Value
Sometimes, we only need to match requests with a particular value in the payload. For instance, we may have different responses for two different consuming applications that are identified by their codes in the request.
Then, we can limit our response to a specific consumer by adding a match by script:
We can use an XQuery expression that resolves into either boolean or into non-empty sequence.
For example, the following script checks that the request comes from application named “Online”:
$input variable contains the request. See Payload Variable for details.
input.GetOffers.Header.ApplicationID=='Online'. The expression must resolve into a boolean true to match.
Match by HTTP Header
We can match the request based on the request HTTP header (or lack thereof).
For instance, we can simulate HTTP Authentication exchange by rejecting any request that comes in without Authorization HTTP header and send back a HTTP status 401 (Unauthorized):
The headers are provided in the
Match by Query String
A value passed in the URL query string can also be used for a match. The input parameters are parsed into the
For example, imagine a reporting service where the response format can differ based on the CALL_TYPE parameter:
Match by URL Component
For REST services, a URL component can be a value that needs to be matched against.
Imagine a REST service where the second part of the URL is a form id:
Then, we can match the response by the value that is passed in the URL, e.g. here, we only match if that value is 5099:
Match by Account Value
Sometimes users want to mark accounts as belonging to a specific flow - some responses should only match accounts in one flow.
To achieve this we can match the request by the account values that it would use:
Note that this case is special.
First MockMotor matches the request by the HTTP Method and first element of the payload (
GetAccountDetails), i.e. performs the checks in its normal order.
Then, however, it sees that the matching script contains a reference to the account variable
$account. To have the value of the
$account MockMotor first
performs the account selection, finding the account that has the
ban property matching the value from the request using the XPath
Only when this account is found and loaded, MockMotor executes the matching script, checking that the account’s property
type has the value
If the selected account has a different
type, the response is considered to be not matching and the next response in the list will be tried.