Create a virtual service

A virtual service is a deployable mock endpoint that stands in for a live service during a test. In the following procedures, we refer to the following concepts:

  • Transaction — A request/response pair. It defines how the virtual service responds when an incoming request matches specific criteria.
  • Service — A named container in the asset library. In BlazeMeter, a service represents one underlying live service, and all its transactions are available to any virtual services in it.
  • Virtual service — A running mock endpoint. It is part of a service and activates your selected subset of that service's transactions to handle incoming requests.

To learn more about these concepts, see Introduction to service virtualization.

Workflow overview

  1. Create a service — Create a named container to hold your transactions. BlazeMeter can create a service automatically during import. To create a service in advance, see Create a service.
  2. Add transactions to the service — Import a file, record live traffic, or add transactions manually. To learn how to import or create transactions, see Adding transactions.
  3. Create the virtual service — Choose the starting point that fits your use case:
  4. Configure the virtual service — Set the location, endpoint protocol, and other parameters. See Complete the configuration of your virtual service.
  5. Include transactions — Select which of the service's transactions this virtual service should use. See Include/exclude transactions in a virtual service.
  6. Run the virtual service — See Running a virtual service.

Create a virtual service from transactions (import file)

Use this method when you have an API specification file to import, such as OpenAPI, Swagger, HAR, or WSDL. To upload multiple Swagger files using a zip file, the main file in the zip file must be named index.json or index.yaml. The import flow creates a service and adds the transactions automatically.

  1. Navigate to the Service virtualization tab and click Virtual services.
  2. Click the Plus button and select Create from transactions.
    create-a-ms.png
    A new row is added to the top of the Virtual services list.
  3. Enter a Name for the virtual service.
  4. Drag your file into the upload area, or click the upload area to browse to the file.
    upload area
    The Import transactions dialog opens.
    import transactions
  5. Select an existing service to hold the imported transactions, or create a new service. For details on supported file formats, import options, and tags, see Adding transactions.
  6. (Optional) To tag the imported transactions, type names in the Tags field and press enter after each.
    Tags make transactions easier to identify in the list, especially within a large service. Either define one tag for all imported transactions here, or define individual tags at the transaction level after import.
  7. Click Import.

Create a virtual service from transactions (existing service)

Use this method when you already have a service whose transactions you want to use in a new virtual service. No file upload is needed.

  1. Navigate to the Service virtualization tab and click Virtual services.
  2. Click the + button and select Create from transactions.
    create-a-ms.png
    A new row is added to the top of the Virtual services list.
  3. From the Service drop-down, select the service that contains the transactions you need.
  4. Add and remove transactions as needed.

Continue with Complete the configuration of your virtual service.

Create a virtual service from live traffic

Use this method when you want to capture live traffic as transactions instead of providing a file. You record a series of browser interactions, and the recorder generates the transactions and creates a virtual service from them.

To learn more, see Record HTTP transactions or Virtualizing message queues.

Create a virtual service from a custom template

Use this method when you have a saved template that defines a reusable set of transactions. A requirement is that you have created a virtual service template.

  1. Go to the Virtual service templates tab.
  2. In the Actions column of the template, click the Create virtual service button.
    create virtual service from template

Your virtual service is created and available in the Virtual services tab. To learn more about templates, see Creating a virtual service template.

Create a virtual service from the Blueprints Library

Use the Blueprints Library when you want ready-made transactions for a common API, such as OpenAI, Azure DevOps, or Google OAuth2, instead of building transactions from scratch.

  1. Add transactions from the Blueprints Library to a service.
  2. Review the generated transactions and adjust matchers or responses as needed.
  3. In the Virtual services tab, click the Plus button to create a virtual service.
  4. Add the blueprint transactions to the virtual service.

Complete the configuration of your virtual service

After you have created a virtual service using one of the above methods, complete its configuration.

  1. In the Name box, enter a name for the virtual service.
  2. Click the arrow next to the virtual service name to expand the details for the virtual service.
    1. (Optional) Enter a Description for your virtual service.
    2. (Optional) Select a Configuration. If needed, define attribute-value pairs for your environment variables on the Configurations tab.
    3. (Private location only) Under Create log, enable or disable logging on the private location. To learn more, see Running virtual services on private locations.
  3. In the Location drop-down list, select the location that you want to deploy your virtual service to. Select from the available Google Cloud Platform locations (US East or EU West) depending on your location. Or select a private location.
  4. From the Endpoint drop-down, select either HTTPS or HTTP. The default is HTTPS.
  5. (Optional) To run the virtual service in a private location, select a preferred port in the Port field.
    preferred-port.png
    To learn more about preferred ports, see Select a preferred port.
  6. Under Runner, leave the default HTTP Runner.
    To learn more about the optional Messaging runner, see Virtualizing message queues.

