Assignment of Sample Next Steps Based On a UDF
PreviousApplying Indexing Patterns to Containers AutomaticallyNextParsing Metadata into UDFs (BCL Conversion and Demultiplexing)
Last updated
Last updated
In the default configuration of Clarity LIMS, at the end of every step, the user is required to choose where the samples will go next - i.e. the 'next step'.
If samples in the lab follow a logical flow based on business logic, this is an unnecessary manual task. This example shows how to automate this next step selection, to reduce error and user interaction.
This example uses the Automatically Assign Next Protocol Step (Example) step, in the Automation Examples (API Cookbook) protocol. The examples shoes how to:
Automate the selection of a sample's Next Steps, as displayed on the Assign Next Steps screen of this step.
Use the Pooling sample UDF / custom field to determine which next step each sample is assigned.
The Automatically Assign Next Protocol Step (Example) step has two permitted Next Steps:
Confirmation of Low-plexity Pooling (Example)
Automated Workflow Assignment (Example)
Depending on the value of a sample's Pooling UDF / custom field, the sample's Next Step will default to one of the permitted next steps:
If the value of the Pooling UDF / custom field is any case combination of No or None, the sample's next step will default to Automated Workflow Assignment (Example).
Otherwise, the sample's next step will default to Confirmation of Low-plexity Pooling (Example). Next step configuration (LIMS v4.x shown)
Automation is configured as follows:
Behavior: Automatically initiated
Stage of Step: On Record Details screen
Timing: When screen is exited
The script takes three basic parameters:
-u
The username of the API user (Required)
The {username} token
-p
The password of the API user (Required)
The {password} token
-i
The URI of the step that launches the script (Required)
The {stepURI:v2:http} token, in the form: http://<Hostname>/api/v2/steps/<ProtocolStepLimsid>
An example command line is shown below.
(Note: The location of groovy on your server may be different from the one shown in this example. If this is the case, modify the script accordingly.)
Assuming samples have been placed in the protocol and are ready to be processed, the user proceeds as normal:
Upon reaching the transition from the Record Details screen to the Assign Next Steps screen, the script is run. A message box alerts the user that a custom script is in progress.
Upon completion of the script, a custom success message is displayed.
Once the success message is closed and the screen has transitioned, the default next steps display for the samples.
Once the script has processed the input and ensured that all the required information is available, we can start to process the samples to determine their next steps.
First, we retrieve the next actions list:\
This endpoint contains a list of the step's output analytes, and a link to its parent step configuration. In this case, we want to retrieve the step configuration so that we can collect the URIs of the expected next steps.
Once we have retrieved the step configuration, we iterate over its possible next steps, gathering their URIs and storing them by name in a Map.
Once we have collected the URIs of our destination steps, we can start analyzing each sample to determine what its default should be.
For each possible 'next-action', we retrieve the target artifact, which then enables us to retrieve that artifact's parent sample.
We then retrieve the value of the sample's Pooling UDF / custom field , if it exists. If it doesn't exist, a default value is given.\
To set the next step, we set the step-uri attribute of the node to the URI of the expected destination step.
We also increment counters, so that we can report to the user what actions were taken on the given samples.
Once this is done, we perform an httpPUT on the action list, adding the changes to the API and allowing our defaults to be set.
Finally, we define the successful output message to the user. This allows the user to check the results.
You are running a version of Groovy that is supported by Clarity LIMS, as documented in the Clarity LIMS Technical Requirements.
The attached Groovy file is placed on the LIMS server, in the folder /opt/gls/clarity/customextensions
GLSRestApiUtils.groovy is placed in your Groovy lib folder.
A single-line text sample UDF named Pooling has been created.
The example code is provided for illustrative purposes only. It does not contain sufficient exception handling for use 'as is' in a production environment.
NextStepAutomation.groovy:
