Share this page

# Customize runtime settings

This topic describes how to customize the runtime settings rts.yml file, to define enhancements for your test runs with DevWeb scripts.

In this topic:

## About runtime settings

The rts.yml contains the runtime settings for DevWeb script test runs. The default rts.yml file can be found in the DevWeb root folder, and includes descriptions of the runtime settings alongside each setting.

Note: The supported runtime settings vary, depending on the product version you are using.

The runtime settings are specific to each Vuser. If you want to customize these settings for your script, you can do so in a local runtime settings file that you create in the script's folder. For details, see Create a local runtime settings file.

You can also use the rts.yml to define additional files and attributes for your script.

The following table provides information for some of the sections and settings in rts.yml.

Section | Details
--- | ---
httpConnection | Configuration for the Net Loader component. Settings include: canonicalHeaderEntries. Set to false to configure DevWeb to pass request headers "as-is", instead of normalizing them.
network | Supported from version 26.3. Configure the IP version for the Vuser, to force the system to work with only IPv4 or IPv6. This applies for both the hostname and on the server side. The default is any, meaning that any available IP is used. Note: Setting a specific IP version (IPv4 or IPv6) may cause a conflict when working with Multi IP, resulting in unexpected results. For details on Multi IP, see Assign IP addresses to Vusers.
dns | Configure DNS resolution to be performed per Vuser. The obtained IP address is stored in the internal Vuser cache according to the TTL (Time to Live) setting. It is resolved again either when expired, or between iterations when Simulate new user is enabled (see replay entry, below).
grpc | Connection settings for the native gRPC communication protocol. (gRPC-Web is not supported.)
proxy | Proxy settings include PAC support, proxy server details and authentication credentials, authentication type (basic or NTLM), and excluded hosts.
ssl | SSL settings include enabling/disabling HTTP/2 and HTTP/3 support for replay, maximum TLS version to use, and whether to ignore bad certificates. Note: If the server refuses the HTTP/3 connection, DevWeb will fall back to the next enabled HTTP version. When HTTP/3 is enabled, DevWeb will use TLS1.3, regardless of the maximum TLS version defined in the runtime settings.
replay | Replay settings include: Simulate new user, enabling a new Vuser to be simulated in each iteration. This emulates a new user beginning a browsing session. Save snapshots on replay or error. Data push to the Dynatrace monitor. For details, see Dynatrace integration. Define multiple IP allocation to Vusers. For details, see Assign IP addresses to Vusers.
vts | Configuration for the VTS proxy server.
encryption | Key location for data decryption. For details, see Encrypt data.
vuserLogger | Includes the ability to enable log mode and set log level.
flow | Use to define run logic for actions. For details, see Implement run logic, below.
thinkTime | Use to configure think time pauses for Vuser during a script run .For details, see Configure think time, below.
openTelemetry | Connection setting for integration with openTelemetry Collector. For details, see OpenTelemetry integration.

## Create a local runtime settings file

You can create customized runtime settings for each script in a local rts.yml file in the script's folder. When the script runs, the customized runtime settings take precedence over the default runtime settings.

To customize local runtime settings:

1. Copy rts.template.yml from the DevWeb root folder to your script's folder, and rename it rts.yml.
2. Customize the copied file and save your changes.

## Implement run logic

Run logic is the order in which actions run during a test. You can define run logic for DevWeb scripts by adding a flow section to the local runtime settings file (rts.yml) for the script.

For information on customizing the rts.yml file per script, see Script structure.

The flow section defines the order in which the specified initialize, run, and finalize sections are run in the script. You can define random order, random selection, and group actions into blocks.

- The items in the initialize section are run only once, at the beginning.
- The items in the run section are actions that can be grouped into blocks, and can run for multiple iterations.
- The items in the finalize section are run only once, at the end.

By creating your flow, and breaking the actions into blocks, you can build the logic of how your test will run. Not all items that are defined in the script need to be included in the flow, so you can change the run logic without changing the actual code.

### Creating blocks

When creating blocks of actions, you can define the logic for how the blocks are run:

Logic name | Behavior
--- | ---
Sequential | The blocks, or actions in the block, run sequentially in the order they appear.
Random | An action or block is randomly picked each time, and only that action or block is executed.
Shuffle | Run all actions in the block (or in all the blocks), but in random order.

Other run logic parameters:

- loop: This defines the number of times to run the block. It must be a positive number, greater than 0. You cannot define a loop value on the run section level.

- probability: When using random logic, you can define the probability value for each item. This can be any value from 0 to 100, but the total probability for all items must add up to 100%.

### Flow section example

The following shows an example of code from a script, and the flow section created for the script in the rts.yml file.

Note that not all items listed in the script appear in the flow; items that are not included do not participate in the flow.

Tip: You can also check out the flow example in the <DevWeb root>\examples\CustomRunLogic\rts.yml file.

