Application Models

The application model is the highest level of abstraction, comprised of application scenarios. Application scenarios make it possible to orchestrate multiple virtual services in a single test. If you do not need to run multiple services, your application scenario can follow the minimal application model.

Minimal application model

In an application model file, you must define at least one application scenario. This is required because the SV Lab server API takes an application scenario name as the entry point for simulation.

The following example shows a minimal application model, taken from the Hello World demo (Lab/demo/hello-world):

import * as sv from "../../../../../../lib/sv-vsl.js"
import {HelloServiceModel} from "HelloServiceModel.js"

export class HelloApplicationModel extends sv.ApplicationModel {

    constructor(smHelloServiceModel: HelloServiceModel) {
        super();
        this.smHelloServiceModel = smHelloServiceModel;
    }

    @sv.applicationScenario
    sayHello() {
        this.smHelloServiceModel.simpleSayHello();
    }
}

Enable auto-completion

Add sv-vsl.js to make auto-completion work in your IDE:

import * as sv from "../../../../../../lib/sv-vsl.js"

We recommend that you always reference the sv-vsl.js file in your simulation model files. Its main purpose is to supply information about VSL constructs to help your IDE's auto-completion features. Please make sure the file exists in the referenced location before importing it.

Import service models

Import all the service models that you intend to use in the application model:

import {HelloServiceModel} from "HelloServiceModel.js"

To make a service model instance available inside an application model, pass it via constructor argument as shown below. The SV Lab server automatically injects an instance of the service model, when the application model is used.

constructor(smHelloServiceModel: HelloServiceModel) {
    super();
    this.smHelloServiceModel = smHelloServiceModel;
}

Create application scenarios

Once your service models are available in the application model, you can create an application scenario. The application scenario calls one or more service scenarios, as shown below.

To create an application scenario, add a dedicated method to the application model, annotated using the @sv.applicationScenario decorator. The name of the method defines the application scenario namem in this example, sayHello. You must use this name when starting the scenario using SV Lab server API.

@sv.applicationScenario
sayHello() {
    this.smHelloServiceModel.simpleSayHello();
}

Application models with multiple virtual services

The environment you want to simulate may often consist of multiple services. Composing multiple service simulations is the primary purpose of the application scenario.

The following example is taken from the MQTT Sensors and Actuators demo (demo\mqtt-sensors-and-actuators). When compared with the minimal application model, the differences are:

• you must import more than one service scenario in your application model file,
• you must inject all the service models using constructor arguments.

In the following example the application model uses two service models, ControlServiceModel and StatusServiceModel.

import * as sv from "sv-vsl.js"

import {ControlServiceModel} from "ControlServiceModel.js"
import {StatusServiceModel} from "StatusServiceModel.js"

export class MqttBuildingApplicationModel extends sv.ApplicationModel {

    constructor(control: ControlServiceModel, status: StatusServiceModel) {
        super();
        this.control = control;
        this.status = status;
    }

    @sv.applicationScenario
    applicationScenario() {
        // Call service scenarios here using this.control and this.status
    }
}

Service scenarios inside application scenarios

You can use service scenarios inside application scenarios, similar to the way you work with ordinary service scenarios.

Things you can do the same way	Things you cannot do
Call service scenarios in a sequence	Run one application scenario from another application scenario
Insert a delay between service scenario calls	Directly call methods on service interfaces inside an application scenario
Fork service scenarios to run in parallel independently on each other
Synchronize service scenarios forked to run in parallel	Synchronize application scenarios. Only a single application scenario runs within a simulation.
Share internal state using SV variables defined on the application scenario level