Logical actions

Logical actions can be inserted in a User Path in two ways:

drag and drop the Action from the Actions panel to the desired location in the User Path tree
select the desired location in the User Path tree to insert the item, right-click and according to the selected location, select Insert as child or Insert after

Delay

The Delay action pauses the Virtual User for a specified duration. The delay is expressed in milliseconds and may be set as a NeoLoad variable (useful for random delays).

Name: This is the name of the Action. In this case, the default name is "Delay".

Description: The Action behavior can be described in this field.

Delay: The time, in milliseconds, to apply the Delay can be specified in this field. A click on the Variable picker button allows setting a NeoLoad variable to the Delay.

Delay from: The time to apply to the Delay can be set as a range between two values in milliseconds.

Consider as think time: Ticking the check box allows defining the Delay as a think time. In this case, the Delay is not taken into account for calculating the response time of the parent containers.

Note: Each time a new Delay Action is created, it is considered as a think time by default.

Set global think time for all User Path pages and delays: A click on the link allows assigning the same think time for all the Pages and Delays of the User Path. A click on the link redirects you to the User Path runtime parameters section. For more information, see Virtual User runtime parameters.

Loop

The Loop action is used to iterate various items such as pages, the number of iterations being defined by the user. This number may be a variable, in which case the variable will be evaluated once only, before the first iteration.

A variable named <MyLoopName>_counter is created within the loop containing the current iteration number. This value starts at 1, for the first iteration, and is incremented by 1 at each next iteration.

Note: Loop-type logical actions may be shared among several User Paths. For more information, see Shared Containers.

While

The While action allows various items, such as web pages, to be iterated while a condition remains true, stopping once the condition is false and continuing with the rest of the User Path. A condition is composed of two operands and an operator. The operators are:

Equals- true if the 2 operands have the same value
Doesn't equal - true if the 2 operands do not have the same value
Contains - true if operand1 contains operand2
Doesn't contain - true if operand1 does not contain operand2
Starts with - true if operand1 begins with operand2, including if the 2 operands are equal.
Doesn't start with - true if operand1 does not begin with operand2.
Ends with - true if operand1 ends with operand2, including if the 2 operands are equal.
Doesn't end with - true if operand1 does not end with operand2.
Matches regexp - true if operand1 verifies the regular expression of operand2.
Doesn't match regexp - true if operand1 does not verify the regular expression of operand2.
Greater than -true if operand1 is greater than operand2.
Greater than or equal to - true if operand1 is greater than or equal to operand2.
Less than - true if operand1 is less than operand2.
Less than or equal to - true if operand1 is less than or equal to operand2.
Exists - true if operand1 corresponds to a name of a variable whose value is not nil. Operand2 cannot be defined.
Doesn't exist - true if operand1 does not correspond to a variable name or if operand1 corresponds to a variable name with a nil value. Operand2 cannot be defined.

Each operand may be a variable ${VariableName} or a static string. In the case of the Exists operator, operand1 can only be a VariableName variable name.

Several conditions may be used within a While action. To add a condition, simply click on the + button below the table of conditions. You must then specify whether the action is executed if all the conditions are true (Resolve all the following items), or if at least one of them is true (Resolve one of the following items).

Note: While-type logical actions may be shared among several User Paths. For more information, see Shared Containers.

If ... Then ... Else

The If ... Then ... Else action is used to execute conditional actions. When creating a conditional action, two Containers are created, Then and Else. If the condition is true, the actions in the Then Container are executed; If false, the actions in the Else Container are executed. A condition is composed of two operands and an operator. The operators are:

Equals - true if the 2 operands have the same value
Doesn't equal - true if the 2 operands do not have the same value
Contains - true if operand1 contains operand2
Doesn't contain - true if operand1 does not contain operand2
Starts with - true if operand1 begins with operand2, including if the 2 operands are equal.
Doesn't start with - true if operand1 does not begin with operand2.
Ends with - true if operand1 ends with operand2, including if the 2 operands are equal.
Doesn't end with - true if operand1 does not end with operand2.
Matches regexp - true if operand1 verifies the regular expression of operand2.
Doesn't match regexp - true if operand1 does not verify the regular expression of operand2.
Greater than -true if operand1 is greater than operand2.
Greater than or equal to - true if operand1 is greater than or equal to operand2.
Less than - true if operand1 is less than operand2.
Less than or equal to - true if operand1 is less than or equal to operand2.
Exists - true if operand1 corresponds to a name of a variable whose value is not nil. Operand2 cannot be defined.
Doesn't exist - true if operand1 does not correspond to a variable name or if operand1 corresponds to a variable name with a nil value. Operand2 cannot be defined.

Each operand may be a variable ${VariableName} or a static string. In the case of the Exists operator, operand1 can only be a VariableName variable name.

Several conditions may be used within an If ... Then ... Else action. To add a condition, simply click on the + button below the table of conditions. You must then specify whether the action is executed if all the conditions are true (Resolve all the following items), or if at least one of them is true (Resolve one of the following items).

Switch

