Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
As of BaseSpace Clarity LIMS v5.0, several terms have been deprecated:
External Program Integration Plug-in (EPP) has been replaced with automation
EPP/AI node has been replaced with automation worker / AW node
Parameter has been replaced with token
User defined field (UDF) has been replaced with custom field
When a job is dispatched to the AI node/automation worker, the following steps occur:
A temporary working directory is created on the AI node / automation worker:
In AIInstallDirectory/temp/
With a unique name including the client process LIMS ID.
The command configured and selected as part of the step run in the LIMS is then sent to the AI node / automation worker, with any specified parameters / tokens replaced with actual values.
The command is executed on the AI node / automation worker, spawning step execution using the temporary working directory as the working directory context.
Script processing can use stdout, stderr, and return codes following standard shell programming packages.
When the script exits, the AI node/automation worker automatically retrieves any files with matching LIMS IDs from the temporary working directory. The files are attached to the appropriate output file placeholders.
The automation API infrastructure can be used alone or with the REST API infrastructure.
For example:
Simple scripts can use automation parameters/tokens and data files directly from the current working directory. They can write results back to the current working directory, associating them back to the relevant placeholders in Clarity LIMS.
More advanced scripts can also use the REST API infrastructure to retrieve additional required information and place relevant data back into UDFs/custom fields. Advanced scripts can also attach and associate data files to placeholders, which may be in different locations, while the script is still running.
This section provides information to help you work with Clarity LIMS automation tokens in Clarity LIMS v5 and later.
As of BaseSpace Clarity LIMS v5, the Operations Interface Java client, which is used by administrators to configure processes, consumables, user-defined fields, and users, has been deprecated. All configuration and administration tasks are now executed in the Clarity LIMS web interface.
In addition, several terms have been deprecated:
External Program Integration Plug-in (EPP) has been replaced with automation
EPP/Automated Informatics (AI) node has been replaced with automation worker / AW node
Parameter has been replaced with token
Use step automations to trigger a command-line call on a process/step or a file attachment event. The steps required differ depending on the LIMS version.
This article provides an overview of the steps required to configure automations and automation triggers. For detailed version-specific instructions, see the following documentation:
Clarity LIMS v6 reference guide > Configuration > Automations
On the main menu bar, click Configuration, and then click the Automation tab.
On the Automation configuration screen, on the Step Automation tab, add a new automation:
Name the automation.
Set the channel name.
Define the command line.
Enable the automation on the desired steps.
On the Master Step Settings or Step Settings screen of the related step, set the following:
Trigger Location—The stage at which the script it is to be initiated (beginning of step, end of step, on entry to/exit from a screen, etc.).
Trigger Style—How the script is to be initiated (automatically or manually when the user selects a button in the interface).
For more information, see the API Training Videos
Scripts produce a numeric code on exit. By convention and by default, a successful exit has a code of 0 (zero). Within error handling, select different nonzero exit codes to indicate various error conditions.
NOTE: For Clarity LIMS v5.0, the term External Program Integration Plug-in (EPP) is deprecated and replaced with automation.
Though logging information in the Clarity LIMSuser interface is useful, scripts can also write debugging/troubleshooting information into the automatedinformatics.log file using stderr (standard error). When a line is printed to stderr, a [WARN] line is written to this log, which is useful for troubleshooting interactions between the script and the automation programs. For more information on the automatedinformatics.log file, see Troubleshooting Automation. For more information on using stderr on the command line, refer to Unix and Windows documentation on standard I/O streams, especially standard error.
In Clarity LIMS, the last line written to stdout (standard out) is automatically captured and shown in the interface.
If the exit code is zero, the message displays in green. If the exit code is nonzero, the message displays in red.
The Operations Interface Java client is deprecated in Clarity LIMS v5. All configuration and administration tasks are currently executed in the LIMS web interface.
If the script exits with a nonzero code, a sample genealogy flag is automatically added to the process outputs, with a standard error message indicating there is an External Program Error.
If the script is complex, or includes several error conditions, configure an additional result file process output (eg result.log) designed to capture status and error information. Make the external script write additional information to this file. If an error occurs, the file is still captured in the client, and is available to view for troubleshooting purposes.
The automation and integration of the day-to-day work in the lab requires different Automated Informatics (AI) nodes/automation workers to perform different tasks.
For BaseSpace Clarity LIMS v5.0, several terms are deprecated:
Automation replaced External Program Integration Plug-in (EPP).
Automation Worker (AW) node replaced EPP/AI node.
Channels are manually named, and ideally clearly represent the task performed (eg. Type_2_Analysis). To make sure that dispatched automation work is routed to the correct destination, specify a channel in the following places:
On the AI node / automation worker
Clarity LIMS v5 and later: When configuring step and derived sample automations on the Automation tab
When the automation trigger conditions are met in the LIMS, the automation job first enters a channel-specific 'first in, first out' (FIFO) queue of work for completion.
Jobs queue in this channel until one of the AI nodes/automation workers operating on the channel completes its previous work, and indicates it is free to accept more.
The next job is then dispatched from the channel queue to the node. This strategy allows a single channel queue to receive service by one, or many, AI nodes/automation workers servicing the specified channel.
It is possible to have multiple AI nodes/automation workers performing the same type of work all configured on the same channel, allowing a simple but effective way to increase throughput of a particular analysis bottleneck, or to ensure redundancy during a single node failure.
Clarity LIMS automations typically call scripts or third-party programs written for a shell or command-line interpreter, of either a Linux or Windows operating system (OS). Although the use of any system shell if acceptable, Bash is recommended.
Depending on the systems that integrate with the given automations, various restrictions apply to the string parameters/tokens and formatting used in the automation command line.
As of Clarity LIMS v5, several terms have been deprecated:
External Program Integration Plug-in (EPP) has been replaced with automation
EPP/AI node has been replaced with automation worker / AW node
Parameter has been replaced with token
Environment variables can be used to aid in configuration. However, automation commands are generated with a limited shell. For full access to environment variables, the recommended practice is to start the command to instantiate a 'full' user shell. For example, for Bash use the following command:
This procedure provides the following advantages:
Ensures updates of the environment variables, removing the need for repeated AI node/automation worker restarts.
Ensures access to all environment variables, including the full path to Groovy.
Allows certainty of the shell being used.
The various operating system (OS) shells each have their own rules and regulations. When creating command-line strings, be aware of the considerations described in the following sections.
Windows shell command-line interpreters require different syntax and formatting than Linux shell variants. For example, the following scripts are identical, but are formatted for different AI nodes/automation workers running on different operating systems.
On Linux:
On Windows:
Most of the examples in this specification use Windows formatting, because Windows is the most common platform found in the lab.
Spaces
Spaces in paths, file names, or parameter/token data can cause commands to be misinterpreted as information passes between systems.
Many OS shells automatically parse command-line contents by space, which cannot be what is intended. Enclose commands in double quotes " " to avoid misinterpretation of spaces by the OS shell command-line interpreter.
Special characters
OS shell command-line interpreters can attempt to interpret and act upon certain special characters, rather than passing them along as textual information. A character can have a rule applied to it within one OS shell environment, and a different rule under another environment. To use a character in its literal form, escape the characters. The escape character used varies depending on your OS shell. The most common escape character is the backslash character.
The most common OS shell characters that require escaping are:
To make sure that a configured command in the client is properly interpreted, test it on the AI node/automation worker machine command line.
To trigger scripts and third-party programs from the BaseSpace Clarity LIMS user interface, use command-line calls configured in step automations.
There are many ways to use automation in Clarity LIMS. Consider the following examples:
Automate sample tracking and enhance the information recorded.
Generate and attach specially-formatted text files.
Simplify data entry.
Automate the population or updating of data fields and data files.
Before using automation, become familiar with the topics discussed in this article and understand how automation functionality interacts with users, Clarity LIMS, and REST.
As of BaseSpace Clarity LIMS v5.0, several terms have been deprecated:
External Program Integration Plug-in (EPP) has been replaced with automation
Automated Informatics (AI) node has been replaced with Automation Worker (AW) node
Parameter has been replaced with token
Automation scripts are often used to automatically create and attach specially-formatted text files, such as the following:
Files containing sample lists (sometimes called instrument driver files). Users can import these driver files into control software, saving time and ensuring accurate sample processing.
Barcode or label files. These are specially-formatted files that can be supplied to barcode software systems to allow users to print out container labels.
Summary analysis results - for example, from alignment or molecular identification and quantification algorithms.
The two common applications of automation are:
To create files and attach them to process output placeholders.
To update data fields with information created during data analysis.
Scripts triggered by automation also use REST to update information directly within the REST resources.
For details, see REST Web Services and the version-specific documentation in the following sections:
Record lab work in Clarity LIMS by running steps on samples. These steps may be configured in Clarity LIMS by an administrator.
Most steps can be configured with an automation trigger that invokes an external script. The script may include fixed and variable information parameters/tokens on the command line.
NOTE: As of Clarity LIMS v5.0, the term command-line parameter has been replaced with token.
After an AI/AW node is installed, processes (in Clarity LIMS v4.2 and earlier) or steps (Clarity LIMS v5 and later) must be configured to call out to it.
This configuration is executed by the Clarity LIMS administrator:
In Clarity LIMS v4.2 and earlier, execute configuration in the Operations Interface process configuration dialog on the External Programs tab.
In Clarity LIMS v5 and later, execute configuration on the Automation configuration screen.
When configuring an automation, the following must be defined:
Name
Channel
Command line call
Trigger style and location (see also Automation Triggers and Command Line Calls)
NOTE: Only a brief summary of automation configuration is provided here. This material should be familiar from the Clarity LIMS administration training.
Scripts or third-party programs are called using the operating system command line. They must meet the following requirements:
Be callable on the command line and, preferably, be able to read and respond to command-line parameters.
Be accessed by the user account running the automation, with appropriate permissions and disk locations.
Exit with appropriate exit codes, otherwise the automation may record the script completed with an error.
The following diagram illustrates what happens when a user runs a step in the LIMS.
The lab scientist tracks activities by running a step in Clarity LIMS. The step is configured to display a button that invokes the configured automation script.
NOTE: As of Clarity LIMS v5.0, the term parameter has been replaced with token.
The application server creates a new step, which is much like POSTing to the processes resource of the REST API. The server resolves any parameters/tokens found in the string and sends the resolved command-line string to the automation.
In this example, two of the most common parameters/tokens used when working with automation are discussed:
{processURI:version:scheme}—This parameter/token passes the REST API URI of the step that issued the command-line string.
{ouputFileN}—This parameter/token passes the LIMS ID of the specified expected output file of the step that issued the command-line string. You can use 0 (zero) for the first file, 1 (one) for the second file, etc.
For more information about the parameters/tokens available for use, refer to the articles in the following API documentation sections:
NOTE: As of API v1 r12, the version and scheme values for {processURI:version:scheme} are automatically populated, based on the REST version and protocol of the deployed server.
The automation program receives the command-line string from the application server. It may also receive other process(step)-related information, such as temporary files. The command-line string is executed by the operating system of the host computer.
The automation can work with any third-party program that supports command-line parameters/tokens. The program may simply create files or it may manipulate information directly via the REST API (steps 5 and 6).
Simple automation operation does not require anything of the REST API. If a third-party program creates files that users would like brought back into Clarity LIMS, scripts should use the outputFileN parameter/token to specify that the program create file names that are expected by the client. The files are placed in a temporary local working directory and automatically imported into the client. With this method, the automation automatically handles many of the things that would need manually scripts using the REST API processes, artifacts, files, and glsstorage resources.
For more complicated scenarios, you may want to use automation with the REST API. This situation is where the processURI parameter/token is used. A GET request on the URI of the step that issues the command-line string provides all the information recorded by the user. This information includes links to the analytes (samples) used as inputs. The script can then use other REST API resources to create or update information.
On completion, the third-party program exits (step 7). Standard shell exit codes apply: zero (0) equals successful completion.
On exit of the third-party program, the automation software updates the application server. If the system finds files with names that match the file placeholders produced by a process/step, the files are uploaded to the file server and attached to the appropriate placeholders.
A nonzero exit code sets a flag on the step, indicating that there is an error.
With updates complete, the application server sends refresh events to the Clarity LIMS. The user will see that files have been uploaded.
Verifying and testing scripts is an important part of working with automation. Remember that there are three software components:
The server
The automation instance (calling scripts)
The script
The best way to debug scripts is to unit test each component separately. For example a logical order to work on a script is as follows:
Define and test the REST calls required in a web browser.
Define the command-line parameters / tokens sent to the automation at step completion.
Test the script running just from the command line.
Test automation calls to the script at step completion by running the step from the LIMS interface.
Before the system can use the automation, a system administrator installs one or more automation workers / AI nodes within the lab network. The installation typically occurs on the server that contains the script program, or third-party application, to be integrated.
The installer program is contained in the Automated Informatics / Automation Worker software package.
When configuring automations in the BaseSpace Clarity LIMS, copy tokens from the Tokens list and paste them into the Command-Line field.
These tokens are available for use in derived sample automations. If using multiple variables, add a space between each entry. All tokens and parameters are case-sensitive.
| Token | Purpose | Example |
|---|---|---|
When configuring automations in BaseSpace Clarity LIMS, copy tokens from the Tokens list and paste them into the Command Line field.
These tokens are available for use in project automations. If using multiple variables, add a space between each entry. All tokens and parameters are case-sensitive.
| Token | Purpose | Example |
|---|---|---|
When configuring automations in BaseSpace Clarity LIMS, copy tokens from the Tokens list and paste them into the Command Line field. These tokens are available for use in step automations. If using multiple variables, add a space between each entry. All tokens and parameters are case-sensitive.
| Token | Purpose | Example |
|---|---|---|
Use the setExitStatus.py Python script, attached to this page, to test and simulate the use of the automation triggers within Clarity LIMS.
The setExitStatus.py script is designed to illustrate concepts for API training purposes. Do not use in a production environment.
The setExitStatus.py script relies on the presence of the glsapiutilv2.py script. Typically, both scripts are located in the same directory.
The setExitStatus.py script uses the following command-line parameters:
An example of a parameter string that invokes this script from Clarity LIMS is provided in the following. Note the use of the stepURI token in the -l parameter.
python /opt/gls/clarity/customextensions/setExitStatus.py -l {stepURI:v2:http} \
-u {username} -p {password} -s "OK" -m "successful"
glsapiutilv2.py:
setExitStatus.py.txt:
Clarity LIMS v4 and later
Automation is powerful and simple in design. However, its applications can quickly become complex. We recommend you keep your scripts simple. When troubleshooting, the best practice is to isolate the issue to determine the source. The Automated Informatics (AI)/automation worker log file, automatedinformatics.log, is useful for isolating system components and diagnosing problems.
Isolate the behavior of each component in the system. In particular, determine if the following components can be ruled out as causing of the problem:
The script or program—Running the custom logic, REST calls, and file handling.
The AI nodes/automation workers—Calling the command line and invoking the script or program.
The network—Providing reliable and timely TCP/IP packet transfers.
The client—Completing the process/step and notifying the server.
The server—Responding to client notifications and dispatching to AI nodes/automation workers.
The script provides many options for troubleshooting. For example, increase logging to rule out unexpected behavior.
Printing to stderr in the script writes a line to the automatedinformatics.log file. This file is a great source of information.
The records in the log file allow for emulating the command-line call for unit testing the script, and calling it manually on the command-line prompt (see ).
helps verify the automation program on the AI node/automation worker. If the script and the AI node/automation worker are functioning, review the log file entries for any warning (WARN) or error (ERR) lines near the time-stamp of the process completion event sent from the client.
If the issue is related to the client or server software, contact the Illumina Support team, providing:
The automatedinformatics.log file
The server log
The results of the isolation tests (in the previous section).
Use the following steps to test and verify the setup.
Create a process/step that generates a result file.
Configure an automation on the process/step. Associate it with the channel on which the AI node/automation worker is configured to communicate.
Add the following command line string.
cmd /c "C:\ai\ai.bat {outputFile0}"
On the AI node/automation worker machine, create an ai folder in C:\ so the system has an C:\ai path. Create a new file named ai.bat.
Edit the ai.bat file and add the following line:
echo Data for Output File LIMS ID %1 > %1.txt
Run the process/step created on an existing attached result file.
The step passes the LIMS ID of its output file placeholder to the script.
The script creates a file in the working directory.
When the script exits, this file transfers to the LIMS and associated with the step. The file contains a single line of text that includes the LIMS ID of the output file for easy verification.
Create a process/step that generates a result file
Configure an automation on the process/step. Associate it with the channel on which the AI node/automation worker is configured to communicate.
Add the following command line string:
bash -c "echo Automation Test > {outputFile0}.txt"
Run the process/step created on an existing attached result file.
The step passes the LIMS ID of its output file placeholder to the script.
The script creates a file in the working directory with a file name that contains this LIMS ID.
When the script exits, this file transfers to the LIMS and associated with the step. The file contains the text "Automation Test". When open, the file opens in the default program associated with *.txt files.
AI nodes/automation workers are installed using the Automated Informatics (Automation Worker for LIMS v5 and later) software package.
In the installation directory:
Find the /log directory, which contains an automatedinformatics.log file.
Use this file to locate log lines near the time of the process/step completion event.
Locate the log line containing the parameter/token command string, and manually run and test the script.
Locate the working directory to review temporary files created.
This step can indicate if the cause of the error lies with a network or other issue external to the computer running the AI node / automation worker.
Running the script manually forms a unit test. The script is run on the command line, without being invoked by automation.
To locate the line containing the command-line string, search for the Command string, or externalprogram.runExternalProgram.
An example is shown in the following abridged log file section. Copy the line to a text file and modify it for script testing.
2014-02-28 21:24:48,688 INFO ... definitions.behaviour.automatedinformatics.plugins.externalprogram.runExternalProham as ...
2014-02-28 21:24:49,323 INFO ... (ExternalProgramBehaviour.java:133)... Command string: bash -c "~/scripts/HelloWorld.sh http://###.###.###.###/api/v2/processes/A30-MXX-110228-24-2320 > 92-2869.txt"
Used when temporary files are left by the script, this automation script removes the temporary working directory, unless there was an error. In case of an error, the directory provides clues to the root cause of the error.
To locate the working directory, search for "Working directory:" in the log file.
An example is shown in the following abridged log file section. Use the recorded directory to list and review temporary files.
2014-02-28 21:24:49,324 INFO ... Working directory: /home/gls/GenoLogicsAutomatedInformatics/temp/runExternalProgram-28022014-432350866632555775.A30-MXX-110228-24-2320
2014-02-28 21:24:49,324 INFO ... Retrieved files. Executing command.
As of BaseSpace Clarity LIMS v5.0, several terms have been deprecated:
Automation replaces External Program Integration Plug-in (EPP). In LIMS v4.x and earlier, the Operations Interface still uses the term EPP.
Automation worker/AW node replaces AI node.
Token replaces Parameter.
Step replaces Process in the web interface.
The latest glsapiutil (and glsapiutil3) Python libraries can be found on the page.
With automation, the command-line information is important. The actual values sent on the command line are recorded in the AI log file as the AI node/automation worker receives them. Copy the parameters/tokens from the log and use them on the command line to troubleshoot. If scripting in Groovy, the cli class handles command-line tokens well. See the example *.groovy files used with automation and the utility class section in .
If no records are found, use the procedure to confirm that logging is functional.
{username}
Supplies the username of the current user running the step to the triggered automation script.
cmd /c "C:\ai\ai.bat {username}"
resolves to:
cmd /c C:\ai\ai.bat adminuser
{password}
Supplies the password of the current user running the step to the triggered automation script.
cmd /c "C:\ai\ai.bat {password}"
resolves to:
cmd /c C:\ai\ai.bat 3BlindMice
In log files, the password supplied on the command line is replaced with a series of *** characters.
{baseURI}
Supplies the base API URI to the triggered automation script.
cmd /c "C:\ai\ai.bat {baseURI}"
resolves to:
cmd /c C:\ai\ai.bat https://lims.lan.29/api
{derivedSampleLuids}
Supplies the derived sample LIMS IDs to the triggered automation script.
cmd /c "C:\ai\ai.bat {derivedSampleLuids}"
resolves to:
cmd /c C:\ai\ai.bat 2-1641 2-1642 2-1643
{userinput:customParameterName}
Allows for data input to supply the triggered automation script. Custom parameters are identified with the prefix 'userinput:'
The following command line requires the user to input a value for 'more_yield':
yieldscript.sh -y {userinput:more_yield} -u {username}
{username}
Supplies the username of the current user running the step to the triggered automation script
cmd /c "C:\ai\ai.bat {username}"
resolves to:
cmd /c C:\ai\ai.bat adminuser
{password}
Supplies the password of the current user running the step to the triggered automation script.
cmd /c "C:\ai\ai.bat {password}"
resolves to:
cmd /c C:\ai\ai.bat 3BlindMice
In log files, the password supplied on the command line is replaced with a series of *** characters
{baseURI}
Supplies the base API URI to the triggered automation script.
cmd /c "C:\ai\ai.bat {baseURI}"
resolves to:
cmd /c C:\ai\ai.bat https://lims.lan.29/api/
cmd /c "C:\ai\ai.bat {baseURI}v2"
resolves to:
cmd /c C:\ai\ai.bat https://lims.lan.29/api/v2
NOTE: To access the endpoints, make sure that the {baseURI} is appended with v2. You can include this in the token in the command line, as shown above, or in the script itself.
{projectLuid}
Supplies the URI of the step to the triggered automation script. Include the version parameter (ie, {stepURI:version}) to specify the version of the REST API to be accessed.
cmd /c "C:\ai\ai.bat {C:\ai\ai.bat {projectLuid}"
resolves to:
cmd /c C:\ai\ai.bat ADM123
{username}
Supplies the username of the current user running the step to the triggered automation script
cmd /c "C:\ai\ai.bat {username}"
resolves to:
cmd /c C:\ai\ai.bat adminuser
{password}
Supplies the password of the current user running the step to the triggered automation script.
cmd /c "C:\ai\ai.bat {password}"
resolves to:
cmd /c C:\ai\ai.bat 3BlindMice
In log files, the password supplied on the command line is replaced with a series of *** characters.
{baseURI}
Supplies the base API URI to the triggered automation script.
cmd /c "C:\ai\ai.bat {baseURI}"
resolves to:
cmd /c C:\ai\ai.bat https://lims.lan.29/api
{stepURI}
Supplies the URI of the step to the triggered automation script. Include the version parameter (ie, {stepURI:version}) to specify the version of the REST API to be accessed.
cmd /c "C:\ai\ai.bat {stepURI:v2}"
resolves to:
cmd /c C:\ai\ai.bat https://yourServerNameOrIP/api/v2/steps/CAM-CSB-100212-24-197
{artifactsURI}
Supplies the URI of the artifacts root to the triggered automation script.
Include the version parameter (ie, {artifactsURI:version}) to specify the version of the REST API to be accessed.
cmd /c "C:\ai\ai.bat {artifactsURI:v2}"
resolves to:
cmd /c C:\ai\ai.bat https://yourServerNameOrIP/api/v2/artifacts
{processURI}
{stepURI} token is preferred.
{processURI} is deprecated and less accurate. May be removed in future versions.
Supplies the URI of the step to the triggered automation script.
If using the deprecated {processURI} token, the addition of the version and scheme parameters is recommended ({processURI:version:scheme}).
Adding the version and scheme reduces the chance of a server and REST version upgrade unknowingly affecting your scripts.
cmd /c "C:\ai\ai.bat {processURI:v2:http}"
resolves to:
cmd /c C:\ai\ai.bat https://yourServerNameOrIP/api/v2/processes/CAM-CSB-100212-24-197
{processLuid}
Supplies the LIMS ID of the step that triggered the automation script.
cmd /c "C:\ai\ai.bat {processLuid}"
resolves to:
cmd /c C:\ai\ai.bat CAM-CSB-100212-24-169
{udf:nameOfUDF}
Supplies the current value stored within a UDF configured as nameofUDF.
cmd /c "C:\ai\ai.bat {udf:injection_volume}"
resolves to:
cmd /c C:\ai\ai.bat 12.4
{parentProcessUdf:nameOfUDF}
Supplies the current value stored within a UDF configured as nameofUDF of the immediate parent step to the step that triggered the automation script.
The parent step must provide the inputs (derived samples) to the step.
In cases where there are multiple parents (ie, the inputs are derived from various steps) only the first of these parents is returned.
cmd /c "C:\ai\ai.bat {parentProcessUdf:RunID}"
resolves to:
cmd /c C:\ai\ai.bat RUN_BW1765
{parentProcessUdfN:nameOfUDF}
Supplies the current value stored within a UDF configured as nameofUDF of the immediate parent step to the step that triggered the automation script. The parent step must provide the inputs (derived samples) to the step.
In cases where there are multiple parents (ie, the inputs are derived from various steps) all parent step IDs are treated as an array-based list.
N specifies the array list index position 0..n of the desired step.
{parentProcessUdf0:nameofUDF} is equivalent to {parentProcessUdf:nameofUDF}.
cmd /c "C:\ai\ai.bat {parentProcessUdf1:RunID}"
resolves to:
cmd /c C:\ai\ai.bat RUN_HJ1865
{outputFileLuids}
Supplies the LIMS IDs of all step output file placeholders.
cmd /c "C:\ai\ai.bat {outputFileLuids}"
resolves to:
cmd /c C:\ai\ai.bat "BAR103A1CO248" "BAR103A1CO249" "BAR103A1CO250" "BAR103A1CO251" "BAR103A3CO158" "BAR103A3CO159" "BAR103A3CO160" "BAR103A3CO161"
{outputFileLuidN}
Supplies the LIMS ID for the specified step output file placeholder. All output file placeholders applying to inputs of the step are treated as an array-based list, where N specifies the array list index position [0..n] of the desired file.
Assuming the same eight output files as in the previous example:
cmd /c "C:\ai\ai.bat {outputFileLuid0}"
resolves to:
cmd /c C:\ai\ai.bat BAR103A1CO248
cmd /c "C:\ai\ai.bat {outputFileLuid1}"
resolves to:
cmd /c C:\ai\ai.bat BAR103A1CO249
cmd /c "C:\ai\ai.bat {outputFileLuid7}"
resolves to:
cmd /c C:\ai\ai.bat BAR103A3CO161
{compoundOutputFileLuids}
Supplies the LIMS IDs for all shared step output file placeholders.
cmd /c "C:\ai\ai.bat {compoundOutputFileLuids}"
resolves to:
cmd /c C:\ai\ai.bat "92-527" "92-528" "100-541" "100-544"
{compoundOutputFileLuidN}
Supplies the LIMS ID for the specified step output file placeholder that applies to an individual input. All output file placeholders applying to individual inputs for the step are treated as an array-based list, where *N specifies the array list index position [0..n] of the desired file.
Assuming the same four output files as in the previous example:
cmd /c "C:\ai\ai.bat {compoundOutputFileLuid0}"
resolves to:
cmd /c C:\ai\ai.bat 92-527
cmd /c "C:\ai\ai.bat {compoundOutputFileLuid1}"
resolves to:
cmd /c C:\ai\ai.bat 92-528
cmd /c "C:\ai\ai.bat {compoundOutputFileLuid2}"
resolves to:
cmd /c C:\ai\ai.bat 100-541
cmd /c "C:\ai\ai.bat {compoundOutputFileLuid3}"
resolves to:
cmd /c C:\ai\ai.bat 100-544
Deprecated {parentProcessLuid*} tokens
The following tokens have been deprecated:
• {parentProcessLuid}
• {parentProcessLuids}
• {parentProcessLuidN}
These tokens were only applicable to steps that take file inputs. File inputs are no longer supported in the Clarity LIMS.
-u {user} | LIMS username |
-{password} | LIMS password |
-l {stepURI} | LIMS stepURI—the URI of the transient step API resource that invokes the script. |
-s {status} | The status the script is reporting (OK, WARNING, or ERROR). |
-m {message} | The descriptive message displayed to the user. |