Advanced Virtualization with Dynamic Responses

Once you've mastered basic mocking, you can create powerful, dynamic responses using ACCELQ's Post-Processor feature. This allows your virtual service to intelligently react to the data it receives in a request.

What is a Post-Processor?

A Post-Processor is a special ACCELQ Action that runs after a virtual service matches a request but before the final mock response is sent. Inside this Action, you can read data from the incoming request and use it to modify the mock response on the fly.

This requires creating an Action inside a special Context named AQ$V12NPostProcessor.

Example 1: Data-Driven Virtualization (Input Validation)

Let's create a virtual service that validates the age in a user creation request. If the age is less than 18, it should return a 400 Bad Request error.

1. Define the Base Rule:

   Define a rule for POST /users that returns a successful 201 Created response by default.

2. Create the Post-Processor Action:

   Create an Action (e.g., "Validate Age") inside the AQ$V12NPostProcessor Context with the following logic:

   1. Get the request body using Get request info of current virtualization request. Request Info: payload.
   2. Extract the age from the payload using Get value of a node....
   3. Use an If block: Is the number age less than '18'?
   4. Inside the If block:
      • Overwrite the status code: Overwrite the response status code for the current virtualization request to be: '400'.
      • Overwrite the body: Overwrite the response body for the current virtualization request to be: '{"Error": "You must be 18 or above"}'.

3. Apply and Enable:

   Use Apply post processor to virtualization rule to link your rule to the "Validate Age" Action, then enable the rule.3

Example 2: Service Orchestration Virtualization

Let's create a virtual service that orchestrates a response by calling another, real API. For example, our virtual service will receive a request containing an error code, call a real "error details" microservice to get the error message, and then embed that real message into its own mock response.

1. Define the Base Rule:

   Define a rule for an endpoint like GET /api/mock/errors/{errorCode}. The default mock response can be a template, e.g., {"code": 0, "message": "Default message"}.

2. Create the Post-Processor Action:

   Create an Action (e.g., "Orchestrate Error Message") with the following logic:

   1. Get the errorCode from the incoming request's endpoint.
   2. Build a new URL to the real error-details service: msg_endpoint = '/error/' & <errorCode> & '/details'.
   3. Call the real service: Invoke ReSTful GET service on the connection, 'conn1'. End-point: msg_endpoint....
   4. Extract the real error message from the response: Get value of a node in the JSON content from Latest REST Response. Node: '$.message'.
   5. Inject the real message into the final mock response: Set value of a node in the JSON content... Node: '$.message', Value: <real error message>.
   6. Overwrite the original mock body with this newly updated JSON content.

3. Apply and Enable:

   Apply the "Orchestrate Error Message" post-processor to your rule and enable it. Now your virtual service acts as a mediator, enriching its mock responses with real-time data from other services.