Appendix E: Parallel Steps Configuration Hints
This section provides hints on configuring and running test scripts that comprise parallel steps opening device sessions to configured devices and executing commands on the established sessions.
Parallel Steps Execution Examples
Execution of parallel steps that establish connections to configured devices and execute commands on the established connections should be considered with care.
The subsequent examples illustrate by way of example that unique session identifiers must exist within each Composer test execution in order to obtain a predictable behavior at test execution time.
Example 1
This example illustrates the case of a procedure P that opens a session to a configured device, executes some commands on the device, and eventually closes the connection. In the main test body, this procedure is called by two RunProcedure steps configured for running in parallel.
Assuming, for example, that we had the four step procedure defined below:
Procedure
StartSession Router_01 //S1
Execute Router_01 <some_command> //S2
Execute Router_01 <some_command> //S3
StopSession Router_01 //S4
EndProcedue
and that we wanted to call the procedure twice, with the corresponding
RunProcedure steps configured as parallel:...
RunProcedure P // instance P1 launched as parallel step
RunProcedure P // instance P2 launched as parallel step
...
In this case, since the application's execution engine does not enforce an exclusive per-session access to the configured device, the actual executed steps sequence is largely unpredictable and the obtained test execution flow could be for example that shown in Figure:Steps Execution Sequence below:
Figure:Steps Execution Sequence
In the diagram above, the step first index refers to the procedure instance, while the second index references the step number within the procedure. For example, S12 denominates the second procedure step that is executed by the first instance of the called procedure P.
An execution flow such as that shown in Figure:Steps Execution Sequence would set the configured device in an unpredictable state, since at the time of the execution of step S21 the connection would already be open (it was opened by S11), or at the time of the execution of S23 the connection would already be closed (it was terminated by S14).
To avoid such a situation, you would have to avoid executing in parallel steps that execute commands referencing the same session.
Example 2
This example illustrates the case of a procedure P opening a session to a configured device, executing some commands on the device, and closing. The procedure accepts an IP address as argument, which is used inside the procedure to connect to a device specified by that argument.
Procedure P {String: IP_addr}
StartSession Router_01 $IP_addr //S1
Execute <some_command> Router_01 //S2
Execute <some_command> Router_01 //S3
StopSession Router_01 //S4
EndProcedure
and that we tried to use the procedure in the main test body to configure two different devices (10.0.0.1 and 10.0.0.2) in parallel, using in a loop construct such as a following:
...
For IP_addr in {10.0.0.1, 10.0.0.2}
RunProcedure P $IP_addr //PunProcedure step is parallel
EndFor
...
Instead of opening a Router_01 session with the device at IP address 10.0.0.1 and another Router_01 session with he device at IP address 10.0.0.2, such an execution would open a single session 10.0.0.1, and no configuration command would reach device 10.0.0.2.
Such a behavior again highlights the requirement of using a single, unique session identifier per test.
Example 3
Another example that illustrates the requirement of using a single, unique session identifier per test is the following.
Let us consider the case of a test that opens a session to a configured device and then executes some commands on the device.
StartSession Router_01 $IP_addr //S1
Execute <some_command> Router_01 //S2
Execute <some_command> Router_01 //S3
StopSession Router_01 //S4
Let us also assume that step S2 is configured as monitoring the command response and triggering the execution of a local procedure P that uses the same session Router_01 opened by the test (S1).
Procedure P
Execute <some_command> Router_01 //P1
EndProcedure
In such a case, if at test execution time step
S2
would encounter a matching command response from the configured device and would effectively trigger the procedure P, then the procedure-triggering step (S2) would time out.
IxLoad TestComposer │ User Guide |