Categories: USER GUIDE PLANS

Controls

Step supports a wide range of so-called controls to build-up complex flows in Plans. The supported controls range from classical control structures (like if blocks, loops, etc) to use-case specific controls like thread groups for load-testing, data-sets, etc. This page provides details about all the controls supported by Step.

General controls

Set

The Set control allows to define a variable and assign it a value. Variables defined with Set controls can be accessed according to their scope throughout Plans and sub Plans. Combined with the power of groovy, almost anything can be achieved in a Set node.

Variables are uniquely defined by their key. When a Set is executed, if no variable exists within the scope of the Set, a new variable will be defined. If a variable exists under the specified key, the variable defined previously will be updated.

The value of the variable can be defined either as string or as an expression.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Key : the name of the variable to be defined or updated
  • Expression : the value of the variable as string or as groovy expression to be interpreted (with groovy evaluation enabled)
Examples
set.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page. The following example shows how to assign a string to a variable in a YAML plan and read its content in an Echo afterwards:

---
version: "1.0.0"
name: "Plan example"
root:
  testCase:
    nodeName: "Plan example"
    children:
    - set:
        key: "myVar"
        value: "Hello world"
    - echo:
        text:
          expression: "myVar"

Following example shows how to assign a value to a variable using a groovy expression. The example would log “2” in the execution report.

---
version: "1.0.0"
name: "Plan example"
root:
  testCase:
    nodeName: "Plan example"
    children:
    - set:
        key: "myVar"
        value:
          expression: "1 + 1"
    - echo:
        text:
          expression: "myVar"
Properties

There is no specific property using this control with natural language, see below example for usage.

Examples
// Set - City to Basel
Set City="Basel"
// Echo - City
Echo City
// Set - City to Bern
Set City="Bern"
// Echo - City
Echo City

Not yet documented.

Echo

The Echo controls allows to print data in the execution report of Plans, mostly for debugging or information purposes.

It can print a hardcoded string value or the result of any expression.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Text : the data you want to display (can be a groovy expression if Groovy mode is toggled)
Examples
echo.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

The following example shows how to print a simple string in a Plan:

---
version: "1.0.0"
name: "Plan example"
root:
  testCase:
    nodeName: "Plan example"
    children:
    - echo:
        text: "Hello world"

The following example shows how to print the result of an expression:

echo:
  text:
    expression: "1 + 1"
This would print "2" in the report.
Properties

There is no special property in natural language.

Examples
// Echo - Hello World !
Echo "Hello World"

Not yet documented.

Sleep

The Sleep control allows to pause the current execution thread according to a configured duration.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Duration : the amount of time to sleep.
  • Unit : ‘ms’ for milliseconds (default), ’s’ for seconds and ’m’ for minutes.
  • Advanced :
    • Release Tokens : release tokens reserved in current session (details).
Examples
sleep.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following example shows how to sleep 1s before performing another action in a Plan:

---
version: "1.0.0"
name: "Plan example"
root:
  testCase:
    nodeName: "Plan example"
    children:
    - sleep:
        duration: 1
        unit: "s"
    - echo:
        text: "After 1s sleep"
Properties
  • Duration : the amount of time to sleep.
  • Unit : ‘ms’ for milliseconds, ’s’ for seconds and ’m’ for minutes.
  • ReleaseTokens: (optional, default is false) release tokens reserved in current session (details)
Examples
// Sleep control with a duration of 3 seconds
Sleep Duration=3 Unit="s"
//Optional parameter 'ReleaseTokens' (false by default)
Sleep Duration=100 Unit="ms" ReleaseTokens=true

// Simplified syntax (ReleaseTokens option and Groovy String interpolation not supported)
Sleep 100ms
Sleep 1m
Sleep 1h

Not yet documented.

Script

Executes any arbitrary groovy code. The script context is local, which means that variable used in the script control cannot be accessed externally by other nodes.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Script: the groovy code to be executed
Examples
script.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

The following example shows how to use the Script control to add elements to an array:

---
version: "1.0.0"
name: "Plan example"
root:
  testCase:
    nodeName: "Plan example"
    children:
    # Declare an array
    - set:
        key: "myArray"
        value:
          expression: "[]"
    # Add elements to the array using the Script control
    - script:
        script: "myArray.add(\"Apple\")\nmyArray.add(\"Orange\")"
    # Output the array to the execution report
    - echo:
        text:
          expression: "myArray"
Properties

There is no special property in natural language.

Examples
-
// Script - A custom script
Script 
result = 5 + 7;
-

Not yet documented.

Check

The Check control allows to perform custom assertions within Plans.

To perform assertions on the output of Keyword executions, it is recommended to use the Assert control. This control is usually used instead of the Assert control if custom expressions are required.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Expression : the expression to be asserted
Examples
check.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following examples shows how to perform an assertion with the Check control. In this example we assert that the value of the variable ‘myVar’ is equal to ‘Hello’

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Example plan"
    children:
    - set:
        key: "myVar"
        value: "Hello"
    - check:
        expression: "myVar == 'Hello'"
Properties
  • Expression : the expression to be asserted
Examples
 // DefineLocation
DefineLocation
// Check the return value
Check Expression=previous.location.toString().equals('Basel')

Not yet documented.

Assert

The Assert control allows to perform validations after a Keyword execution on its output. It works only in combination with Keyword calls and has to be placed as child element of Keyword calls in the plan tree.

Basically it allows to compare the actual value of a Keyword output property with a defined expected value. It supports a wide range of operators to perform string-based but also numerical comparisons.


  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Output attribute : the key of the Keyword output property to be validated. In order to perform assertions on complex Keyword outputs, this field also supports JSONPath to identify the output property.
  • Operator : the type of verification
  • Expected value : the value you want to check against
  • Negate the assertion: tick the box to enable the negation of the value you want to check against
  • Custom error message: display a custom error message when the assertion fails

Available operator values are :

  • equals : asserts true if the specified output attribute value and the expected value are strictly equals
  • begins with : asserts true if the specified output attribute value begins with the expected value
  • contains : asserts true if the specified output attribute contains the expected value
  • ends with : asserts true if the specified output attribute value ends with the expected value
  • matches : asserts true if the specified output attribute value matches the expected value (regular expression can be used as expected value)
  • less than (less than or equals): asserts true if the specified numeric output attribute value is less than (or equal to) the expected value
  • greater then (greater than or equals): asserts true if the specified numeric output attribute value is greater than (or equal to) the expected value
  • is null: asserts true if the specified output attribute value is null or the output attribute is missing
