Share this page

# Script structure

This topic describes the layout of the main.js file used for DevWeb scripts. It also describes some of the important YAML and other files available for the DevWeb scripts. These files control the execution of the DevWeb engine and scripts.

In this topic:

## main.js file

The main.js file contains the main code for your DevWeb script.

main.js can contain three types of sections: initialize, action, and finalize. These can appear more than once and are executed in the order that they appear in the script.

Section | Description
--- | ---
initialize (optional) | Executed only once at the beginning of the script.
action (mandatory) | Executed in iterations throughout the duration of the script. Note: The script must contain at least one action section.
finalize (optional) | Executed only once at the end of the script, when all the action sections are finished running.

Tip: You can implement run logic to determine the order in which actions run during a test. For details, see Implement run logic.

The following is an example of the action section for a typical DevWeb script. An HTTP request is sent to a server and then uses some values from the response to determine if the transaction around that HTTP request has passed.

    load.action("Main", () => { //(A)

      const productTransaction = new load.Transaction("Product"); //(B)

      productTransaction.start(); //(C)
      const myPageRequest = new load.WebRequest({ //(D)
    	url: "http://myServer.com/main/product.html", //(E)
    	method: "GET",
    	returnBody: true,
    	headers: {
    	   "Accept-Language": "en-US,en;q=0.8",
    	   "Accept-Encoding": "gzip, deflate, sdch",
    	   "Accept": "*/*"
    	},
    	resources: [
    	   "http://my.server.net/sources/Caching/oldnavy.css"
    	]
      });

      const myPageResponse = myPage.sendSync(); //(F)

      /*Expected result is :
      <html>
         <body>
    	<h1>My product</h1>
    	<span productId="12">Very nice product</p>
         </body>
      </html>
      */

      const productId = load.utils.getByBoundary(myPageResponse.body,'productId="','"'); //(G)
      if (productId === null){ //(H)
         productTransaction.stop(load.TransactionStatus.Failed);
      }  else {
         productTransaction.stop(load.TransactionStatus.Passed);
      }
    });

The flow:

1. Declare a new action (A), Main, with a function containing all the code that will be executed as part of this action.

   All the elements of the SDK are within the load namespace (object), therefore the load. prefix is needed to access them.

   Note: The action name is mandatory and used internally only.

2. Declare a new transaction (B), Product, and store it in the productTransaction variable. This variable allows for obtaining information about the transaction and performing operations on it.
3. Start the transaction (C).

4. Declare a web request using the WebRequest constructor (D). The WebRequest constructor takes an object that configures the web request.

   For example, you can declare the URL for the web request (E). You can also set other properties for the request such as the header and extra resources. See WebRequest in the DevWeb JavaScript SDK.

5. Send the request synchronously (F). The script stops and waits to receive a response, and stores the response in the myPageResponse variable. Because the returnBody property is set to true in the web request options, you can access the full response body.
6. Use the getByBoundary function (G) to extract the product ID from the response. Using the product ID (H), you can determine if the Product transaction should pass or fail.

Note: After receiving the web response, you can view additional web request headers (on the WebRequest headers object) added during replay.

## Scenario resource file

The scenario.yml file is included in every script folder, and defines the scenario settings when running a DevWeb script in load mode.

You can define alternative scenario.yml files to use for script replay, give them a different name, and save them outside of the script folder. Each scenario file can contain different settings, and you can then reuse each scenario file with multiple scripts. You pass the location of the alternative file to use for the script from the command line.

For details, see Execute DevWeb scripts.

Note: This file is used for OpenText Performance Engineering for Developers only. When running a test in OpenText Professional Performance Engineering or OpenText Enterprise Performance Engineering, the scenario is defined in the testing tool itself.

The scenario run settings include pacing. Pacing controls the timing of iterations, by setting the pace for the Vuser to wait between iterations of the script actions. You can define the pacing as follows:

Property | Description
--- | ---
type | Pacing type. Possible values: delay. A delay after the previous iteration ends. interval. The interval from the beginning of one iteration to the next. Note: New iterations will not begin until the previous one completes, even if it exceeds the interval time.
mode | Pacing duration. Possible values: fixed. A fixed amount of time is used for the defined pacing type (delay or interval). random. An amount of time is selected at random for the pacing type (delay or interval), from a defined range of values.
value | The amount of time to use with fixed mode (in seconds).
min/max | The time range to use with random mode (in seconds).

Example of a scenario.yml file:

Copy code

    # All times are defined in seconds
    vusers: 1        #The number of Vusers that will be run during the test
    pacing:          #The period of time to wait between iteration of each Vuser
      type: delay    #The Pacing type, valid values: delay or interval
      mode: random   #The Pacing mode, valid values: fixed or random
      min: 3         #The min and max are valid on mode: random.
      max: 6         #The min and max determine the range of values
    rampUp: 2        #The number of seconds it will take to start all the Vusers
                     #The starting of Vusers that will be distributed equally throughout this time frame
    duration: 20     #The number of seconds to run Vuser iterations after all the Vusers have started running
    tearDown: 0      #Not used

## Runtime settings resource file

The optional rts.yml contains the default runtime settings for test runs, for example, timeouts for HTTP connections and logger settings.

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

## Parameter resource file

The optional parameters.yml contains the parameter descriptions for your script. This file is user-defined in the script folder.

The parameters file defines the parameters that can be used in the script and various aspects of how and when new values are retrieved.

For more information, see Parameterize values.

## Transactions resource file

The optional transactions file, transactions.yml, is only relevant for users of the SLA feature in OpenText Core Performance Engineering.

To enable the SLA feature, populate this file with a list of transaction names for which to calculate the SLA.

Note: The script must contain transactions with names that match the ones in transactions.yml.

Format the list as shown in the following example, where two transactions are defined, named foo and bar:

- name: foo

- name: bar

## Rendezvous resource file

The optional rendezvous.yml file is created automatically in the script directory during replay, if the main script contains rendezvous points. When a rendezvous point is reached, the Vuser stops running and waits for permission to continue.

Note: Rendezvous points are supported when running scripts in OpenText Professional Performance Engineering or OpenText Core Performance Engineering. They are not supported when executing scripts locally using OpenText Performance Engineering for Developers.

The rendezvous.yml file provides a list of rendezvous names, required by OpenText Core Performance Engineering to define the rendezvous policy. The file uses the following format:

- name: foo

- name: bar

In the above example, the file contains two rendezvous points with the names foo and bar. The script must contain rendezvous with matching names for the rendezvous functionality to work.

Before uploading a script to OpenText Core Performance Engineering, you must replay the script once so that the rendezvous.yml file is included in the zip file for the script.

For details on adding the rendezvous function to your script, see the JavaScript SDK Rendezvous section.

## User arguments resource file

The optional user arguments file, user_args.json, contains arguments that are used in the script for execution. These arguments are equivalent to the custom command line options used for VuGen scripts.

For argument properties, see Config in the SDK documentation.

The file is in a key-value JSON format (string values):

    {
        "key": "value",
        "hello": "world"
    }

## Example files

Sample DevWeb scripts, containing examples of the YAML files and other DevWeb files, are provided to help you create your own scripts. For example, you can use the scripts to experiment with, or as a basis for creating your own scripts, or take code snippets to reuse.

A large variety of sample scripts are available, and more are added in new releases. The scripts are located in the <DevWeb root folder>\examples folder.

## See also

- Create scripts
- Record and generate a script
- Run scripts
- DevWeb JavaScript SDK

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: