API Virtualization

Feature Availability: Release 5.0

ACCELQ's API virtualization allows you to set up Service simulation by responding to API calls with mock responses. Example use cases below:

• To test your application UI when some of the backend API services are still under development
• Application-under-test needs to communicate with an external API that is not accessible during the test execution
• When you deliberately want to prevent your testing from hitting the API services for cost or other resource considerations.

Virtualization is achieved by passing the API calls through a server that is equipped with a ruleset for intercepting requests and mocking responses. If there is a matching rule for the given API call, a mock response is returned by the Virtualization server. If not, the API call is passed through in the original route for the normal response.

ACCELQ achieves API virtualization through a set of simple commands that you can use in your Action logic.

Define virtualization rule

This command defines a service virtualization Rule which involves identifying the API call that should be intercepted and the mock response that should be returned. Every Rule should be provided with the following identifiers to allow referencing in the subsequent commands:

• A reference name to identify and reference the rule in subsequent commands. Make sure this is functionally meaningful.
• A group name for related rules (may be for all rules belonging to a particular service or all the rules for variations of an end-point etc.). A default group name is provided by the system if you skip this.
• Request matching criteria – URL, Endpoint, Method Type, Contents of Body, Headers, Query Params 
• Response Template – Response status, body, headers that should be returned as part of the mock response

Apply post processor to virtualization rule

This command is used to apply a post processor to a virtualization rule. A post-processor is a piece of custom logic that allows you to manipulate the mock response generated by a virtualization rule before it is returned to the consumer.

You can apply a post processor to either a single virtualization rule, all the rules belonging to a group, or all the defined virtualization rules in one shot, depending on the selection criteria you specify.

To use this command, you need to specify the selection criteria, as well as the reference names of the virtualization rule or group you want to apply to the post-processor. You also need to provide the names of the post-processor Actions as a comma-separated list. These Actions should belong to a Context named AQ$V12NPostProcessor, and they will have access to both the request and the mock response generated by the virtualization rule.

It is important to note that you must run this command before you enable the virtualization rule, as the post-processor must be added before the rule takes effect at runtime.

This command has the following parameters:

• rule selection criteria: This parameter specifies the criteria you are using to select the virtualization rules you want to apply the post processor to. You can choose from three options: "all virtualization rules", "virtualization rule", or "virtualization rule group".

• rule ref name: This parameter is used to specify the reference name of a specific virtualization rule. It is only required if you have chosen the "virtualization rule" as the selection criteria.

• group ref name: This parameter is used to specify the reference name of a virtualization rule group. It is required if you have chosen the "virtualization rule" or "virtualization rule group" as the selection criteria.

• post processor Action names: This parameter is a comma-separated list of the names (literal only) of the post-processor Actions you want to apply to the virtualization rule. These Actions should belong to a Context named AQ$V12NPostProcessor and will have access to both the request and the mock response generated by the virtualization rule.

Enable virtualization rules

This command enables virtualization for the API calls covered by the Rules already defined with the previous command. You have an option to enable virtualization by

• Reference name, when you want to pick one or more Rules explicitly
• Group name, which enables all the related Rules belonging to a group
• All services, which enables virtualization for all the API calls which are covered by the Rules

You may include multiple statements with this command to enable a series of virtualization Rules.

Disable virtualization rules

This command disables virtualization for the specified list of Rules. Maintaining symmetry with the "Enable" command, this command also supports three options below:

• Reference name, when you want to disable one or more Rules explicitly
• Group name, which disables all the related Rules belonging to a group
• All services, which disables virtualization all together

Delete Virtualization Rules

Clears/removes an already defined virtualization rule. This is different from enabling/disabling Rules, as the Rule is completely removed from the scope. You can either remove Rules by reference name, group name, or all the Rules in one go.

Set virtualization scope

Virtualization involves sending the API calls through a virtualization proxy to determine if there is a matching Rule. On a high level, you can choose to decide which of the API calls will be passed through this virtualization proxy:

1. ACCELQ API calls only; With this setting, only the API test cases defined in ACCELQ are evaluated for virtualization
2. Application API calls only: This setting enables only the API calls made by the test application (Web or Mobile) to pass through the proxy for evaluation. These are the API calls that your test application makes when you are running tests on the front-end.
3. All API calls: All the API calls during the test run are passed through the virtualization proxy.

If you do not use this command in your Action logic, by default virtualization is enabled for all API calls.

Example for virtualization

The following Scenario uses virtualization to return a mock response for the QBank API to get credit card offers listing.

The logic for the virtualization Action (Step 1 above) involves logic as shown here:

• Load the JSON to use as the mock response.
• Define virtualization rule for credit card listing API call, using the mock response
• Enable virtualization

Behind the scenes

When you work with service virtualization, ACCELQ sets up a virtualization server on the Agent machine which intercepts API calls based on the defined scope. If there is a matching Rule, this server responds with the pre-defined response from the Rule definition.

By default, ACCELQ picks the ports dynamically to enable this service. But if you have a requirement to use specific port numbers only, you can provide this information in the agent.properties file. 

Following properties are relevant in the agent.properties file (optional).

virtualization_ports_range=    # provide a range of numbers to use for virtualization

If this property is left blank, system will pick port numbers dynamically. When providing the port numbers, make sure the range is big enough to accommodate concurrent threads/jobs you anticipate to run. Number of ports required may be up to twice the number of anticipated concurrent threads/jobs.