Examples
assert.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following example shows how to assert the value of a Keyword output. After the call to the Keyword HttpRequest, the Assert control asserts that the Keywourd output StatusCode equals “200”. To test this example, first upload the Keyword package step-library-kw-http. Refer to Keyword deployment for instructions on deploying a Keyword package.

---
version: "1.0.0"
name: "Plan example"
root:
  testCase:
    nodeName: "Plan example"
    children:
    - callKeyword:
        keyword: "HttpRequest"
        inputs:
        - URL: "https://www.exense.ch"
        children:
        - assert:
            actual: "StatusCode"
            operator: "EQUALS"
            doNegate: false
            expected: "200"
            customErrorMessage: ""
Properties

There is no specific property using this control with natural language, see below example for usage.

Examples
 // FindCity
FindCity

// Assert - City equals "Basel"
Assert City = "Basel"
// Assert - City begins with "Basel"
Assert City beginsWith "Basel"
// Assert - City contains "Basel"
Assert City contains "Basel"
// Assert - City ends with "Basel"
Assert City endsWith "Basel"
// Assert - City matches "Basel" (regex)
Assert City ~ "Basel"
// Assert - Count is less than 10
Assert Count < 10
// Assert - Count is less than or equal to 10
Assert Count <= 10
// Assert - Count is greater than 10
Assert Count > 10
// Assert - Count is greater than or equal to 10
Assert Count >= 10
// Assert - City is missing or null
Assert City isNull

Not yet documented.

Export

Give the possibility to export the execution attachments to a specific location on the Step Controller.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Values : has to be “report.attachments” with groovy evaluation enabled
  • File : the file or directory path where to export the attachments
  • Prefix : prefix to be prepended to the exported file names
  • Filter : regular expression to use in order to filter files to export on their name
Examples
export.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

This control is not supported using natural language.

Not yet documented.

Control Structure

Sequence

The Sequence control executes its children nodes sequentially. Per default the execution of the Sequence is interrupted after the first error. It can be configured to continue on error and ensure that all children are executed even if an error occurs in one of the children.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Continue sequence execution on error : specify if the sequence should continue until its end if an error occurred within
  • Pacing : minimum execution time for the whole sequence to be executed (in milliseconds) as a Long
Examples
sequence.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following example shows how to define a simple sequence of 2 steps:

---
version: "1.0.0"
name: "Plan example"
root:
  sequence:
    nodeName: "Plan example"
    continueOnError: false
    children:
    - echo:
        text: "Step 1"
    - echo:
        text: "Step 2"
Properties
  • ContinueOnError : <true|false> specify if the sequence should continue until its end if an error occurred within
  • Pacing : minimum execution time for the whole sequence to be executed (in milliseconds) as a Long
Examples
// Sequence - Order Keywords execution
Sequence ContinueOnError = true Pacing = 1000l
    // MyFirstKeyword
  MyFirstKeyword
  // MySecondKeyword
  MySecondKeyword
End

Not yet documented.

BeforeSequence

This control has been replaced by the new Before Section. The only exception is the plain text editor. (see: plain text exclusive controls)

AfterSequence

This control has been replaced by the new After Section. The only exception is the plain text editor. (see: plain text exclusive controls)

If

Executes the child nodes if the specified condition is met. If the specified condition is met, the child nodes are executed sequentially similarly to Sequences.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Condition : the expression evaluated to know if the content of the node is executed
Examples
if.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

if:
  condition:
    expression: "true"
    children:
      - echo:
          text: "True is always true :)"
Properties

No condition for this control used with natural language. See below example for usage.

Examples
If 1==1
  Echo "Condition met"
End

Not yet documented.

Switch / Case

Same as in any programming language, this 2 controls work in combination.

  • Visual editor
  • YAML
  • Plain text
  • Java
Switch property
  • Expression : the expression to switch on to
Case property
  • Value : the value to be potentially matched
Examples
switch-case.png case.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Performs different actions depending on the value of a random variable randomValue using the Switch control

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Switch case example"
    children:
    - set:
        key: "randomValue"
        value:
          expression: "(new java.util.Random().nextInt(2)).toString()"
    - switch:
        expression:
          expression: "randomValue"
        children:
        - case:
            value: "0"
            children:
            - echo:
                text: "The value was 0"
        - case:
            value: "1"
            children:
            - echo:
                text: "The value was 1"

This controls are not supported using natural language.

Not yet documented.

Synchronized

Guarantee thread safety within a test block by synchronizing all threads on the entire Test Execution. Additionally, by using the lock name and the global lock properties, you can synchronize threads across different blocks and test executions.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Lock name: the name of the lock, leave empty if you want this lock to synchronize on this plan node
  • Global lock: select this check-box if you want this lock to be global across all the executions
Examples
synchronized.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

In the following example, the Synchronized control ensures that the Echo control is never run in parallel

---
version: "1.0.0"
name: "Example plan"
root:
  threadGroup:
    nodeName: "Plan root"
    users: 10
    iterations: 10
    children:
    - synchronized:
        lockName: ""
        globalLock: false
        children:
        - echo:
            text: "This echo is never run in parallel"
Properties
  • LockName: (optional) when unspecified, synchronization happens on this plan node
  • GlobalLock: (optional) set this property to true if you want this lock to be global across all the executions
Examples
Synchronized LockName="myLockName" GlobalLock=true
  // MyFirstKeyword
  MyFirstKeyword
  // MySecondKeyword
  MySecondKeyword
End

Not yet documented.

For

Creates a For loop at execution time and iterates through its children

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Start : the initial value of the for loop
  • End : the final value of the for loop (exit condition)
  • Increment : the increment value at the end of each iteration
  • Counter variable (handle) : the name of the variable containing the value of the iteration counter
  • Number of threads : the number of threads to use in order to parallelize the loop (i.e the execution of the children)
  • Maximum number of failures : the number of failures before the loop is stopped. If empty, the loop is never stopped
Examples
for.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Plan root"
    children:
    - for:
        start: 1
        end: 10
        inc: 1
        item: "counter"
        threads: 1
        children:
        - echo:
            text:
              expression: "\"Counter: ${counter}\""
Properties
  • Start : the initial value of the for loop
  • End : the final value of the for loop (exit condition)
Examples
// For - display counter value
For 1 to 10 
  // Echo - counter value
  Echo counter
End

Not yet documented.

While

