GET
Displays a list of processes that have been run in the system. If the number of processes returned exceeds the display maximum, the results are paged.
When submitting a GET request, you can use the following query parameters to filter the results. For more information about using query parameters, please refer to [REST:Filtering list resources].
Parameters
| name | description | type | default |
|---|---|---|---|
| start-index | When working with large lists of results, displays the results from a set point. If omitted, the first page of results is returned. | query | 0 |
| last-modified | Displays only the processes modified since the specified date, in YYYY-MM-DDThh:mm:ssTZD format. For more information on this format, please refer to the ISO 8601 Complete Date (plus hours, minutes and seconds) standard. | query | |
| type | Displays only the processes whose type matches the specified value (the name of the process in the client). When filtering results, you can repeat this parameter. | query | |
| inputartifactlimsid | Displays only the processes whose input artifacts include the specified artifact LIMS ID. When filtering results, you can repeat this parameter. | query | |
| udf.UDFNAME\[OPERATOR\]=UDFVALUE | Displays only processes that include the specified UDF value. The system will only return processes with standalone UDFs; it will not return processes with UDFs that belong to a UDT. When filtering results, you can repeat this parameter. | query | |
| udt.name=UDTNAME | Displays only processes that include data for the specified UDT name. When filtering results, you can repeat this parameter. | query | |
| udt.UDTNAME.UDFNAME\[OPERATOR\]=UDFVALUE | Displays only processes that include the specified value for a UDF within a UDT. The system will only return processes with UDFs that belong to a UDT; it will not return processes with standalone UDFs. When filtering results, you can repeat this parameter. | query | |
| techfirstname | Displays only the processes whose researcher's first name matches the specified value. When filtering results, you can repeat this parameter. | query | |
| techlastname | Displays only the processes whose researcher's last name matches the specified value. When filtering results, you can repeat this parameter. | query | |
| projectname | Displays only the processes whose input artifacts are related to a submitted sample in the specified project (the name of the project). When filtering results, you can repeat this parameter. | query |
Output Payload
| element | produceable content type(s) |
|---|---|
| processes (XML) |
|
| description | |
| The system returns a response that includes a list of processes and URI links, starting from the start-index offset. | |
POST
Creates (runs) a process.
When posting processes, the following rules apply:
- Before you can post a process, a process type with the provided name must exist in the system and be enabled.
- You must supply a reference to a Technician that corresponds with a user in the system.
- You can only post configured processes. For more information about Clarity LIMS process types, see [Understanding process types|https://documentationgls.atlassian.net/wiki/display/DOC/Understanding+process+types] in the Clarity LIMS Lab Manager Guide at [http://documentation.genologics.com].
- The parameter is a child element of process execution that integrates the Process with the External Program Integration plug-in (EPP). When a user runs the Process, the system automatically issues a command configured in the process parameter this element represents.
When working with input/output maps (the inputs and outputs of a process), the following rules apply:
- The inputs you specify must match what the process type is configured to accept as an input.
- The input artifacts you specify must exist in the system.
- The outputs you specify must match what the process type is configured to produce as an output.
- The output containers you specify must exist in the system. The specified well location must exist in the container and be available (empty and not reserved).
- You cannot place more than one output into the same well of a container.
- You cannot associate two inputs with the same output, unless it is a shared output.
- A process always creates a variable number of outputs, which can equal zero.
- A process always creates an output for each reagent label applied to an input.
When working with process-level User-Defined Fields and User-Defined Types, the following rules apply:
- The UDFs and UDTs that you refer to must be configured for the type of process you are working with.
- You must provide any UDFs or UDTs that are configured in the system as a required item.
When working with QC options, the following rules apply:
- You can apply QC values to the inputs or outputs of any type of process.
- If an input has QC information specified multiple times (i.e. multiple outputs per input case), only the first setting is considered
- QC inheritance will be applied if the process type is configured to 'Apply the QC flags of the inputs to the outputs' and no QC flags are provided for the entire process execution request.
Example XML to transfer a single sample to a new container where the server is localhost. The container, input and researcher uri's will need to match your system
{code:xml}{code}
Input Payload
| element | consumeable content type(s) |
|---|---|
| process (XML) |
|
| description | |
| The representation of the process creation. | |
Output Payload
| element | produceable content type(s) |
|---|---|
| process (XML) |
|
| description | |
| HTTP Status 201 (Created) with the URI for the new process in the Location header of the response. The representation for the newly created process will be returned as the response body. | |