TABLE OF CONTENTS
- General concepts
- Dynamic workflows and Workflow steps
- Workflow template structure and hierarchy
- Workflow elements
- Flow and flow control
Workflow Templates and Workflow Runs
Workflows in Laboperator provide a powerful tool to orchestrate devices and data with information and control elements which enable lab scientists to create a digital twin of their processes in the laboratory. Workflows operate as a connecting layer between the device integration layer harmonizing device interfaces, commands and data and the API layer which provides data, commands and resources in a unified format to third parties. Workflows can be utilized to provide the full scope if functionalities of a Laboratory Execution System (LES).
Workflows are defined and described in Workflow Templates, which can then be instantiated via execution as Workflow Runs. Workflow Templates are authored as YAML files and can be uploaded and shared by any roles within an organisation and collection which have the required privileges. Once uploaded, Workflow Templates exist as resources in a collection and can be executed by any roles with the required privileges. Changes and parameterization of the Workflow Templates is only possible within the degrees of freedom defined and allowed in the YAML file.
The procurement and instantiation lifecycle of Workflow Templates, Workflow Step Templates and Workflow Runs is outlined below:
Since Workflows are highly customizable and can be arbitrarily complex, this chapter aims at giving a high-level overview of the hierarchical structure and general principles of Workflow templates. It is meant to provide an orientation to the Workflow Template Schema which provides additional detail and functional information.
YAML-file based templating
As a data serialization language that is both human-readable and machine-readable, YAML is the optimal format to allow the authoring of both simple and complex workflows using a predefined schema for defining appearance, functionality and logic within a workflow.
YAML files can be regarded as a script which is then executed by the Laboperator server as an interpreting engine.
All Workflow Templates have a UUID and a Version which is unique to an organization within Laboperator, meaning that a YAML file with the same UUID and Version cannot be added if the same combination of UUID and Version already exists within the Organization. YAML template files also have a distinct structure which is explained on a high level in what follows.
The complete YAML schema definition for Workflows can be found here.
Dynamic workflows and Workflow steps
In addition to defining entire Workflows within a Workflow Template, modular steps can be defined as Workflow Steps, which can be added to and combined into Workflows both at design time and at run time. Examples for Workflow Templates may i.e. be a dissolution test, where a weighing step for the sample to be dissolved may be represented by a Weighing Step, which may then be re-used within other workflows and protocols.
Workflow Step templates can be uploaded, managed and executed the same way as Workflow Templates. They also share similar schemata and can be enriched by Workflow elements in the same way.
Details on the schema definitions can be found here:
Design-time loading of Workflow Steps
When designing a Workflow Template as a YAML file, Workflow Steps can be added to the Workflow Template by referencing the UUID and Version as the unique identifiers of a Workflow Step Template. All properties of the Workflow Step Template are then defined in a separate unique resource representing the Workflow Step Template.
When running a Workflow Run with an underlying Workflow Template to which a Workflow Step Template has been referenced, it is required that the executing operator has the access and privileges required to load and execute the template, otherwise, an error will be raised.
Run-time loading of Workflow steps
At run time, Workflow steps which have previously been uploaded and shared as Workflow Step Templates within an Organization or Collection can be appended (i.e. added to the end) to a Workflow Run that is not finalized or locked.
Workflow template structure and hierarchy
On a high level, a Workflow Template YAML file can be divided in three parts: Header, Content Elements, Step Definitions and Flow.
The YAML file header contains all workflow metadata metadata that is summarized in the Info Section schema.
Step definitions list the different steps, in which all the user interface (UI) Elements encapsulated which make the data visible and controls available to the user. These include, but are not limited to images, buttons, visualization elements like gauges or line graphs, input fields, dropdown menus and many more. Workflow Steps are also usually the place where behaviors (consisting of triggers and actions) are managed as well as calculations and scripts.
Within steps, variables can also be locally defined as Fields. Locally defined Fields are not available outside the scope of a step.
In the Flow section, the Workflow Template YAML file defines the sequential order in which the Workflow Steps in the previous sections are executed during the Workflow Run. Conditional and branching logic can be defined in the flow section as well.
Additional information can be found in the Flow Section schema description.
This chapter summarizes a high-level overview of visual, functional, logic and UI elements that can be utilized within a Workflow Template YAML file. For a complete overview and additional details, please refer to the Laboperator Workflow Schema Index.
|Workflow Element||High-level description||Schema Reference|
|Fields||Fields can be used on a global level and within Step Definitions to store variables and data points. Formatting options exist and they can be used as variables, inputs and display option.||Link|
|Context Info||Context Info can be used to display static and dynamic information in a viewport which is available during the entire Workflow and can be collapsed and expanded.||Link|
|Navigation Elements||Navigating to the previous or next step, repeating steps||Link|
|Media & Content||Different media (i.e. images and videos) as well as in-built data displays (i.e. gauges) can be displayed in a Workflow Step or Substep||Link Media |
|Behaviours||Bahaviours can be used to execute actions (i.e. send command to device, send alert, next step etc.) in response to triggers (i.e. temperature above threshold, button pressed, step started etc.) A complete list of available actions and triggers can be found in the linked schema description.||Link Triggers|
|Alerts||Alerts can be raised as an action and can be defined in terms of broadcasting channel according to the linked schema.||Link|
|Webhooks||Webhooks can be fired off as an action as a response to a trigger. Webhook URLs have to be authorized by an organisation administrator.||Link|
|Timers||Timers can be used as countdown or as forward counting timers. They can both be controlled by triggers, and can trigger actions by themselves.||Link|
|Scans||Registered scanners can set off triggers in workflows as well in addition to acting as a keyboard.||Link|
|Calculations||Arithmetic calculations can be used as part of a script field to calculate values from constants and values from other fields.||Link|
|Buttons||Buttons can be used to manually trigger actions within a workflow.||Link|
Flow and flow control
Additional options for conditional flow and loops are listed in a high-level overview below.
|Sequential Flow||As a default option, sequential flow describes in the sequential order in which steps defined within the workflow or loaded into the workflow are executed.||Link|
|Parallel Flow||Parallel flow allows the parallel execution of nested sequences. Additional information can be found in the linked schema.||Link|
|While Flow||Within a While Flow, steps or sequences of steps can be repeated as long a predefined condition is met. More details are described in the linked schema.||Link|
|Loop Flow||Within a While Flow, steps or sequences of steps can be repeated until a predefined condition is met. More details are described in the linked schema.||Link|
|If-Then-Else Flow||An IF-Then-Else Flow allows the conditional branching of sequential flow. Additional details can be found in the linked schema.||Link|
|For-Each Flow||A For-Each Flow repeats a certain sequence with a predefined set of conditions, either a series of integers or a predefined data array. Additional details can be found in the linked schema.||Link For-Each Integer|
Link For-Each Array