The While control executes its children repeatedly as long as the specified condition is met. For each loop the children nodes are executed sequentially similarly to Sequence controls.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Condition : a groovy condition to be evaluated at the beginning of each iteration
  • Post Condition : a groovy condition to be evaluated at the end of each iteration
  • Pacing: : minimum execution time in ms for the node content to be executed as an Long
  • Timeout : stop the control execution after the defined value as a Long (serves as a security)
  • MaxIterations : stop th control execution after the define amount of iterations (serves as a security)
Examples
while.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

In the following example, the While control loops as long as the value of the variable counter remains below 5.

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Plan root"
    children:
    - set:
        key: "counter"
        value:
          expression: "0"
    - while:
        condition:
          expression: "counter < 5"
        children:
        - set:
            key: "counter"
            value:
              expression: "counter + 1"
        - echo:
            text:
              expression: "\"Counter: $counter\""
Properties
  • Condition : a groovy condition to be evaluated at the beginning of each iteration. Please mind the “|” surrounding the condition expression.
  • Post Condition : a groovy condition to be evaluated at the end of each iteration. Please mind the “|” surrounding the condition expression.
  • Pacing: : minimum execution time in ms for the node content to be executed as an Long
  • Timeout : stop the control execution after the defined value as a Long (serves as a security)
  • MaxIterations : stop the control execution after the define amount of iterations (serves as a security)
Examples
-
// While
While 
  Condition=|!"Hello World !".equals("Goodbye World !")|
  Pacing=1000l
  Timeout=5000l
  MaxIterations=5
-
// Echo - Hello World
Echo "Hello World"
End

Not yet documented.

Keyword calls

CallKeyword

The CallKeyword control allows to dynamically call a Keyword by attributes (name, etc). It is similar to calling a method using reflection in Java. The CallKeyword control is an advanced control. In most cases it is recommended to directly add Keywords to the Plan directly.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties

Same as in a regular Keyword call, but a name should be set in order to tell Step which Keyword needs to be called. Used in conjunction with groovy, this can provide a powerful mechanism for Keyword Call templating.

Examples
callkeyword.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

The following example shows how to use the CallKeyword control to call a Keyword by name. To test this example, first upload the Keyword package step-library-kw-http that declares the Keyword HttpRequest. Refer to Keyword deployment for instructions on deploying a Keyword package.

---
version: "1.0.0"
name: "Plan example"
root:
  sequence:
    nodeName: "Plan example"
    children:
    - callKeyword:
        keyword: "HttpRequest"
        inputs:
        - URL: "www.exense.ch"

In the following example, a Keyword is called dynamically based on the value of the variable keywordToCall which specifies the name of the Keyword to call.

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Plan root"
    children:
    - set:
        key: "keywordToCall"
        value: "HttpRequest"
    - callKeyword:
        keyword:
          name:
            expression: "keywordToCall"
Properties

Same as in a regular Keyword call, but a name should be set in order to tell Step which Keyword needs to be called. Used in conjunction with groovy, this can provide a powerful mechanism for Keyword Call templating.

Limitations

You can only have String variable using natural language (i.e boolean, numbers and date are not supported). You can however use the Groovy String interpolation to resolve variable value directly in a String. Application prefixed keywords syntax is supported as well as Application / Keyword having spaces in their name, thus the keyword call needs to be double-quoted when using plain text (see example below).

Examples
// CallKeyword - MyFirstKeyword
MyFirstKeyword location="Bern" date="01.07.2019" contact="${John Doe}"
// My Application -> My Second Keyword
"My Application.My Second Keyword"

Not yet documented.

Session

The Session control is a very important control in Step. It allows to group the execution of Keywords on the same agent token and thus to ensure that the Keywords would share the same Session. This is a very important feature for stateful keywords that share session objects. The Session controls executes its children sequentially like the Sequence control.

You may use keywords which will be executed on different token’s type (i.e. java, .net,…) in the same session control. This implies that one token per type will be reserved. Also, consider that sharing objects between keywords of different type is not supported.


  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Keyword routing : optional, for affinity patterns using selection criteria
Examples
session.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

In the following example, we assume that we have 2 stateful Keywords Login to MyApplication and Perform a specified action in MyApplication that share some session objects. The Session control ensures that these 2 Keywords are executed on the same agent token.

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Plan root"
    children:
    - session:
        children:
        - callKeyword:
            keyword: "Login to MyApplication"
        - callKeyword:
            keyword: "Perform a specified action in MyApplication"
Properties
  • Keyword routing : optional, for affinity patterns using selection criteria (see below example for usage)
Examples
// Session 
Session key1=value1 key2=value2
  // InitWebDriver - And put it into session
  InitWebDriver
  // NavigateToUrl - But first get the driver from session
  NavigateToUrl
End

Not yet documented.

Plan calls

CallPlan

Similarly to the CallKeyword control for Keywords, the CallPlan control allows to call another Plan dynamically by attributes (name, etc).

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • keys & values : the plan you want to invoke, as for Keywords and CallKeywords, CallPlan can be used for templating Plan executions.
Examples
callplan.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Plan root"
    children:
    - callPlan:
        nodeName: "Example plan"
        planId: "66bc5df58307a91fca497056"
Properties

The only property exposed at the moment is the plan name to be called, passing inputs is not supported in natural language yet.

Examples
-
// Call Plan - mySubPlan
Call plan "mySubPlan" 
-

Not yet documented.

PlaceHolder

The PlaceHolder control is an advanced control that allows to create Plan templates. In a Plan that should serve as a template, the Placeholder control can be added to define a placeholder that will be replaced by some other controls when the Plan template is called by another plan. Refer to the example below to understand how this work.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties

There is no specific property configurable for this control.

Examples

Main plan echoing the counter value while the for loop incrementing the counter is defined in a sub-plan as a placeholder :

placeholder-echo.png placeholder-plans.png

Execution results :

placeholder-execution.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

This control is not supported using natural language.

Not yet documented.

Functional Testing

TestCase

The TestCase control allows to define a functional test case. In terms of execution flow it works like a Sequence, in the sense that it executes its children sequentially and interrupts when an error occurs. In terms of reporting it enables different specific features:

  • TestCase execution results are reported in the Test cases overview of the execution report view
  • If more than a TestCase is available in a Plan, the reporting switches to the test set mode. In this mode the status distribution is grouped by TestCase and not Keyword

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties

Simply wrap your Test Plans with a test case

Examples
testcase.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

---
version: "1.0.0"
name: "Example plan"
root:
  testSet:
    nodeName: "Plan root"
    threads: 1
    children:
    - testCase:
        nodeName: "TestCase A"
        children:
        - echo:
            text: "Running TC A"
    - testCase:
        nodeName: "TestCase B"
        children:
        - echo:
            text: "Running TC A"