The Switch action is used to execute conditional actions based on a selection control mechanism. It allows the Switch value to change the control flow of the User Path execution via a multiway branch, named Case statements.

Note: The Switch action is composed of one or several Case statements that are executed based on a defined value, and a Default statement that is executed if no other Case statement is matched.

The Switch action is fall-through, which means that if a Break flag is disabled on a Case, then the next Case statement is executed.

Switch value

The Switch value is defined on the Switch logical action node. It may be a variable ${VariableName} or a static string.

Case statement

Case statements are children of the Switch. They are executed based on a case value defined on the Case Statement node. The case value must be a static string (cannot be a variable). The test is based on a equality of the string values.

Case statements can be added, moved, removed, disabled within the Switch.

Each case statement has a Break flag, that allows to stop the Switch execution when the case value matches the Switch condition. If the Break option is disabled, then the Switch execution will continue the evaluation of next Case statement.

Note: Within the same Switch, it is not allowed to have two case statements with the same value.

Default statement

Default statement is static, it is the last statement of the Switch, and cannot be moved/deleted/disabled.

Examples

For example, let’s consider we have a Switch defined with value ${pageNumber}:

If variable is evaluated to 1, then only page1 is executed
If variable is evaluated to 2, then only page2 is executed
If variable is evaluated to 3, then only page3 is executed
If variable is evaluated to a different value than above, then only page4 is executed

However, when the Break flag is disabled on the Case statements, then all Case statements are executed after a first match:

If variable is evaluated to 1, then page1, page2, page3 and page4 are executed
If variable is evaluated to 2, then page2, page3 and page4 are executed
If variable is evaluated to 3, then page3 and page4 are executed
If variable is evaluated to a different value than above, then only page4 is executed

Variable modifier

A Variable Modifier action makes it possible to change the value of a variable separately from its value changing policy. For example, the value of a variable may be modified in a loop for a User Path.

It is necessary to specify the name of the variable on which the action must be applied, for example myVar, but not the expression such as ${myVar}. However, the variable name may be composed, for example ${data_for_${login}} for the variable data_for_jsmith.

Predefined variable: This option makes it possible to:

