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

This article covers:

• Webhooks
• HTTP Calls
• State Update
• How to View the Log

Usage

When do you use processing actions? 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 similar behaviors in a BlazeMeter Mock Service, you configure Processing Actions.

Processing Actions can reference values returned in responses of external services. 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.

At this time, the supported Processing Actions are Webhooks and HTTP Calls.

 

HTTP Calls

A Mock Service can trigger a HTTP request and then use the obtained response in the current transaction response body. The HTTP call is a synchronous call, this means the Mock Service waits for the HTTP call to finish before it sends back the response to the client.

How to Define a HTTP Call Processing Action

1. Go to the Assets Catalog tab and create or edit a Transaction.
2. In the Processing Actions tab, click the Plus button to add one or more HTTP Calls.
3. Define the HTTP Call:
   1. In the Name field, give it a descriptive name.
   2. In the URL field, select a method (for example, GET) and define a request URL that returns a response.
   3. (Optional) Define Query Parameters.
   4. (Optional) Define Header values.
   5. (Optional) Define the Body value.
4. Click Save.
5. Use the response value in the transaction response body with the following syntax. Replace  myHttpCallname with your HTTP Call's name to distinguish multiple calls. The syntax supports any handlebar from Wiremock.
   

   ${httpcalls.myHttpCallName.response.body}

6. Assign this transaction to a Mock Service.
7. Run the Mock Service and submit the test job to trigger the Mock Service.

Next, you may want to review the log.

Considerations

• A single transaction can have up to 20 different HTTP Calls associated with it.

 

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.

Considerations

• A single transaction can have up to 20 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.

 

State Update

When a transaction matches, a Mock Service cannot only return a value, but also modify existing data parameters in your Service Data. This processing action is useful to store a Mock Service's state or even, for example, to maintain a global counter as part of a test run. Mock Services that trigger State Updates are marked with a "stateful" tag.

This updated state persists even when stopping and restarting your Mock Service. The state is only reset when updating your Mock Service and then also choosing to update your data.

What is Global Scope?

In addition to accessing data parameters in data entities, State Updates can also access data parameters with a global scope. Global Data parameters are available to the whole service and are listed in the Global Scope section in your Service Data panel. You create global parameters by clicking the blue Plus button there.

How to Define a State Update Processing Action

You create a State Update processing action inside the transaction that triggers it.

Follow these steps:

1. Go to the Mock Services > Assets Catalog tab and select a Service.
2. Verify that the Service has Service Data attached. If not, create or load a Data Entity now.
3. Create a transaction or open an existing one.
4. In the Processing Actions tab of the Transaction, click the Plus button to add one or more State Updates.

In the State Change Definition window, define which data parameter you want to update.

Follow these steps:

1. In the Name field, give the Processing Action a descriptive name.
2. In the State Change Type field, select one of the following actions: 
   • Store Object — If the transaction matches, add a row of values to the data entity.
     1. Select a Data Entity.
     2. Click the Plus button to add the Selected Data Parameters in which you want to store values.
     3. Enter the Value to Store to add for the Data Parameter.
   • Update Object — If the transaction matches, update a specific value in an existing row in the data entity.
     1. Select a Data Entity.
     2. To define which rows of the Data Parameters you want to update, fill in the Filter by Data Parameter fields. Select a data parameter column, a comparison operator, and a comparison value.
     3. Click the Plus button to add the Selected Data Parameters in which you want to store values.
     4. Enter a Value to Store that will overwrite the existing value of the Data Parameter.
   • Delete Object — If the transaction matches, delete a specific column value in an existing row in the data entity.
     1. Select a Data Entity.
     2. To define which row and column of the Data Parameters you want to delete, fill in the Filter by Data Parameter fields. Select a data parameter column, a comparison operator, and a comparison value
   • Update Value — If the transaction matches, update a global value.
     1. Select or create a global data parameter.
     2. Define a Value.
   • Increment Value — If the transaction matches, increment or decrement a global value.
     1. Select or create a global data parameter.
     2. Enter a positive step Value to increment to counter. Enter a negative value to decrement the counter.
3. Click Save.
4. Assign this transaction to a Mock Service.
   The Mock Services is marked with a "stateful" tag.
5. Run the Mock Service and submit a test to trigger the transaction.

The operator in the data parameter filter supports the following comparison for strings and numbers, respectively:

• Equals
• Less than
• Greater than
• Starts With
• Ends With
• In — Returns true if the value matches an item in a list. Provide a comma-separated list of values.

 

How to View the 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 Processing Action.
   3. Verify the response.
5. On the respective Processing Action tabs (either Webhooks tab or HTTP Call tab), review the logs of outgoing Processing Actions:
   1. Verify which calls were triggered, their method, and URL.
   2. Verify the timestamps when they were triggered.
   3. Select an entry to inspect query parameters used, headers, and body value.