Script example:

    load.initialize('Set default headers', async function () {
        //Set default headers
    });
    load.initialize('Login', async function () {
        //Do login
    });
    load.initialize('Set additional defaults', async function () {
        //Set additional defaults
    });
    load.initialize(async function () {
        //Initialize something else
    });
    load.action("Add food to the cart", async function () {
        //Add food to the cart
    });
    load.action("Add chocolate to the cart", async function () {
        //Add chocolate to the cart
    });
    load.action("Add marshmallow to the cart", async function () {
        //Add marshmallow to the cart
    });
    load.action("Add doughnut to the cart", async function () {
        //Add doughnut to the cart
    });
    load.action("Purchase items in the cart", async function () {
        //Purchase items in the cart
    });
    load.finalize('Logout', async function () {
        //Do logout
    });
    load.finalize('Clear cookies', async function () {
        //Clear cookies
    });
    load.finalize(async function () {
        //Finalize something else
    });
    load.finalize('Clear headers', async function () {
        //Clear headers
    });

Flow section example:

    flow:
      # Allow the user to enable or disable the flow control
      enabled: true
      initialize:
        #List of initializers to be used.
        #An empty list will lead to no initializers.
        items:                                            #List of items to run.
          - name: "Set default headers"
          - name: "Login"
      run:
        #Define the logic between the items, can be sequential, random or shuffle.
        logic: "sequential"
        items:                                            #List of items to run.
          - name: "Add food to the cart"                      #Define the action name.
          - name: "Add something sweet to the cart"           #This part create a "block" of actions.
            logic: "random"
            #Loop a positive number define the number of times to run the current section
            loop: 3
            items:
            - name: "Add chocolate to the cart"
              #Probability value between 0 to 100 include. Total probability of all items should be 100%.
              probability: 40
            - name: "Add marshmallow to the cart"
              #Probability value between 0 to 100 include. Total probability of all items should be 100%.
              probability: 60
          - name: "Purchase items in the cart"
      finalize:
        #List of finalizers to be used.
        #An empty list will lead to no initializers.
        items:                                            #List of items to run.
          - name: "Logout"
          - name: "Clear cookies"

### Using DevWeb run logic in OpenText Professional Performance Engineering

When you run your DevWeb script in OpenText Professional Performance Engineering, the defined run logic flow for your script is displayed in the Run Logic view in the script runtime settings.

## Configure think time

Think time defines for how long the Vuser will pause its execution at the point where think time is used. This is to emulate a user pausing before moving on to the next step in a business process.

You can configure think time settings, to control how the Vuser uses think time, and how the recorded think time in your script is handled, during script execution.

In the thinkTime section of the rts.yml file, define the type for think time. The supported types are:

- ignore. Ignores the recorded think time, and runs the script without any delays.
- asRecorded. The think time that was detected during recording is replayed without change.

- multiply. The recorded think time is multiplied by a value you define (from 0.01-10000). For example:

      thinkTime:
        limit: 0
        type: multiply
        arguments:
          by: 5

- randomPercentage. Uses a random percentage of the recorded think time, within defined minimum and maximum percentage values. The minimum range you can define is 1-150. The maximum range is 50-10000.

  For example:

      thinkTime:
        limit: 0
        type: randomPercentage
        arguments:
          max: 50
          min: 3

You can also set a limit value, to define a maximum think time for each think time period during script execution.

- The possible range is 0-10000 seconds.
- -1 indicates disabled.

## Additional files

In the local rts.yml for the script, you can define additional files in a files section (use the absolute path if they are not in the script folder). The additional files are automatically loaded as part of the script and therefore contain the load namespace, as defined by the JavaScript SDK. The files section also defines the role of the file - this should be set as `script`.

In the following example, the additional file is called extra.js:

    files:                   # A list of all the extra files which are a mandatory part of the script
      - name: extra.js       # The file name, it can be relative to the script directory or rooted
        role: script         # The role of the file in the script. Currently only "script" role is supported

The <DevWeb root folder>\examples\CustomRunLogic script includes an example for using an additional file with a run logic flow.

## Add additional attributes

You can provide additional attributes for your DevWeb scripts by specifying user arguments. These arguments are retrieved during the test run using load.config.user.args (see Config).

For each additional attribute, you define the attribute name and its value. There are three ways that you can define the user arguments for the attributes, with a hierarchy to determine the value to use at runtime, as described below:

Location of user argument | Description
--- | ---
rts.yml | Add the attributes to the script's rts.yml file using the userArguments parameter. For example:
    userArguments:
      username: admin
      Attribute_2: system
user_args.json | Add the attributes to a user_args.json file in the script folder. The values must be strings. The value defined for a specific attribute overrides any value defined for that attribute in the rts.yml file. For example:
    {
      "username": "RDteam",
      "Attribute_2": "system"
    }
command line | Add the attributes to the command line using the argument userArgs. The value defined for a specific attribute overrides any values defined for that attribute in the user_args.json or rts.yml files. For example:
    DevWeb  -userArgs="{"username": "Kim"}"

## See also

- Script structure

https://admhelp.microfocus.com Performance Engineering for Developers 8942
Tips to improve your search results... OpenText™ Performance Engineering for Developers Help Center OpenText™ Performance Engineering for Developers Help 26.1-26.3 All View Local Help Center View Online Help Center Version: