Simulation

Application and service models contain scenarios which serve as instructions for the simulation.

Modes of virtual service

Scenarios can either be executed in simulation or invocation mode. In forwarding mode, the virtual service is transparent and the simulation engine disengaged.

Simulation mode

In simulation mode, the simulation engine plays the role of the server side (service side). After receiving the intercepted requests, the simulation engine generates simulated responses.

Invocation mode

In invocation mode, the simulation engine plays the role of a virtual simulated client for a real service. The simulation engine sends out simulated requests toward a real service. It then validates whether the received responses correspond to what was specified in the simulation scenarios.

A service model written using VSL contains all of the simulation information for the client and service.

Forwarding mode

In forwarding mode, the simulation engine is disabled and the virtual service transparently re-sends requests and responses between the real client and real service. This mode is used in one of following situations:

• To learn simulation models.
• To perform full end-to-end test when the real service is intermittently available.

Application scenario simulation

The application scenario is the starting point for simulation. It contains calls to service scenarios that instruct the simulation engine when to and how to start the simulation of a virtual service. Service scenario calls specified in an application scenario are processed one by one. An application scenario can:

• [Call] a service scenario

  The simulation of the virtual service starts immediately, or after a specified delay. The simulation engine won't process the next specified service scenario call before the current service scenario finishes.

  For details, see Composing service scenarios.

• [Fork] a service scenario

  The simulation of the virtual service starts immediately, or after a specified delay. The simulation engine processes the next specified service scenario immediately.

  For details, see Composing service scenarios.

  Tip

  Using forked service scenario calls you can simulate more virtual services running in parallel. You can for instance start a scenario simulating a heartbeat operation, to prevent it from adding complexity to the main simulation flow.

Service scenario simulation

The simulated service scenario may contain message calls and service scenario calls, which are processed by the simulation engine.

A message call tells the simulation engine to either process an incoming message, or to produce an outgoing message, depending on the simulation mode.

A simplified version of the simulation algorithm used by the simulation engine producing outgoing messages based on an incoming one, can be described as follows:

1. Intercept an incoming message.
2. Select a service scenario. If several service scenarios of the same virtual service are available (see [Fork a service scenario] (#fork_scenario)), try to find the most appropriate scenario. For example, check the message operation that the service scenario expects at the current time.
3. If the intercepted message is expected by the service scenario, process the incoming message and proceed with the next call:
   • If it is a message call containing an output message, create an outgoing message and go to the next call of the service scenario.
   • If it is a message call containing an input message, wait for a next message to arrive.
4. If the intercepted message was not expected, try to find the most appropriate place in the scenario where the message could fit, preferably with the unprocessed scenario calls, and proceed with the execution and process (step 3) the incoming message.
5. If the intercepted message was not processes in previous steps, try to find a similar message to the incoming one in any scenario, preferring the non-default ones, and proceed with the execution from that point.

6. If the intercepted message was not processes in previous steps, produce a default message for given operation.

   Note

   Default messages are optional data examples used in operations declared inside service interface.

The following summary describes how the simulation degrades from the most accurate to less accurate when the client exhibits behavior that differs from service scenario:

• Happy path simulation: Applying only steps 1 and 2 means the simulation proceeds on the happy path and the simulation engine moves forward through the scenario without intercepting unexpected messages.
• Heuristic simulation: In step 3, in order to find the most appropriate place in the scenario a heuristic is used. The simulation can still move close to the happy path, just some messages came at unexpected moments.
• Stateless simulation: In step 4, the simulation engine simply tries to choose the most relevant message from the known ones, ignoring the current position in the executed scenarios, in order to produce some type of response.

SV variables simulation

When processing an incoming message, the simulation engine:

• may evaluate the SV variable to be able to compare the incoming message and the expected data specified in a scenario call,
• updates the SV variable with the incoming value.

When creating an outgoing message, the simulation engine must evaluate the SV variables to use their values in the outgoing message.

SV variable value evaluation details:

• If the SV variable has a non default value that was assigned already, the assigned value is used.
• A default value is assigned to the SV variable and used otherwise.

When the simulation engine compares an incoming message with the expected data of a scenario call, it produces a message in the run log if there was a mismatch. Parts of the message represented by SV variables are by default not compared. If there is a mismatch on such data, nothing is written to the run log. To force the simulation engine to compare a message part represented by an SV variable, the SV variable must be marked final. For details, see Final SV variables.

Delays

Each scenario call may have a delay assigned to it. It tells the simulation engine when to process or expect the call. The engine attempts to incorporate the delays when producing outgoing messages.

For details, see Delaying service scenario calls.

Performance best practices

Simulation performance is determined complexity of the simulated models and scenarios.

To create well performing models:

• Reduce SV variables usage: The simulation of SV variables uses resources and time. Messages without SV variables can be generated directly from the output and don't require extra processing time.
• Reduce scenarios length: Stateless simulation is faster than the happy path or heuristic simulation. It is used as a fallback when all the message calls of the simulated scenarios were processed.

To write the best performing simulation model:

• The service model should contain a single scenario for each operation without delays. The most common case is the request/response pair.
• The application scenario should fork all service scenarios without a specified delay.