Properties

Simply wrap your Test Plans with a test case

Examples
 TestCase
// MyFirstKeyword
MyFirstKeyword location="Bern" date="01.07.2019" contact="${John Doe}"
End

Not yet documented.

TestSet

The TestSet control allows to define a set of TestCases. In terms of execution flow it executes its children (TestCases) in parallel according to the defined number of threads. In terms of reporting, it enables the test set mode which among other things reports the status distribution grouped by TestCase and not Keyword

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties

Simply wrap your TestCase’s with a TestSet controller, parallelism is derived from the global variable tec.execution.threads

Examples
testset.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

The following example shows how to define a test set that calls 2 test case plans by Id

---
version: "1.0.0"
name: "Example plan"
root:
  testSet:
    nodeName: "Plan root"
    threads: 1
    children:
    - callPlan:
        nodeName: "Call Test case A"
        planId: "66bc5df58307a91fca497056"
    - callPlan:
        nodeName: "Call Test case B"
        planId: "66bc5df58307a91fca497056"
Properties

Simply wrap your TestCase’s with a TestSet controller, parallelism is derived from the global variable tec.execution.threads

Examples
TestSet 
  TestCase
  // CallKeyword - MyFirstKeyword
  MyFirstKeyword location="Bern" date="01.07.2019" contact="${John Doe}"
  End
  TestCase
  // CallKeyword - MySecondKeyword
  MySecondKeyword 
  End
End

Not yet documented.

Load testing

ThreadGroup

The ThreadGroup control is an important control for the creation of load testing Plans. Basically it allows to repeatedly execute its child nodes in parallel according to the specified load parameters and for the specified duration or number of iterations.

To define the target load, the user can either specify a combination of number of threads and pacing OR the target throughput. When specifying the target load as a combination of number of threads and pacing, the ThreadGroup starts a fix number of threads, each one running the child sequence iteratively, waiting after each execution to keep the specified pacing as illustrated below.

  • Visual editor
  • YAML
  • Plain text
  • Java

Wizard

With the wizard the values for number of threads and iterations per thread can be easily calculated. It requires the following information:

  • Target throughput : the expected number of iterations produced over specified time during the execution
  • Estimated iteration durations max : the duration to execute one iteration under load, considering to keep sufficient margin. If the actual iteration time is higher during the execution, the target throughput will not be reached.

Properties (Advanced)

  • Number of threads : the number of threads to be started in parallel
  • Number of iterations per thread : the number of iteration each thread will perform
  • Pacing : defines the fix period of time that the ThreadGroup will try to keep between the start of each iteration. In combination with the number of threads, this allows to control the number of iterations per time unit (so that throughput remains independent of the actual duration of each iteration)
  • Rampup : defines the duration of the ramp-up i.e. the time that the ThreadGroup will take to start all the threads. If not set, the pacing value is taken as default rampu-up
  • Start offset : defines an optional offset of time before the ramp-up start
  • Maximum duration : the maximal execution time for the whole thread group

Examples

threadgroup.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following examples defines a ThreadGroup with 10 threads, 100 iterations per thread and a pacing of 500ms. It will execute the child nodes (Keyword 1 and Keyword 2) 100 times per thread

---
version: "1.0.0"
name: "Plan example"
root:
  threadGroup:
    nodeName: "Plan example"
    users: 10
    iterations: 100
    pacing: 500
    startOffset: 0
    maxDuration: 0
    children:
    - callKeyword:
        keyword: "Keyword 1"
    - callKeyword:
        keyword: "Keyword 2"

Properties

  • Threads : the number of threads to be started in parallel
  • Iterations : how many times the node content should be executed per thread
  • Pacing : defines a fixed time window in milliseconds, as an Integer, in order to better control the number of keywords executed per time unit (and so that throughput remains independent from keyword execution time)
  • Rampup : the ramp-up value is designed to be automatically divided by the number of threads to start them progressively and “spread” them out evenly, it represents the total duration of the ramp-up phase. If the ramp up value is left empty, then it will default to the pacing value (all threads will be spread out evenly but started “quickly”, i.e in one single pacing period).
  • Offset : the duration in ms to wait before the Rampup starts as an Integer
  • MaxDuration : the maximal execution time in ms for the whole thread group as an Integer

Examples 

-
// ThreadGroup
ThreadGroup 
  Threads=5
  Iterations=5
  Pacing=5000
  Rampup=1000
  Offset=100
  MaxDuration=25000
-
  // Echo - Hello World
  Echo "Hello World"
End

Not yet documented.

BeforeThread

This control has been replaced by the new Before Thread Section. The only exception is the plain text editor. (see: plain text exclusive controls)

AfterThread

This control has been replaced by the new After Thread Section. The only exception is the plain text editor. (see: plain text exclusive controls)

TestScenario

The control TestScenario allows to define complex load testing Plans made of multiple ThreadGroups. From an execution point of view, it simply executes all its children in parallel. Initially designed to group ThreadGroups or call to sub-plans of type ThreadGroup it can also be used to run any kind of node in parallel.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties

There is no special property for this control.

Examples
testscenario.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following examples defines a load test scenario with 2 thread groups:

---
version: "1.0.0"
name: "Example plan"
root:
  testScenario:
    nodeName: "Example plan"
    children:
    - threadGroup:
        users: 10
        iterations: 100
        children:
        - echo:
            text: "Running iteration from TG1"
    - threadGroup:
        users: 20
        iterations: 100
        children:
        - echo:
            text: "Running iteration from TG2"
Properties

There is no special property for this control.

Examples
TestScenario
  -
  // First ThreadGroup
  ThreadGroup 
  -
  // Echo - Hello World
  Echo "Hello World"
  End
  -
  // Second ThreadGroup 
  ThreadGroup
  -
  // Echo - Goodbye World
  Echo "Goodbye World"
  End
End

Not yet documented.

PerformanceAssert

Validates a measurement metric value (either generated by a Keyword or by a Custom measurement within a Keyword) against a specified value. This control can be placed in the “After”-section of any Keyword call (to validate a single keyword call generated measurements) or any kind of loop (to validate a measurement metric aggregation).

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Metric to assert : the measurement metric to check the value against.
  • Measurement name : the measurement name (can be a custom measurement).
  • Operator : the operator to use to compare the measurement metric against the specified value
  • Value: the value to compare the measurement metric against

Available metrics to assert are :

  • average : the average response time of the selected measurement
  • min : the minimal response time of the selected measurement
  • max : the maximal response time of the selected measurement
  • sum : the sum of the response time of the selected measurement
  • count : the number of time the selected measurement has been generated