Re-initialize variable value to reset a predefined variable (reset to first value) or delete a variable issued by a variable extractor, or
Modify value to change the value of a predefined variable ((take next value).

Shared queue: The option allows adding or consuming a value in a shared queue. For more information, see Shared queues.

Transaction

The Transaction action is used to group together certain actions, namely those relating to a business transaction, in order to extract statistics. In the Results, a Transaction is dealt with in exactly the same way as other actions (pages, requests) and it provides the same statistics, for example average times, requests/s, and so on.

You can configure the way a Transaction executes the elements it contains with the following options:

Play all elements sequentially: All the Transaction elements are played in the order they were declared.
Play all elements randomly: All the Transaction elements are played once in random order.

When the Advanced mode is selected, you can configure each element to repeat a number of times. By default, each element has a repetition value of 1. A counter showing the number of repetitions configured for the element is shown next to the element in the User Path tree.

Play X number of elements randomly: X element(s) in the Transaction are selected and played in random order. All Transaction elements have the same probability of being selected.

When the Advanced mode is selected, you can configure the probability of each element being played randomly. This probability is proportional to the weighting given to the element. The more heavy the weighting, the more likely the element is to be selected. By default, all elements have the same probability weighting of 1. The percentage of probability of the element being selected is shown next to the element in the User Path tree.

You may configure the pacing of a Transaction. The pacing is the minimum time for the Transaction to be executed. If the Transaction is executed in less time than the pacing time, the Virtual User will pause until the pacing times out before continuing the scenario.

For example, if a Transaction has a pacing time of 30 seconds and during runtime the actual time taken to execute all the actions in the Transaction is 20 seconds, the Virtual User will pause for 10 seconds before resuming. However, if the actual time taken is 45 seconds, the User Path will continue without pausing.

Note: Transaction-type logical actions may be shared among several User Paths. For more information, see Shared Containers.

A service level agreement profile can be linked to a Transaction by clicking on the Apply SLA button. For more information, see Apply a Service Level Agreement profile.

A click on the Advanced button allows defining the variables to store for raw data export.

Note: For more details, see Exporting contextualized RAW data.

Variables can be entered manually in the field or by clicking the button on the right opening the Variable picker dialog box.

You may also set a global validation for all the requests contained in a Transaction, allowing quickly setting common application validation rules for several requests. For more information, see Global validation.

Try ... Catch

The Try...Catch action is used to execute specific actions in the case of an error or validation failure. A Try...Catch action can capture errors or assertions (validation errors) or both.

When creating a Try...Catch action, two Containers are created: Try and Catch. All actions in the Try Container are executed until an error or assertion occurs (depending on the action configuration). When an error or assertion occurs, the actions in the Catch Container are executed.

Note: Within a Try Container, the User Path will not be halted upon the error or assertion occurrence, even if it is configured so to do, as described in Error handling.

Go to next iteration

The Go to next iteration action interrupts the Virtual User runtime and makes it go to the next iteration. The way this action behaves depends on where it is placed within the Virtual User:

Placed in an Init Container: The Virtual User interrupts its initialization and starts its first iteration by running the Actions Container;
Placed in an Actions Container: The Virtual User interrupts its current iteration and runs (depending on the load policy):
- a new iteration by running the Actions Container;
- its End Container.

Placed in an End Container: There is no interruption; the Virtual User continues to run its End Container and an error message is written to the log files.

The Go to next iteration logical action can be particularly useful in combination with an If ... Then ... Else or Try...Catch action. For example, you can:

avoid running the Init Container for a Virtual User that is already logged on to the application;
re-start a Virtual User iteration if an error occurs.

Stop

The Stop action interrupts the Virtual User runtime. The Stop action can be configured to either start a new Virtual User with the same User Path to maintain the load or to do nothing after the stop. The newly created Virtual User starts its lifecycle from its Init Container.

The way this action behaves depends on where it is placed within the User Path:

In an Init Container or Actions Container, the Virtual User interrupts its current action and runs its End Container.
In an End Container, the Virtual User stops immediately.

The Stop logical action can be particularly useful in combination with an If ... Then ... Else or Try...Catch action. For example, a Virtual User can be stopped and a new Virtual User is started with the same User Path if an error occurs.

Fork

The Fork action is used to play actions in a different execution thread to the current one. This execution thread is parallel to the main chain used by the Virtual User. When the current iteration of the Virtual User stops, all the threads created using Fork actions in the Actions Container are immediately halted.

In particular, this action can be used to modelize automatic actions played by the browser while the Virtual User is using the web application normally. For example, an action could play every x seconds on the server to refresh a web component (Ajax, Flash plug-in...). This request must be made in parallel to the standard scenario for the Virtual User.

Fork-type logical actions may be shared among several User Paths. For more information, see Shared Containers.

When the option Create a local copy of existing variable values is:

unchecked (by default): existing values of variables are accessed by reference. When a variable value is modified in another thread, the modified value is used by the Fork action.
checked: existing values of variables are copied locally. When a variable value is modified in another thread, the variable value remains unchanged in the Fork action.

Note: Variables declared after the Fork is created are accessed by reference by the Fork whatever the option selected.

Variables

When NeoLoad variables are used inside a Fork, they are shared for reading in all the execution threads. This ensures communication of variables between the main execution thread and multiple secondary execution threads.

If, in due course, two execution threads modify the same variable, each of the threads obtains its own variable. This allows the use of the same variable extractors derived from the Framework parameters in several execution threads without having to worry about clashing values.

Lastly, in the case of same variables used in different execution threads, variables visibility is based on hierarchy: a Fork can access variables that have been modified locally by its parent until such time as it modifies them itself.

Limitations

When checking a User Path, the actions played as part of a Fork action appear in the list at the moment they are executed. This can make reading the validation results more complicated, as the list will contain several overlapping execution threads.

Execution threads persistence

In the Actions Container, the execution threads created using fork actions are halted when the Container execution is complete. Every Virtual User iteration recreates new paralleled execution threads distinctively.

In the Init Container, the persistence of the execution threads created using Fork actions is subordinated to the configuration of the Actions Container:

When the Emulate new browser between each iteration option is checked, the execution threads in the Init Container are halted when the first iteration execution is complete. Stopping the browser is simulated.
When the Emulate new browser between each iteration option is cleared, the execution threads in the Init Container persist all along the User lifetime.

To make an execution thread persistent until the Virtual User stops, the fork logical action must be set in the Init Container, and the Emulate new browser between each iteration option must be cleared for the Actions Container.

Information: For more information, see Structure of a User Path

Wait Until

The Wait Until action pauses the current execution thread until certain conditions have been verified.

A condition is composed of two operands and an operator. The operators are:

Equals - true if the 2 operands have the same value
Doesn't equal - true if the 2 operands do not have the same value
Contains - true if operand1 contains operand2
Doesn't contain - true if operand1 does not contain operand2
Starts with - true if operand1 begins with operand2, including if the 2 operands are equal.
Doesn't start with - true if operand1 does not begin with operand2.
Ends with - true if operand1 ends with operand2, including if the 2 operands are equal.
Doesn't end with - true if operand1 does not end with operand2.
Matches regexp - true if operand1 verifies the regular expression of operand2.
Doesn't match regexp - true if operand1 does not verify the regular expression of operand2.
Greater than -true if operand1 is greater than operand2.
Greater than or equal to - true if operand1 is greater than or equal to operand2.
Less than - true if operand1 is less than operand2.
Less than or equal to - true if operand1 is less than or equal to operand2.
Exists - true if operand1 corresponds to a name of a variable whose value is not nil. Operand2 cannot be defined.
Doesn't exist - true if operand1 does not correspond to a variable name or if operand1 corresponds to a variable name with a nil value. Operand2 cannot be defined.

Each operand may be a variable ${VariableName} or a static string. In the case of the Exists operator, operand1 can only be a VariableName variable name.

You may also set a maximum timeout delay in milliseconds. Once this delay is timed out, the thread is restarted. The following action is then executed, even if the conditions have not been verified