Reactions AI-generated

A Reaction is a configured reply for a request: a pre-set payload (often scripted), HTTP status, delay, and any other properties the calling application expects. Reactions in a service are tried top to bottom; the first one whose Match Options all pass wins, its payload/headers/status/delay get computed, and evaluation stops. If nothing matches, MockMotor returns HTTP 404 (unless a broadly-matching Forward reaction is in the list - see Forwarding & Recording).

Typical practice is one reaction per operation (SOAP or REST), though a complex scenario may need several reactions per operation (one per interesting case) or one reaction spanning several operations. The minimum to create one is a Match Option and a Response Payload; everything else is optional. Reactions can be reordered by drag-and-drop, created manually or from a captured request/response pair, cloned, disabled (a safer alternative to deleting - a disabled reaction is never matched), or deleted outright.

The editor is laid out in the same order the sections are covered below: General Info, Target & Match Options, GraphQL (optional), Account(s) Selection, Forward to Live Service, Response Payload, Response Properties & HTTP Headers, Response Attachments, and an Advanced group (Update/Delete Mock Account(s), Postponed & Chunked Delay) - numbered circles in the real UI. For worked examples putting several of these sections together - JSON and XML side by side, scripted matching, account selection, account updates - see Reaction Examples.

General Info

Name and Description are for your own navigation only - MockMotor never reads them for matching. Status is Enabled or Disabled. The reaction's scripting language - JavaScript or XQuery - applies to every scriptable field in it; as a rule of thumb, XQuery suits XML-based responses and JavaScript suits JSON-based ones (see Script Library & JWT for shared functions in either language).

Matching a request

Every non-empty match field must pass for a reaction to be selected; fields left empty are skipped entirely:

• HTTP Method - a specific method (GET, POST, ... including WebSocket pseudo-methods WEBSOCKET_TEXT/BINARY/OPEN and, for LDAP-mode environments, BIND/SEARCH), or (Any) to match every verb.
• Relative URI - the path left after the service's own Base URL is stripped. Supports {param} placeholders bound into variables of the same name (also collected under the rest structure - see Variables), and a catch-all form {name:.*} that captures everything remaining.
• SOAP Action - for SOAP requests: the SOAPAction header (SOAP 1.1) or the action parameter inside Content-Type (SOAP 1.2). Quotes around the value aren't compared, so "GetInfo" and GetInfo are equivalent.
• First Element - when SOAP Action is empty, matches on the payload's first element under <soap-env:Body> (or the outermost element for plain XML with no SOAP envelope), namespace ignored.
• Script - an arbitrary JS, XQuery, or JSONPath expression; truthy/non-empty means match. JSONPath (e.g. $..ApplicationID=='Online') only ever looks at the request payload; JS/XQuery see every namespace in Variables. Combine conditions with &&/|| (JS) or and/or (XQuery).

GraphQL

If the request carries a GraphQL query/mutation, Path in Request tells MockMotor where to find it: input if the whole payload is GraphQL text, a JSON path like input.query if it's wrapped in JSON, or http.parameters.q if it arrives as a query-string parameter.

Account(s) Selection

An equality-driven script (e.g. account.id==input.accountId) picks which mock account(s) this reaction operates on - available afterward as account/$account and accounts/$accounts to every other section (see Mock Accounts). Multiple conditions can be combined with AND or OR. Max Accounts to Bind caps how many selected accounts get bound (choices from 1 up to Unlimited - the field warns unlimited can have a performance impact on a large account set); leave it at the default of 1 unless the reaction genuinely needs to act on a group.

If Account(s) Not Found controls what happens when the selection script matches nothing:

• Fail Immediately (default) - the reaction errors out with HTTP 500 and a message describing which selector found nothing, so a missing test-data account fails loudly instead of silently returning a broken payload.
• Ignore & Continue - runs anyway with empty accounts/null account, useful for scripting an explicit "not found" response.
• Create - seeds a brand-new mock account (nulls except whatever equality clauses the selector could extract) and binds it, so a later Update Accounts step can persist it.