Available operator values are :

  • equals : asserts true if the selected measurement metrics value is equals to the defined value
  • lower than : asserts true if the selected measurement metrics value is lower than the defined value
  • higher than : asserts true if the selected measurement metrics value is higher than the defined value
Unitary example

In the below example, the PerformanceAssert validates that the average response time of the “testKeyword” execution is lower than 3000 ms.

performanceAssert.png
Count example

In the below example, the PerformanceAssert validates that the “testKeyword” has been executed exactly 10 times.

performanceAssertCount.png
Agreggation example

In the below example, the PerformanceAssert validates that the aggregation done on the average response time of the “testKeyword” over the 10 loop iterations is lower than 3000 ms.

performanceAssertAggregation.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following example defines a ThreadGroup that runs 10 VUs (threads) in parallel and asserts that the average duraiton of the Keyword call “HelloWorld” is below 500ms

---
version: 1.0.0
name: "Load testing plan with PerformanceAssert"
plans:
  - name: "Demo load test"
    root:
      threadGroup:
        # Run the sequence with 10 VUs
        users: 10
        # Perform 10 iterations per user
        iterations: 10
        children:
          # Call the keyword HelloWorld
          - sequence:
              children:
              - callKeyword:
                  keyword: "HelloWorld"
          # Assert that the response time of the measure 'HelloWorld' is below 500m
          - performanceAssert:
              measurementName: "HelloWorld"
              comparator: "LOWER_THAN"
              expectedValue: 500
Properties
  • Metric (Optional): specifies the metric to be asserted
    • Type: String
    • Supported values: “Average”, “Max”, “Min”, “Count”, “Sum”
    • Default value: If not set the “Average” metric is used per default
  • Measurement : specifies the name of the measurement to be asserted. This could be a regex matching several measurements. In this case all measurements will be grouped by name and each group will be asserted individually
    • Type: String
    • Supported values: any
  • Comparator (Optional): the comparator to be used to compare the actual value with the expected value
    • Type: String
    • Supported values: “equals to”, “higher than”, “lower than”
    • Default value: If not set, “lower than” is used per default
  • Value : the expected value in ms
    • Type: Number
Examples

Example 1:

For 1 to 10
  MyFirstKeyword
  MySecondKeyword
End
// Assert that the average response time of the Keyword 'MyFirstKeyword' is lower than 100ms
PerformanceAssert Metric = "Average" Measurement = "MyFirstKeyword" Comparator = "lower than" Value = 100

Example 2:

For 1 to 10
MyFirstKeyword
MySecondKeyword
End
// Assert that the average response time of the 2 Keywords 'MyFirstKeyword' is lower than 500ms
PerformanceAssert Measurement = ".*" Value = 500

Not yet documented.

Synthetic Monitoring

AssertionPlan

Assertion Plans are a special type of plans that can be associated to schedules. Their purpose is to evaluate the success of schedule over a series of executions. When a schedule uses an assertion plans, the events ScheduledExecutionEndedEvent are enriched by the results of the assertion which can be used for incident and alerting management.

Typically, an assertion plan consists of one or more AssertMetric controls that specify the assertions to be evaluated on metrics produced by the executions of the associated schedule. The evaluation is performed after each execution triggered by the schedule. An AssertMetric can be used for example to ensure that no more than 2 executions failed within a 1-hour rolling window.

Note: AssertionPlan must be selected as root of the plan type.

AssertMetric

This control defines a metric-based assertion that can be used within an Assertion Plan.

  • Visual editor
  • YAML
  • Plain text
  • Java

The assert metric control is defined by following properties

  • Metric available metrics for the assertion:
    • Execution count: count of execution
    • Execution failure percentage
    • Execution failure count
    • Execution failure count by error code
    • Response times
  • Filters: add custom filters (for instance filter on a specific measurement name for Response times metrics)
  • Rolling window: specify the time frame to be used when querying the metrics as a rolling window
    • The window starts from the end of the execution triggering the evaluation of the Assertion Plan
    • Per execution metrics, such as execution count and execution failures count, are ingested with the execution start time, therefore the windows must be at least larger than the execution duration
    • Using very small windows (i.e. close to the time series resolution which is by default 5 seconds) may give unpredictable results
  • Time series aggregation: define which aggregator to use (i.e. average, min, max, sum, percentiles…)
  • Time series group by (optional): to aggregate and assert grouping by specified attributes
  • Comparator: used for the assertion, can be either below, above or matching threshold
  • Threshold value: The values compared to aggregation result using selected comparator
  • Error code: defien the code of the error that will be raised if the assertion fails

In below example, we assert that the number of failed executions in the last hour remains below 2:

AssertMetric.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following example shows how to define an assertion plan in YAML that asserts that the executions of a schedule did not fail more than once in the last 10 minutes

version: 1.0.0
name: "Assertion plan example"
plans:
  - name: "Opencart schedule assertion plan"
    root:
      assertionPlan:
        description: "Assert the scheduled executions did not fail more than once in the last 10 minutes"
        children:
          - assertMetric:
              description: "Make sure executions did not fail more than once in the last 10 minutes"
              comparator: LOWER_THAN
              aggregation: SUM
              expectedValue: 2
              slidingWindow: 600000
              metric: "executions/failure-count"

Not yet documented.

Not yet documented.

Data driven controls

DataSet

This controls enables the use of different kind of data sources (CSV, Excel, SQL table, etc) within a Plan. Contrary to the ForEach control which is meant for data driven execution of functional tests or RPA; the DataSet control can be used with more flexibility and is particularely well adapted for load testing using Thread Group.

Technically the DataSet control declares a variable that exposes the API to access the data contained in its data source. The API of the DataSet supports following operations:

  • dataSet.next(): returns the next row of the data source. The row object itself is a Map (key-value pair) of column names and their values.
  • dataSet.nextChunk(n).asJson(): returns a JSON array containing the next n rows of the data source

To use a DataSet in a Plan you need to:

  • Declare your dataset by adding and configuring it in your plan. The property Iterator handle define the variable to access your datasource (the default name is dataSet)
  • Access row and columns values using the API. Example: dataSet.next().MyColumn1
  • Visual editor
  • YAML
  • Plain text
  • Java

