Response Caching AI-generated

Caching lets a reaction learn from its own traffic. Every time the reaction handles a request, MockMotor can save the exchange as a new, temporary cached reaction. The next request that carries the same key values is answered by that cached reaction directly - the original reaction (and, for a forwarding one, the real backend) is not executed again.

Caching is a section of any reaction: static, scripted or forwarding. It is switched on with Cache Transactions: Cache in the reaction's Caching section.

When caching is useful

• Recording a real service. Point a forwarding reaction at the backend, enable caching, send representative traffic - and you get a set of mock reactions that reproduce what the backend said, for the inputs it saw. See Forwarding & Recording.
• Shielding a slow, flaky or rate-limited backend. Only the first request per key combination goes through; the repeats are answered locally, at the recorded (optionally capped) delay.
• Repeatable test data. Once a response is cached, it stays the same however the backend changes later, until the cache is cleared.
• Working offline or before the backend exists. Record once, then run without the real service.
• Scripted responses that are expensive to compute. A reaction whose payload script does heavy work can have its results cached per input.

How it works

1. A request reaches the reaction and it is executed normally (payload computed, or request forwarded).
2. The Cache Keys expressions are evaluated against the request (and, for the account flavour, the response). Together their values identify the transaction, e.g. ban=100123.
3. A cached reaction is created for that combination of values. It matches a later request when all of these agree: the HTTP method, the relative URI, the SOAPAction / top XML element (when the original had them), and the key values.
4. The cached reaction answers with the same HTTP status and content type, the payload (see below), and the delay of the original. Max Delay caps the delay if the real backend was slower.

The cached reaction is named after the method, URI and key values (for example POST /accounts ban="100123"), is marked as cached in the reactions list, and is placed so that it takes precedence over the reaction it was recorded from. Changes made to a cached reaction are lost when the cache is cleared. Cached reactions can be deleted in bulk from the service and environment pages.

A cached reaction is never created if the method alone would be its only matching criterion - it would answer every request.

Cache Keys

Enter one full expression per line, not just a field name:

• Request expressions are combined into a single matching script, so keep them in one language: all XQuery or all JavaScript/JSONPath. A key in the other language is skipped.
• A key that cannot be computed, or that is plain text rather than a script, is skipped (the debug output says so).
• A line that ends with an operator (+, &&, ||, ?, ,, =, an opening bracket) continues on the next line, so a multi-line script is still one key.
• Pick values that actually distinguish one transaction from another - account numbers, ids, currencies. Avoid timestamps and random values: every request would produce a new cached reaction that nothing ever matches again.
• With no keys at all, the cached reaction answers every request with the same method and URI.

Two flavours: Raw Reactions or Mock Accounts

The Save Keys into Accounts setting decides where the key values live.

Use Raw Reactions (default)

The key values are hardcoded in each cached reaction's matching script. A request with input.account.id = 18474332674 produces a reaction that matches input.account.id=='18474332674'; another account number produces another reaction. Each cached reaction is self-contained, easy to read and edit, and has nothing to do with accounts.

Use it for recording and replaying a modest number of distinct requests, and whenever you want to see and tweak each case.

Use Mock Accounts

The key values (from both the request and the response) are saved as a mock account, and the cached reaction selects that account instead of containing the values. Properties of the payload whose names match the keys are replaced with account variables. This keeps the data in the account store - where it can be browsed, searched, edited and used by other reactions - rather than scattered through many reactions. It also lets keys that come from the response (for example an id the backend generated) be part of the account. See Mock Accounts.

Use it when the recorded data should be shared or manipulated as accounts, or when response values need to travel with the request values.

Cache Script or Cache Result?

When the reaction has its own payload (a script or a template), the cached reaction can take it in two ways. This is the Cached Payload setting:

Cache Result is right when the answer depends only on the request: a forwarded response, or a script that merely transforms the input. The cached reaction is a faithful snapshot, independent of accounts and of the script library.

Cache Script is right when the payload reads account values that can change between calls - a balance, a status, a counter updated by other reactions. A frozen result would go stale; the copied script, together with the copied account selection, keeps producing current data.

The default is chosen for you from the payload, and is recalculated every time you switch the toggle to Cache:

• XML or XQuery payload using $account or $accounts - Cache Script.
• JavaScript payload using account or accounts - Cache Script.
• JSON, plain text, a forwarded response, or a script that does not use accounts - Cache Result.

You can override it either way. A reaction with an empty payload (a plain forward) always caches the response it received.

Accounts that the original reaction changes

If the original reaction updates account properties or deletes accounts, the cached reaction does so too, in both modes - the side effects of the transaction are part of what is replayed. For that reason the account selection is copied along with them.

Settings summary

Practical advice

• Start with keys only, Raw Reactions and Cache Result; send a few requests and look at the cached reactions that appear. Most needs end there.
• Run the reaction with the debug option (the run button next to Cache Keys) to see the values each key produces and which ones were skipped.
• If the cached responses are wrong after the backend or the original reaction changes, clear the cached reactions and let them be recorded again.
• Authentication to a real backend is forwarded as sent: call the mock with the credentials you would use against the real service.