These settings have no effect when no selection conditions are defined at all - there's nothing to fail or ignore.

Forward to Live Service

Instead of a static payload, send the request through to a real backend - as-is or modified - and optionally cache the real exchange as a new reaction. Typical uses: mock only a few operations while the rest fall through to the real backend, add a reaction for a planned-but-not-yet-implemented endpoint, or preserve real responses before a shared test service goes away. MockMotor passes the payload, relative URL, query string and HTTP headers to the backend as-is by default; if the backend needs authentication, call the mock with the same credentials (e.g. the same Authorization header) and MockMotor forwards them along. Two-way SSL client-certificate authentication to the backend isn't supported. See Forwarding & Recording for the full field reference and how this doubles as traffic recording.

Response Payload

Supported formats: XML, JSON, XQuery, JavaScript, or any plain text. For XML/JSON, a static payload can simply be pasted into the field or uploaded from a file. Plain, non-JSON text must be written as a quoted JavaScript string (since the field is still evaluated as a script). For scripted output: XQuery reactions build the XML directly; JavaScript reactions either assign values into a JSON structure directly or assign the whole result to the output variable (required for non-JSON text output).

Response Properties & Headers

HTTP Status defaults to 200; set it to whatever the scenario needs (500 for a SOAP Fault, 401 for a missing-auth case, etc.) - static or scripted. Content-Type sets the response's Content-Type header; MockMotor appends charset=UTF-8 automatically unless you specify a different charset yourself (e.g. text/plain; charset=windows-1251).

Response HTTP Headers - add a header with the button, remove one with . A header's value can be a fixed literal or a script (JS/XQuery, with the same variables as the payload plus output/response). A script that returns null (JS) or an empty sequence () (XQuery) makes MockMotor drop that header entirely - handy for conditionally including one, e.g. input.debugInfo? "1,2,DB100":null. To emit a literal value that happens to look like a quoted string, wrap it in single quotes: a fixed value of '"N/A"' (or a script returning that text) produces a header whose actual value includes the double quotes. CORS headers are generated automatically (see CORS & Auth Basics), so you don't normally need to add those by hand - though this section is exactly where you'd override the automatic ones if needed.

Delay simulates real-world timing for load testing. A static value of 0 means "as fast as possible"; any value above 0 gets randomized within ±10% of the configured number. A scripted delay recalculates per request - e.g. 250 + accounts.length * 500 for "250ms base plus 500ms per matched account."

Attachments

Attach files to a response - binary downloads, or SOAP attachments in SWA, MTOM/XOP or the legacy SWAREF formats. See Attachments & Binary Responses for the full field syntax.

Advanced

Update/Delete Mock Account(s) writes new values back into the accounts selected earlier, or deletes them - the basis for stateful scenarios (e.g. persisting an account number generated mid-flow, expiring a session, moving an account to a new department). Updating several accounts with the same script applies the same target value to each; referencing account/$account (the account currently being updated) in the value expression instead makes it recompute per account, so each one gets its own value pulled from its own properties or from a matching part of the request.

Postponed Background Request emulates an asynchronous callback: reply immediately, then fire a separate request later. Chunked Delay drips the response out in pieces with pauses between them, useful for testing a client's read-timeout handling.

Change History, Debug, and Cloning

A reaction's History tab lists every saved change, newest first, with a side-by-side diff (yellow = modified, green = added, red = removed) against the previous version; Revert to Version on the Left restores it - and the revert itself becomes a new history entry, so it can be undone too. This is also the safety net if you accidentally edit and save an original instead of cloning it first.

The Debug button opens a per-reaction test harness: fabricate a request, execute it, and get a step-by-step trace of every reaction considered (method/SOAPAction/script matching, account selection outcome, generated payload, account-update values) with per-step timing, so you can see exactly why a given reaction is or isn't matching without needing a real client. See Debug & Troubleshooting.

Clone duplicates the current reaction (appending "(Clone)" to its name) right after the original in the list - usually faster than building a near-identical reaction from scratch.