Common Properties

  • Source type : define the source type object. Values could be : Excel, CSV, SQL, Flat file, Directory, Integer sequence, Json String, Google Sheet V4
  • For write : define if the data source will be used to insert values
  • Iterator handle : define a variable pointing to the dataset’s iterator
    • Rows can then be iterated and accessed with the groovy expression iteratorName.next(), see our example.
  • Reset at end : define if once arrived at the end of the data source, the iterator handle should be reinitialized to the first row

Example - using DataSet in load testing plans

While designing load testing plans it is a common need to run a workflows with a set of data, picking up different rows across threads and iterations.. To run a workflow in parallel, Step provides the control ThreadGroup. Using ThreadGroup and DataSet in combination enables the execution of a workflow in parallel with different data.

dataset-uc-threadgroup.png

You can directly import this sample plan in Step

Excel properties

  • Excel file : the path to your source file
  • Worksheet : the worksheet name in your source file (if blank, the first one in your sheet will be selected)
  • Headers : check this box if your columns have header

CSV properties

  • CSV file : the path to your source file
  • Delimiter : the delimiter used in your CSV file
Example
dataset-csv.png

SQL properties

  • Connection string : the string used to connect to your database. For example, using jdbc to connect to a MySQL database on localhost : “jdbc:mysql://localhost:3306/dbname”
  • Driver class : the driver full class name. For example, using jdbc for MySQL : “com.mysql.jdbc.Driver”
  • Query : the SQL query to perform against your database to retrieve the data
  • User : the username to connect to your database
  • Password : the password to connect to your database. If you want to store your password in a Parameter and thus also protect it, you can use following syntax: “parameter:MyParameterName”. Example: if your password is store in a parameter called “datasource.sql.password”, you can refer to is as follow: “parameter:datasource.sql.password”
  • Primary write key : the primary key to use in case you want to write back to your database

Flat file properties

  • Flat file : the path to your source file

Directory properties

  • Directory : the path to your directory

Integer sequence properties

  • Start : value starting the sequence
  • End : value ending the sequence
  • Inc : increment value for the sequence

Json String properties

  • Json string : the JSON document representing your data. The document has to represent of table of values with headers first, and then rows. For example :
{ "pagename" :
    ["Consulting", "Products"],
  "url" : 
    ["https://www.exense.ch/solutions",
      "https://www.exense.ch/products"]}

Google Sheet V4 properties

  • Service Account Key File : the path to your service account key file. Refer to Google documentation about service account key file creation.
  • File Id : the Google Cloud unique identifier of your file. It can usually be extracted from the URL locating your file in the Cloud.
  • Tab Name : the name of the tab to use in your source file (if blank, the first one in your file will be selected)

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following example shows how to use a DataSet in combination with a ThreadGroup. In this example the dataSet uses a Json as source and is reset when the end of the data is reached. The DataSet is used within the ThreadGroup. In each iteration the method next() of the DataSet is called to move to the next line.

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Example plan"
    children:
    - dataSet:
        item: "dataSet"
        resetAtEnd: true
        dataSource:
          json-array:
            forWrite: false
            json: "[{\"Username\":\"User1\"},{\"Username\":\"User2\"}]"
    - threadGroup:
        users: 1
        iterations: 10
        children:
        - echo:
            text:
              expression: "'Username: ' + dataSet.next().Username"
    continueOnError: false

Common Properties

  • SourceType : define the source type object. Values could be : excel, csv, file (for Flat file) or folder (for Directory). Other source type are not supported yet.
  • File : the path to your source file
  • ForWrite : define if the data source will be used to insert values
  • IteratorHandle : define a variable pointing to the dataset’s iterator
  • ResetAtEnd : define if once arrived at the end of the data source, the iterator handle should be reinitialized to the first row

Excel Properties

There is no specific property configurable for Excel sheet in natural language.

Examples 

-
// DataSet - from Excel sheet
DataSet 
  SourceType = "excel"
  File = "myFile.xlsx"
  IteratorHandle = "myRows"
  ForWrite = true
  ResetAtEnd = true
-

CSV properties

There is no specific property configurable for CSV file in natural language.

Warning: Writing to a CSV file from a dataset is not supported

Examples 

-
// DataSet - from CSV file
DataSet 
  SourceType = "csv"
  File = "myFile.csv"
  IteratorHandle = "myRows"
  ForWrite = true
  ResetAtEnd = true
-

File properties

There is no special property for “File” type in natural language.

Examples 

-
// DataSet - from Flat file
DataSet 
  SourceType = "file" 
  File = "myFile.txt"
  IteratorHandle = "myRows"
  ForWrite = true
  ResetAtEnd = true
-

Folder properties

There is no special property for “Folder” type in natural language.

Examples 

-
// DataSet - from Directory
DataSet 
  SourceType = "folder"
  File = "/myFolder"
  IteratorHandle = "myRows"
  ForWrite = true 
  ResetAtEnd = true 
-

Not yet documented.

ForEach

The ForEach control allows to iterate over a data source and perform operations for each row of the data source. For each row of the data source, the child nodes of the ForEach are execute in sequence as the Sequence control does.

Parallelism

ForEach support parallel processing which means that more than one thread can be configured to process the data source. Each thread picks up the next line of the data source and runs the child nodes. Regardless of the parallelism, the ThreadGroup guaranties to process each row of the data source only once.

Data source types

The ForEach supports a wide range of data source types:

  • Excel: Iterates over each row of an Excel worksheet. Excel features are fully supported. This also includes formula evaluation.
  • CSV: Iterates over each row of a CSV file. The first line of the CSV is expected to contain headers.
  • SQL: Iterates over each row of a SQL table
  • Flat file: When using flat files as data source, the ForEach iterates over each row of a file. In this case only one column
  • Directory: When using directories, the ForEach control iterates over all files of the directory. The value of each row corresponds to the absolute path of each file contained in the directory
  • Integer sequence: When using an integer sequence, the ForEach iterates over a configured integer sequence as the For control would do
  • Json array: In this case the ForEach iterates over each entry of a configured Json
  • Google Sheet V4: In this the ForEach iterates over each row of a Google Sheet worksheet

  • Visual editor
  • YAML
  • Plain text
  • Java
Common Properties
  • Source type : define the source type object. Values could be : Excel, CSV, SQL, Flat file, Directory, Integer sequence, Json String, Google Sheet V4
  • Number of threads : the number of threads to use in order to parallelize the loop (i.e the execution of the children)
  • Maximum number of failures : the number of failures before the loop is stopped. If empty, the loop is never stopped
  • Row handle : define a variable pointing to the current row
Excel properties
  • Excel file : the path to your source file
  • Worksheet : the worksheet name in your source file (if blank, the first one in your sheet will be selected)
  • Headers : check this box if your columns have header
