Synchronizing Script Executions
Occasionally we receive inquiries from Eggplant Functional users who wish to have their scripts run in a parallel fashion, where one script execution waits for an event to occur in a second script execution before proceeding. Eggplant Functional is able to achieve a similar functionality by switching the active system under test (SUT) connection with a Connect command. However, this approach can only automate the SUTs in serial and not truly in parallel.
As separate script executions are handled by separate Eggplant processes, and there is not a mechanism out of the box that allows the processes to be aware of each other, but through some clever scripting, it is possible to allow script executions to communicate and be synchronized to varying degrees.
Parallel script executions require one Eggplant Functional license for each script executed in parallel.
The easiest way to facilitate communication between the scripts is through a simple, shared external data file, such as a text file, that they can each access independently. Next, one can override the code for commonly used commands, such as "Click" and "WaitFor", so that each time the commands are called, communication with the shared data file is executed, enabling the script executions to remain synchronized.
For a very simple example of how to synchronize running the same script against two different SUTs in parallel, see the example scripts:
DrivingScript contains the actual commands that automate the SUTs and perform the test.
Params TestDevice, OverrideScript //passing parameters with the connection information for the SUT, and the name of the override script (FirstSUT or SecondSUT)
Start Using OverrideScript //tell DrivingScript to start looking at the override script handlers before looking at its own command/function library
Connect TestDevice
//begin code that should be synchronized
MoveTo "Pic1"
MoveTo "Pic2"
MoveTo "Pic3"
//end synchronized code
Stop Using OverrideScript
FirstSUT contains the code that acts to create a shared data file when a command is executed on the first SUT.
//a handler override, such as the one below for MoveTo, is needed for each command that should be synchronized
to MoveTo
CheckForNoFile
pass message and continue //passes the message, which is the name of the handler, or "MoveTo", in this case, as well as any parameters passed into the handler (if applicable)
CreateMyFile// creates the file once the MoveTo command happens
end MoveTo
to CheckForNoFile-- checks for the absence of the file
repeat until file "C:\Users\Carrie\Desktop\synccheck.txt"does not exist
end repeat
end CheckForNoFile
to CreateMyFile
Create file"C:\Users\Carrie\Desktop\synccheck.txt"
end CreateMyFile
SecondSUT contains the code that checks whether the data file exists before executing the parallel command on the second SUT.
to MoveTo
CheckForFile
// pass message and continue
DeleteMyFile
end MoveTo
to CheckForFile// checks for the presence of the file
repeat until file "C:\Users\Carrie\Desktop\synccheck.txt"exists
end repeat
end CheckForFile
to DeleteMyFile
Delete file"C:\Users\Carrie\Desktop\synccheck.txt"
end DeleteMyFile
FirstSUT and SecondSUT leverage handlers with the same names as standard commands to override, or to what is sometimes called overload, the functionality of those commands in DrivingScript. DrivingScript will be called twice in succession, once for each SUT. The execution using the OverrideScript=FirstSUT parameter must be passed first, as FirstSUT is the script that controls the initial creation of the shared data file. The two executions of DrivingScript will take turns creating and deleting the shared data file, while simultaneously taking turns executing each command.