Copying Output UDFs to Submitted Samples
Last updated
Last updated
It may at times be desirable to take key data derived during a workflow and copy it to the submitted sample. There are several reasons why this could be useful:
All key data is combined with all of the submitted sample's data, and becomes available on a single object.
Key data determined during a workflow can be made immediately available to external collaborators via the LabLink Collaborations Interface, since these users have access to their submitted samples.
Searching for data becomes easier as the data is not spread over several entities.
This example provides a script to allow the copying to occur, and describes how the script can be triggered.
To illustrate the script, we will copy a user-defined field (UDF) that is collected on the outputs of a QC type protocol step.
This UDF is named Concentration, and it is stored on the individual ResultFile entities associated with the analytes that went through the QC protocol step.
Once the QC protocol step has completed, the Concentration UDF values are copied to a UDF on the submitted Samples, which is called Sample Conc.
The QC protocol step is configured to invoke the script from a button on the step's Record Details screen.
The EPP command is configured to pass the following parameters:
An example of the full syntax to invoke the script is as follows:
Once the script has copied the UDF values from the output to the submitted samples, the values are visible in the Submitted Samples view of the Operations Interface:
Similarly, assuming that the Sample Conc. UDF is set to be visible within LabLink Collaborations Interface, collaborators are able to see these values in their interface:
The main method of interest is setUDFs(). This method carries out several operations:
It harvests just enough information so that the objects required by the subsequent code can retrieve the required artifacts using the 'batch' API operations. This involves using some additional code to build and manage the cache of artifacts retrieved in the batch operations, namely:
cacheArtifact()
prepareCache()
getArtifact()
The cached artifacts are then accessed, and for each one:
The corresponding sample is retrieved via the API.
The sample XML is updated such that the UDF value is obtained from the artifact by calling api.getUDF(), and stored on the sample by calling api.setUDF().
The sample XML is saved by calling api.updateObject().
Finally, a meaningful message is reported back to the user via the contents of the successMsg and/or failMsg variables.
Both of the attached files are placed on the Clarity LIMS server, in the /opt/gls/clarity/customextensions folder.
You will need to update the HOSTNAME global variable such that it points to your Clarity LIMS server.
The example code is provided for illustrative purposes only. It does not contain sufficient exception handling for use 'as is' in a production environment.
setUDFonSample.py:
-l
The limsid of the process invoking the script (Required)
-u
The username of the current user (Required)
-p
The password of the current user (Required)
-f
The UDF on the submitted sample to be copied to (Required)
To copy multiple UDF values from outputs to submitted samples, a list of comma-separated values may be provided.
-t
The type of output that has the UDF to be copied from (Required)
For example, Analyte, ResultFile, Pool, etc.
-v
The name of the UDF to be copied from (Required)
To copy multiple UDF values from outputs to submitted samples, a list of comma-separated values may be provided.