Example
foreach-excel.png
CSV properties
  • CSV file : the path to your source file
  • Delimiter : the delimiter used in your CSV file
Example
foreach-csv.png
SQL properties
  • Connection string : the string used to connect to your database. For example, using jdbc to connect to a MySQL database on localhost : “jdbc:mysql://localhost:3306/dbname”
  • Driver class : the driver full class name. For example, using jdbc for MySQL : “com.mysql.jdbc.Driver”
  • Query : the SQL query to perform against your database to retrieve the data
  • User : the username to connect to your database
  • Password : the password to connect to your database
  • Primary write key : the primary key to use in case you want to write back to your database
Flat file properties
  • Flat file : the path to your source file
Directory properties
  • Directory : the path to your directory
Integer sequence properties
  • Start : value starting the sequence
  • End : value ending the sequence
  • Inc : increment value for the sequence
Json array properties
  • Json : the JSON document representing your data. The document has to be an array of objects:
[{
		"name": "Dave Null",
		"age": 29,
		"profession": "SysAdmin"
	}, {
		"name": "Seg Fault",
		"age": 54,
		"profession": "Developer"
	}
]

You will then be able to use the Row handle variable as a Json object by, for example, accessing the name and age with row.name and row.age

Example
foreach-json.png
Google Sheet V4 properties
  • Service Account Key File : the path to your service account key file. Refer to Google documentation about service account key file creation.
  • File Id : the Google Cloud unique identifier of your file. It can usually be extracted from the URL locating your file in the Cloud.
  • Tab Name : the name of the tab to use in your source file (if blank, the first one in your file will be selected)
Json String (Legacy) properties
  • Json string : the JSON document representing your data. The document has to represent of table of values with headers first, and then rows. For example :
{ "pagename" :
    ["Consulting", "Products"],
  "url" : 
    ["https://www.exense.ch/solutions",
      "https://www.exense.ch/products"]}

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Example

The following example shows how to define a Plan that iterates over all lines of a CSV file delimited by ‘,’ and echo the value of the column “Column1” (the first row of the CSV is expected to contain the headers and thus one column with the text “Column 1”)

---
version: "1.0.0"
name: "Example plan"
root:
sequence:
  nodeName: "Example plan"
  children:
  - forEach:
      dataSource:
        csv:
          file:
            id: "/path/to/file.csv"
          delimiter: ","
      item: "row"
      threads: 1
      children:
      - echo:
          text:
            expression: "row.Column1"
Common Properties
  • SourceType : define the source type object. Values could be : excel, csv, file (for Flat file) or folder (for Directory). Other source type are not supported yet.
  • File : the path to your source file
  • Threads : the number of threads to use in order to parallelize the loop (i.e the execution of the children)
  • RowHandle : define a variable pointing to the current row
  • MaxFailedLoop : the number of failures before the loop is stopped. If not set, the loop is never stopped
Excel Properties
  • Worksheet : the worksheet name in your source file (if blank, the first one in your sheet will be selected)
Examples
-
// ForEach - row in excel sheet
ForEach 
  SourceType = "excel"
  File = "C:/myFile.xlsx"
  Worksheet = "myWorksheet" 
  Threads = 1 
  RowHandle = "myRow"
  MaxFailedLoop = 2
-
  Echo myRow.myColumn
End
CSV properties
  • Delimiter : the delimiter used in your CSV file
Examples
-
// ForEach - row in file
ForEach 
  SourceType = "csv"
  File = "/home/myFile.csv"
  Delimiter = ";"
  Threads = 2 
  RowHandle = "myRow"
-
  Echo myRow.myColumn
End
File properties

There is no special property for “File” type in natural language.

Examples
-
// ForEach - row in file
ForEach 
  SourceType = "file"
  File = "C:/myFile.txt"
  Threads = 2 
  RowHandle = "myRow"
-
  Echo myRow.myColumn
End
Folder properties

There is no special property for “Folder” type in natural language.

Examples
-
// ForEach - file in folder
ForEach 
  SourceType = "folder"
  File = "/myFolder"
  Threads = 2 
  RowHandle = "myRow"
-
  Echo myRow.myColumn
End

Not yet documented.

Asynchronous Testing

RetryIfFails

The Retry control executes its child nodes in sequence as a Sequence control does. However, if an error occurs in one of the nodes, all the child nodes a re-executed and this until all child nodes are passing.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Max retries : number of retries if child nodes execution fails
  • Grace period (ms) : duration to wait in ms after a failed attempt
  • Timeout : maximum execution time in ms for the whole execution retries
  • Advanced :
  • Release Tokens : release tokens reserved in current session (details)
  • Report only last iteration: when enabled, only the final iteration will be reported and persisted
Examples
retryiffails.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

The following example shows how to use the RetryIfFails to rerun a Keyword until its status is PASSED. In this example the RetryIfFails will try to re-execute the Keyword 2 times maximum and wait 1000ms after each retry.

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Example plan"
    children:
    - retryIfFails:
        children:
        - callKeyword:
            keyword: "DummyKeyword"
        maxRetries: 2
        gracePeriod: 1000
        timeout: 0
        releaseTokens: false
        reportLastTryOnly: false
Properties
  • MaxRetries : number of retries if child nodes execution fails
  • GracePeriod : duration to wait in ms after a failed attempt
  • Timeout : maximum execution time in ms for the whole execution retries
  • ReleaseTokens: (optional, default is false) release tokens reserved in current session (details)
  • ReportLastTryOnly: (optional, default is false) when enabled, only the final iteration will be reported and persisted
Examples
RetryIfFails MaxRetries=3 GracePeriod=5000 Timeout=30000
// CallKeyword - MyFirstKeyword
MyFirstKeyword location="Bern" date="01.07.2019" contact="${John Doe}"
End

//Same example with all properties
RetryIfFails MaxRetries=3 GracePeriod=5000 Timeout=30000 ReportLastTryOnly=true ReleaseTokens=true
// CallKeyword - MyFirstKeyword
MyFirstKeyword location="Bern" date="01.07.2019" contact="${John Doe}"
End

Not yet documented.

WaitForEvent

Wait for a specific event to be received by the controller. Refer to Event broker API to learn more about the Event broker and how to send events.

