Mock Service Transactions support Processing Actions so a Mock Service can simulate a long-running task that sends several requests.

For example, instead of polling the status of a job submitted to your web service, you want it to report its progress back to a client, once per second, so the client can display a progress bar to the user. The web service sends asynchronous requests to a callback URL of your choice.
To simulate the same behavior in a BlazeMeter Mock Service, you configure Processing Actions.

Processing Actions can reference values such as ${jsonPath request.body '$.job_id'}. For more information, see the Supported Helper Functions section of the "Adding Parameter Options and Dynamic Responses to Transactions" article.

Processing Actions are optional. If defined, they are triggered after the request is matched, and before the response is sent. The webhook trigger starts a timer.

Currently, the only supported Processing Actions are webhooks.

Webhooks

When do I use Think Time and when a webhook?

The difference is that Think Time sends only the Mock Service's response with a delay. Using a webhook, the Mock Service on its own can schedule sending multiple whole requests asynchronously.

Limitations

• A single transaction can have up to 10 different webhook definitions associated with it.
• A running Mock Service can keep up to 1000 webhook calls scheduled at the same time. For example, you can schedule 1000 webhooks, send all of them, and then schedule an additional 1000. Additional scheduled webhooks going over 1000 will however be discarded.

Example Webhook Scenario

In this sample scenario, an API call submits a job, and the client needs to be informed asynchronously whether the job has been queued, when it has finished or failed, and so on. You want to test whether your system tracks the job status correctly -- therefore you want your Mock Service to reflect that same behavior and simulate posting asynchronous reactions at certain intervals.

As usual, you start with creating a Transaction that matches the long-running job submission, and that returns an appropriate response, and you assign it to your Mock Service.

In the Matcher, you include your custom callback_url query parameter that contains the URL where the client expects to receive updates about this long-running job. You can refer back to this URL as ${request.query.callback_url}.

In this scenario, you create multiple Processing Actions: One webhook handles "job queued", another one handles "job finished", and so on. In the webhooks, you can extract values, such as the job_id from the transaction request body, and use them.

The overall process looks like this:

1. If the transaction matches, the Mock Service responds "The job was submitted", as usual.
2. Five seconds later, the Mock Service triggers the "job queued" webhook.
   1. The webhook posts the status to the provided callback URL ${request.query.callback_url}.
   2. The callback body uses a variable to say: "The job ${jsonPath request.body '$.job_id'} is queued."
3. Ten seconds later, the Mock Service triggers the "job finished" webhook.
   1. The webhook posts to the provided callback URL ${request.query.callback_url}.
   2. The callback body uses a variable to say: "The job ${jsonPath request.body '$.job_id'} has finished."
4. And so on.

As you see, your Mock Service can trigger a series of requests asynchronously.

How to Define a Webhook Processing Action

Typically, you provide the callback URL in a query parameter, in the request body, or in the header of the request that starts a job. It is a good practice to match the callback URL in a transaction to ensure they are present.

1. Go to the Assets Catalog tab and create or edit a Transaction.
2. In the Request Matcher tab, include a matcher that ensures that the callback URL is provided.
   For example, use the matches regex operator with a value of ".+" on the callback_url parameter to verify that the callback_url value is present and non-empty.
3. In the Response tab, you can reference values, as usual.
   For example, you can define the response body as "Job ${jsonPath request.body '$.job_id'} submitted".
4. In the Processing Actions tab, click the Plus button to add one or more webhooks.
5. Define the webhook:
   1. In the Name field, give it a descriptive name.
   2. In the Trigger After field, specify a constant time in milliseconds or enable the Random Delay Between checkbox.
   3. Define the Callback URL and the method, for example, POST.
   4. (Optional) Define Query Parameters.
   5. (Optional) Define Header values.
   6. (Optional) Define the Body value.
6. Click Save.
7. Assign this transaction to a Mock Service.
8. Run the Mock Service and submit the test job to trigger the Mock Service.

Next, you may want to review the log.

How to Review the Webhook Log

1. Go to the Mock Services tab.
2. Open the Mock Service and verify that the transaction is attached.
3. Go to the Analytics tab.
4. On the Inspection tab, review the log of incoming requests to the Mock Service:
   1. Verify that the call was made.
   2. Verify that the call was matched by the transaction that triggers the webhook.
   3. Verify the response.
5. On the Webhooks tab, review the log of outgoing webhooks:
   1. Verify which webhooks were triggered, their method, and callback URL.
   2. Verify the timestamps when they were triggered.
   3. Select an entry to inspect query parameters used, headers, and body value.