Add transactions to the service

To add transactions to a service, you can upload additional transactions directly on the Service virtualization tab without having to switch tabs. Drop a file into the upload area or click the Plus button to create new transactions.

To learn more about recording or loading transactions in a variety of formats, see Adding transactions.

Include/exclude transactions in a virtual service

After you have added transactions to the service and have created a virtual service, the next step is always to select the transactions for this virtual service and define their parameters.

On the Transactions tab:

  1. Select transactions that you want to include. You have several options:

    • Search and filter transactions in the columns by entering a tag or search text.

    • To select all transactions visible in the column (not all transactions in the service), click the check box in the column header.

    • Or, manually select checkboxes in the columns.

  2. Move selected transactions from the Other transactions in your catalog column to the Transactions in this virtual service column.
    You have several options how to do this:

    • Click the Right arrow to move selected transactions from Other transactions in your catalog column to the Transactions in this virtual service column. Select checkboxes in the Transactions in this virtual service column and click the Left arrow to remove these transactions from the virtual service.
      transactions tab

    • Use the quick action to move selected transactions with a single click: Click the Include this transaction in the virtual service icon in the left column. To remove a transaction from the virtual service, click the corresponding Remove this transaction from the Virtual service icon in the right column.
      include transaction

      remove transaction

  3. (Optional) In Transactions in this virtual service column, expand each transaction and define a Priority to control the matching order when a request matches multiple transactions. The transaction with the lowest priority number matches first. For details, see Priority of multiple matching transactions in a virtual service.
    priority value transaction

On the Parameters tab:

  1. (Optional) In the Think time section, define an artificial delay between the request and the response. To learn more, see Simulating irregular response latencies.
    Default: "No delay".
  2. (Optional) In the No matching requests section, choose the expected behavior for when a request against the virtual services does not match any of the provided transactions. The request can either throw an error or be redirected to the live service.
    Default: Return no match found (404)
  3. (Optional) In the Proxy section, define a proxy to connect to the live system endpoint.
    Default: No proxy
    • Proxy URL
    • Username
    • Password
    • Certificate — Upload or select a certificate needed for the connection.
    • No proxy — Provide a comma-separated list of URLs to exclude from this proxy.
  4. (Private locations/Docker only) Select an Keystore & Truststore Override. To learn more, see Running virtual services on private locations.
  5. (Optional) Define Rate Limits to simulate server response 429: too many requests.
    • Rate Limit (req/s) — Define a simulated rate limit after which the mock service will reject further requests. Or leave empty to disable the rate limit.
    • Burst Size — Define the maximum burst capacity or leave empty for no burst allowance.
  6. (Optional) Define Authentication. To protect access to mocked API endpoints, you can enforce authentication at the service level.
    • None — No authentication, this is the default.
    • HTTP Basic — Clients authenticate with a username and password through standard HTTP Basic auth.
    • Header Match — Require a specific header name and value (for example, X-Api-Key) using the familiar header matcher pattern.
  7. Click Save.

    Your virtual service is saved and added to the list of available virtual services.

    mock_services_list.png

The virtual service is not active until you run it.

Click Run virtual service to run it. For information about the next steps, see Running a virtual service.

 

Modify transactions in a running virtual service

You can add and remove transactions or modify existing transactions without having to restart the virtual service.

  • To add a transaction to or remove it from the virtual service, update the virtual service's transaction list in the virtual services tab and then click the Update button. When you run the test again, the changes will be reflected.
  • To modify a transaction, make the changes and click Save in the transaction. Then click the Update button in the virtual services tab. When you run the test again, the changes will be reflected.
To edit Configurations, stop the running virtual service, change the configuration, and redeploy the virtual service.

Define priority of multiple matching transactions in a virtual service

When you test against a virtual service, the virtual service first attempts to match incoming requests against any of its transactions. The transactions can be explicitly spelled out requests or regular expressions. When a virtual service receives a request that matches multiple transactions, the virtual service chooses the transaction with the lowest value in the Priority field.

Examples:

  • Say you have a virtual service for a service that searches by zip code with two transactions. Transaction A matches a parameter value of 75024, and transaction B matches any five-digit number. You want the transaction with the more specific matching criteria (transaction A) to have the higher priority so that it matches first, and the broader matching criteria (transaction B) shall only match if the specific zip for transaction A is not entered, so you give it lower priority.
  • After importing 100 transactions, they are all assigned the same default priority of 10. Fifteen of them are generic transactions that should be matched only after the more specific eighty five are matched. You don't want to have to manually change the priority level of eighty five transactions to 9. In this case, it's quicker to give the fifteen generic transactions a priority of 20, below the default of 10.