Event can be identified by an eventId or a couple group/name. By default, this control will listen to the local Step controller but a remote one can be specified in its remote properties.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties
  • Event selection criteria: either select event by id or by group and name (name is optional)
  • Event Id: the ID of the event to wait for
  • Event Group: the event group to wait for
  • Event Name: the event name to wait for
  • Polling settings : adapt the polling frequency and control optionally the maximum wait time
  • Polling frequency (ms): the interval to poll the event broker in ms as a Long
  • Max number of polling: stop waiting for the event after the define amount of iterations (serves as a security)
  • Maximum wait time (ms): stop waiting to the event after the defined value as a Long (serves as a security)
  • Remote broker settings: to be used when the events are not stored in the local controller
  • Remote URL: the Step remote controller URL where to listen to an incoming event
  • Remote User: the Step remote controller username to use for connection
  • Remote Password: the Step remote controller password to use for connection
  • Advanced:
  • Release Tokens: release tokens reserved in current session (details)
Examples
waitforevent.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following example shows how to use the WaitForEvent in a YAML Plan to wait for an event with the Id ‘myEvent1’ and perform an action upon event reception:

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Example plan"
    children:
    - waitForEvent:
        children:
        - echo:
            text: "Received event 1"
        eventId: "myEvent1"
        pollingSpeed: 500
        timeout: 0
        maxIterations: 0
        releaseTokens: false
Properties
  • EventId: the ID of the event to wait for
  • Group: the event group to wait for
  • Name : the event name to wait for
  • PollingSpeed : the interval to poll the event broker looking for the event in ms as a Long
  • Timeout : stop waiting to the event after the defined value as a Long (serves as a security)
  • MaxIterations : stop waiting for the event after the define amount of iterations (serves as a security)
  • ReleaseTokens: (optional, default is false) release tokens reserved in current session (details)
Examples
-
WaitForEvent 
  Group="eventGroup"  
  Name="eventName" 
  PollingSpeed=1000l 
  Timeout=5000l 
  MaxIterations=5
-
// Set - myEvent
Set myEvent=report.getEvent()
// Echo - myEvent
Echo myEvent

Not yet documented.

You will find more details on the event broker API and how to effectively use the “WaitForEvent” artefact here.

Composite Keywords

Return

The Return control allows to return a Keyword output within a Composite Keyword.

  • Visual editor
  • YAML
  • Plain text
  • Java
Properties

No property. Just enter key values as you’d like them to be available in the output of a regular keyword.

Examples
return.png

The YAML syntax of Plan controls follows the schema documented on the Automation package descriptor page.

Examples

Following example shows how to return an output within the Plan of a Keyword composite. In this example an output with the key/value pair “output1” = “Output 1” would be returned:

---
version: "1.0.0"
name: "Example plan"
root:
  sequence:
    nodeName: "Example plan"
    children:
    - set:
        key: "myOutput"
        value: "Output 1"
    - return:
        output:
        - output1:
            expression: "myOutput"
Note

This control is not available as natural language as Composite Keywords cannot be created using natural language yet.

Not yet documented.

Plain text exclusive controls

BeforeSequence

This control has been replaced by the new Before Section except for the plain text syntax.

The control BeforeSequence allows to define initialization tasks within Sequence-like controls. When added to a Sequence or any control running its children sequentially, it will ensure that its content is executed before the Sequence starts. This can be useful in combination with a For / While loop which have an implicit sequence for each iteration.

In case of multi-threaded executions you also have the possibility to execute an init sequence once and only once before each thread starts (see beforethread).

  • Plain text
Properties
  • Continue sequence execution on error : specify if the sequence should continue until its end if an error occurred within
  • Pacing : minimum execution time for the whole sequence to be executed (in milliseconds) as a Long
Examples
//Set - declare myMessage variable
Set myMessage=''
Sequence
  BeforeSequence
    //Set - init myMessage once
    Set myMessage="Hello World"
  End
  //Echo - myMessage
  Echo myMessage 
End

AfterSequence

This control has been replaced by the new Before Section except for the plain text syntax.

Used to perform clean-up / final tasks inside a Sequence, i.e the content withing the AfterSequence control will be executed only once after the Sequence ends. Useful in combination with a For / While loop.

In case of multi-threaded executions you also have the possibility to execute an after sequence once and only once after each thread terminates (see afterthread).

  • Plain text
Properties
  • Continue sequence execution on error : specify if the sequence should continue until its end if an error occurred within
  • Pacing : minimum execution time for the whole sequence to be executed (in milliseconds) as a Long
Examples
//Set - declare myMessage variable
Set myMessage=''
Sequence
  BeforeSequence
    //Set - init myMessage once
    Set myMessage="Hello World"
  End
  //Echo - myMessage
  Echo myMessage
  //AfterSequence - cleanup myMessage variable
  AfterSequence
    //Set - empty myMessage
    Set myMessage=""
  End
End

BeforeThread

This control has been replaced by the new Before Section except for the plain text syntax.

Used to perform initialization inside a ThreadGroup, i.e the content withing the BeforeThread control will be executed only once per thread in the ThreadGroup, before the iterations start (so not on every thread iteration).

To define an init section for each and every iteration refer to beforesequence.

  • Plain text
Properties
  • Continue sequence execution on error : specify if the sequence should continue until its end if an error occurred within
  • Pacing : minimum execution time for the whole sequence to be executed (in milliseconds) as a Long
Examples
//Set - declare myMessage variable
Set myMessage=''
// ThreadGroup
ThreadGroup Threads=2 Iterations=2
  BeforeThread
    //Set - init myMessage once
    Set myMessage="Hello World"
  End
  //Echo - myMessage
  Echo myMessage
End

AfterThread

This control has been replaced by the new Before Section except for the plain text syntax.

Used to perform clean-up / final tasks inside a ThreadGroup, i.e the content withing the AfterThread control will be executed only once per thread in the ThreadGroup, after the iterations end (so not on every thread iteration).

To define an end section for each and every iteration refer to aftersequence.

  • Plain text
Properties
  • Continue sequence execution on error : specify if the sequence should continue until its end if an error occurred within
  • Pacing : minimum execution time for the whole sequence to be executed (in milliseconds) as a Long
Examples
//Set - declare myMessage variable
Set myMessage=''
// ThreadGroup
ThreadGroup Threads=2 Iterations=2
  BeforeThread
    //Set - init myMessage once
    Set myMessage="Hello World"
  End
  //Echo - myMessage
  Echo myMessage
  //AfterThread - cleanup myMessage variable
  AfterThread
    //Set - empty myMessage
    Set myMessage=""
  End
End

Advanced control options

Release Tokens

This advanced option is currently available on controls entering a waiting state, namely:

The option only has an effect when executed inside a session control and must be used with caution. Its main purpose is to release the agent tokens currently reserved by the session when entering an idle state.

See Also