• Validating Process/Step Level UDFs

• Checking That Containers Are Named Appropriately

• Checking for Index Clashes Based on Index Sequence

In this example, the protocol step is configured to invoke a script that is triggered when the user exits the step's Record Details screen.

Parameters

The EPP command is configured to pass the following parameters to the script:

An example of the full syntax to invoke the script is as follows:

User Interaction

When the lab scientist attempts to exit the Record Details screen, the script is invoked and the UDF names specified in the -f parameter will be checked to see that they have been populated. If they ALL have been, the script issues no message, and the process will continue as normal. If however, SOME of the UDFs have not been populated, a message will be displayed to the user indicating which mandatory fields need to be populated, and the user will be unable to move forward until all the specified fields have been populated.

About the Code

The method of central interest in the script is checkFields(). The method in turn carries out several operations:

1. The list of fields passed to the script via the -f parameter is broken into its component UDF names

2. For each UDF name in the list, the corresponding value is checked via the API, and if the value is empty, the UDF name is noted as absent

3. If any UDF names are noted as being absent, an error dialog will be displayed to the user.

Assumptions and Notes

• Both of the attached files are placed on the LIMS server, in the /opt/gls/clarity/customextensions folder.

• The HOSTNAME global variable needs to be updated so 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.

Attachments

checkprocessFields.py:

When pooling samples, there are often numerous complex rules and restrictions regarding which combinations of adapters are acceptable.

As a method of applying custom business logic, it is possible to automate the verification of your pools using Clarity LIMS.

This example shows how to confirm the composition of pools before they are created, allowing the lab scientist to alter the composition of pools that have caused an error.

Solution

In this example, we will enforce the following Illumina TruSeq DNA LT adapter tube pooling guidelines:

Process

The example script is configured to run on the Library Pooling (Illumina SBS) 4.0 process.

Parameters

The EPP command is configured to pass the following parameters to the script:

An example of the full syntax to invoke the script is as follows:

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.

User Interaction

1. Assuming samples have been worked through the protocol and have reached the Library Pooling (Illumina SBS) 4.0 protocol step, the user pools the samples following the specified guidelines.

2. When the pools are created, the user attempts to proceed to the next page.

3. A message box displays alerting the user that a custom program is executing.

About the Code

Once the script has processed the input and ensured that all the required information is available, we process the pools to determine if they meet the required specifications.

1. The first challenge is to represent the adapter combinations in the script.

   • This is accomplished by a map comprised of the adapter names, indexed by their respective number, ie. AD001 indexed at 1.

2. Next, we define the three combination groups: 2 plex, 3 plex, and 4 plex.

Assumptions and Notes

• Your configuration conforms with the script's requirements, as documented in .

• 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 /opt/gls/clarity/customextensions folder.

Attachments

ConfirmationOfPoolComposition.groovy:

Single Indexing ReagentTypes.xml:

While not a common scenario, it is possible to have two molecular barcodes/indices in BaseSpace Clarity LIMS that share the same sequence.

Within Clarity LIMS, there is logic that can be enabled to prevent pooling of samples with the same index name. However, this check is based upon the index name, not the sequence. In the case of identical indexes with differing names, additional logic is required to prevent index clashes based upon the index sequence.

This example provides a solution that looks for index clashes based upon sequence.

Solution

In this example, the protocol step that is responsible for pooling is configured to invoke the script as soon as the user exits the step's Pooling screen.

Parameters

The EPP command is configured to pass the following parameters:

An example of the full syntax to invoke the script is as follows:

User Interaction

When the user exits the Pooling screen, the script is invoked.

• If no index clashes are found, the step proceeds and the script does not report back to the user.

• If an index clash is found, a message is returned to the user, informing them of the problematic components within the affected pool. The user is not able to continue the step without first re-constituting the pools.

About the Code

The main method in the script is checkIndexes(). The method in turn carries out several operations:

1. The step's pools resource is queried.

2. The constituent artifacts of each pool are identified, along the with name of the reagent-label applied.

3. For each reagent-label:

Assumptions and Notes

• 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.

NOTE: The current script uses caching to avoid unnecessary GETs, but does not use batch transactions. In the case of large levels of multiplexing, the script could be reworked to gather all of the constituent artifacts in a single batch transaction.

Attachments

checkIndexes.py:

When samples are placed onto containers in BaseSpace Clarity LIMS, the default operation is that containers produced by the system are named with their LIMS ID (for example 27-1234 etc). The expectation is that after samples have been placed, the user will rename the containers with the barcode that is on the plate, chip, or other container.

There are places in the workflow in which issues will occur with integrations if the user renames the container incorrectly.

For example, when loading libraries onto a flow cell for sequencing, the flow cell container must be renamed with the actual ID/barcode of the flow cell in order for the Illumina integration to complete its work successfully.

This example provides a short script that checks to see if the user has correctly renamed containers after the placement of samples. It also shows what occurs in the Clarity LIMS Web Interface when the script encounters a naming issue.