Consider this matching logic when determining which transactions to add to a virtual service, and whether one or more virtual services are required to meet your testing requirements.

Setting a Priority for a transaction only applies to that transaction within the current virtual service. In other virtual services or templates, the same transaction can have a different priority value.

Every transaction is added with the default priority level of 10.

  • To have a transactions match first, set its priority to 1.

  • To have a transactions match before another, set its priority to a lower number.

  • To have a transactions match after another, set its priority to a higher number.

  • To have a transactions match last, set its priority to 20.

You can assign the same priority to multiple transactions. Therefor it can happen that multiple matching transactions have the same priority. In this case, the virtual service chooses the most recent transaction first (the one with the highest transaction ID number). To have fine control over the priority over default transactions, assign them unique priorities. Unique priorities use an index counter that defines the order without ambiguity.

To assign unique priorities:

  1. Add transactions that can match.

  2. Enable Unique priorities.
    The Customize unique transaction priorities window opens and a table lists all included transactions.

  3. Arrange the rows in order of highest to lowest priority. You can use the following methods:

    • Click the handle and drag a transaction up to increase its priority.

    • Click the handle and drag a transaction down to decrease its priority.

    • To reorder a transactions to be first, click Move transaction to beginning.

    • To reorder a transactions to be last, click Move transaction to end.

    • To reorder multiple transactions, enable their checkboxes and click the Move transaction to beginning or Move transaction to end button (respectively) above the table.

    • To reorder priorities after Unique priority has been enabled, click the Customize button.

Configure runtime properties

(Optional) To optimize the performance of your virtual services, adjust their runtime properties. Go to Virtual services and open the Virtual service tab, and go to the Runtime properties tab.

  • Show Logs

    • Show logs enabled - Choose whether you want to capture runtime logs. Setting this to false can improve performance by approximately 5%.

    • Show logs max size - Specify the maximum amount of logs to be captured. Enter a number between 0 and 100.

  • Static response caching

    • Caching enabled - A static response is a response that uses no dynamic templates in its body or headers. If you cache static responses, repeated requests for the same styatic content are served faster, which increases the response time and performance of transactions with large response body sizes. On the other hand, it also increases the resource consumption while the virtual service is idle. Disabled by default.

  • Secrets

    • Secrets enabled - Enables or disables the Secrets functionality for this virtual service. Use this feature to avoid hard coding API keys, passwords, and similar into your test scripts. Enabled by default.

  • Inspection data

    • Inspection data enabled - Choose whether you want to capture inspection data. If you enable it, configure the following fields:

    • Max number of stored inspection data requests - Enter a number between 0 and 100.

    • Inspection data max requests per second - Enter a number between 0 and 5.

    • Inspection data max actions per second - Enter a number between 0 and 50.

    • Inspection data max body size - Enter a number in bytes between 0 and 10,240,000 (10MB).

  • Matcher logs

    • Console matcher logs enabled - Enabling this setting can significantly decrease performance. Default is false.

    • Show logs matcher logs enabled - Enabling this setting can significantly decrease performance. Default is false.

    • Matcher logs cache max size - Enter a number between 1 and 1000.

  • Scripting

    • Scripts enabled - Enable or disable processing of JavaScript in templates. Default: true.

    • NodeJS Enabled - Enable or disable NodeJS processing of JavaScript in templates. Always disabled for cloud locations. Default: false.

  • Web Server Configuration

    • Web server container threads - (Optional) Define the number of threads in the web server container. Enter a value between 12 and 1000. The default value for web server threads is the number of processor cores × 32.

    • Request timeout - Enter a number between 0 and 300000 milliseconds.

To edit Configurations, stop the running virtual service, change the configuration, and redeploy the virtual service.

Group multiple virtual services under a single endpoint

(Optional) If you are running multiple virtual services across different Services, and the requirement arises that you need to run them under a single endpoint and port, you can group them.

  1. Go to Virtual services and open the Virtual service groups tab.
  2. Click the blue plus button to create a virtual service group.
  3. Give the group a name and description.
  4. Select a Location.
  5. Select an Endpoint protocol.
  6. Define an Endpoint port.
  7. (Optional) Define tags.
  8. On the Virtual services tab, click Assign virtual service to add one or more virtual services to the group.
  9. On the Parameters tab, optionally, configure SSL authentication.

Now, under Actions, click the green Run button to run this group under a single endpoint.