Finishing the Current Step and Starting the Next
Many facilities have linear, high-throughput workflows. Finishing the current step and finding the samples that have been queued for the next step. Then putting the samples into the virtual ice bucket. Then actually starting the next step. All of these steps can be seen as unnecessary overhead.
This solution provides a methodology that allows a script to finish the current step, and start the next.
We have already illustrated how a step can be run in its entirety via the API. Finishing one step and starting the next would seem a straightforward exercise, but, as most groups have discovered, there is a catch.
Consider the step to be autocompleted as Step A, with Step B being the next step to be autostarted.
The script to complete Step A and start Step B will be triggered from Step A (in the solution defined below, it will be triggered manually by clicking a button on the Record Details screen).
As Step A invokes a script:
The step itself cannot be completed - because the script has not completed successfully. - and -
The script cannot successfully complete unless the step has been completed.
To break this circle, the script initiated from Step A must invoke a second script. The first script will then complete successfully, and the second script will be responsible for finishing Step A and started Step B.
Solution
Invoking script: runLater.py
The runLater.py script launches the subsequent script (finishStep.py) by handing it off to the Linux 'at' command (see Notes). This process effectively 'disconnects' the execution of thefinishStep.py script from runLater.py, allowing runLater.py to complete successfully, and then Step A to be completed.
Parameters
The script accepts the following parameter:
Although this script accepts just a single parameter, the value of this parameter is quite complex, since it is the full command line and parameters that need to be passed to the finishStep.py script.
Following is an example of a complete EPP / automation command-line string that will invoke runLater.py, and in turn finishStep.py:
Invoking script: finishStep.py
The finishStep.py script completes and starts Steps A and B respectively.
Parameters
The script accepts the following parameters:
-u | The username of the current user (Required) |
-p | The password of the current user (Required) |
-s | The URI of the step that launches the script (Required) |
-a | The action, or mode that the script runs under (Required). Accepted values are START (which completes the current step and starts the next) or COMPLETE (completes the current step) |
About the code
The first thing that this script does is go to sleep for five seconds before the main method is called. This delay allows the application to detect that the invoking script has completed successfully, and allow this script to work. The duration of this delay can be adjusted to allow for your server load, etc.
The central method (finishStep()) assumes that the current Step (Step A) is on the Record Details screen. Next, the method callsadvanceStep() to move the step onto the screen to allow the next step to be selected. By default, the routeAnalytes() method selects the first available next step in the protocol / workflow for each analyte. Then theadvanceStep() method is called, which completes Step A.
If the script has been passed a value of 'START' for the -a parameter, the next step (Step B) will now be started. ThestartNextStep() method handles this process, carrying out the following high-level actions:
It determines the default output container type for Step B.
It invokes an instance of Step B on the analytes routed to it via the routeAnalytes() method.
If the Step B instance was invoked successfully, it gathers the LUID of the step.
At this point, it is possible that the apiuser user has started the step. This situation is not ideal. We would like to update it so that it shows up in the Work in Progress section of the GUI for the user that initiated Step A.
This script makes a note of the current user and then updates the new instance of Step B with the current user. This update can fail if Step B has mandatory fields that must be populated on the Record Details screen (see Notes). It can also fail if the step has mandatory reagent kits that must be populated on the Record Details screen.
If the update does fail, the step has been started, but the apiuser user still owns it. It can be continued as normal.
Assumptions
The attached files are placed on the Clarity LIMS server, in the following location: opt/gls/clarity/customextensions
The attached files are readable by the glsai user.
Updating the HOSTNAME global variable such that it points to your Clarity LIMS server is required.
The example code is provided for illustrative purposes only. It does not contain sufficient exception handling for use 'as is' in a production environment.
The scripts use rudimentary logging. After the scripts are installed and validated, these logs are of limited value, and their creation can likely be removed from the scripts.
Notes
The Linux 'at' command might not be installed on your Missing variable reference server. For installation instructions, refer to the Linux documentation.
For a solution to this issue, see Validating Process/Step Level UDFs.
Attachments
runLater.py:
clarityHelpers.py:
finishStep.py:
Last updated