Content |
|||||||||||||||||||||||
|
Overview |
|
|
This is conceptual information regarding Workflow Definitions and Executions.
Adding SDIs to a Workflow |
|
|
Example |
The Example Workflow we demonstrated creates its own Samples in the "Sample Login" Task, but how do we add Samples to a Workflow if the Samples already exist? For example, if we remove the "Login Sample" task and make "Manage Samples" the "Start Task", we must find a way to get Samples into the "Manage Samples" Task:
|
The next sections show several approaches to this.
SDI List Pages |
The advancedtoolbar Element supports a standard button that lets you add selected SDIs on an SDI List page to a nominated Workflow. The Sample List page is preconfigured with this button (although you can configure this button on any SDI List or SDI Maintenance page if desired). Selecting Samples and clicking "Add to Workflow" prompts for the Workflow Execution. The selected SDIs will be added to the Workflow Execution of your choice.
|
AddToWorkflow Action |
The AddToWorkflow Action adds an SDI to a specific Workflow or Workflow Execution and can optionally specify a specific Start Task and/or Queue.
Templates and Test Methods |
Detail Elements of Sample Templates and Test Methods contain a "Workflow" tab that can specify the Workflow Execution to which the Sample (or Test) is added. You must select a Workflow with a Start Task that has an Input Queue so Samples have a place to enter the Workflow.
For Templates, this specifies the Workflow to which newly created SDIs are added:
|
For Test Methods, you can choose whether this affects the Sample to which the Test is added ("Primary" shown below) or the newly created Test ("Test Method" shown below), such that when the Test is added to a Sample, the Sample will be automatically added to the specified Workflow:
|
Event Plans |
In Event Plans, you can add SDIs to a Workflow after an Event (such as Sample creation or after a status change). You can pass the SDI involved in the Event added to a Workflow by calling the AddToWorkflow Action, or by clicking "Add Workflow" (below), which embeds a Workflow directly into the Event Plan. A preview of the chosen Workflow is in the detail tab:
|
Workflow Execution Types |
|
|
"Workflow Execution Types" are based on a logical distinction between "Workflow Definitions" and "Workflow Executions" as described in this section.
Single Execution |
"Single Execution" is the simplest Execution Type. There is one "Workflow Definition" and one "Workflow Execution" for that definition. Single Executions work in a "continuous" fashion, with new SDIs getting added to the first input to the Workflow, potentially merging with SDIs that have already progressed further through the Workflow. This will likely be your first choice for executing Workflows, as it works in a "continuous" cascading manner that maps well onto many business processes.
Named Execution |
"Named Executions" behave the same as Single Executions, except that one Workflow Definition can have multiple Workflow Executions. Reasons for creating multiple named executions might be:
| • | Separation of workstreams (Projects, Departments, etc.) or context. |
| • | Ability to run the same process or experiment multiple times, each with different setup conditions (such as oven temperature, Consumable Type, etc.) |
In general, Named Executions typically rely on the fact that the behavior of the Workflow can be modified by providing values for Workflow Setup Variables. It follows that each Named Execution will typically have different values for its Workflow Setup Variables.
Named Executions are useful when a fixed procedure can be executed in a set of distinct and isolated contexts (such as Departments or Projects) or under a variety of conditions (such as different environmental temperatures or formulative ingredients).
Recall that you can add SDIs to a Workflow through SDI List pages, the AddToWorkflow Action, SDI Templates, Test Methods, and Event Plans. When adding SDIs to a Named Execution, you must indicate the specific Workflow Execution to which the the SDI will be added.
As an example, the Workflow Definition shown below could force you to choose the Sample Template when you run the Task:
 |
An alternative would be to create one Workflow Execution per Template in the Workflow Definition, thus letting the Workflow choose. In the Workflow Definition, create a Workflow Setup Variable called "template" as shown below (note that "Setup Variable" is checked in the "Add Variable" dialog):
 |
Map the Workflow Setup Variable onto the Task Setup Variable by selecting "template" from the "Load From Workflow Variable" dropdown (and uncheck "Show Template Selection", since the User will be doing the selecting):
 |
Now, change the Workflow Execution Type to "Named Executions":
 |
When you create a "New Execution" in the Workflow Manager, you are prompted to provide values for the Workflow Setup Variables. Here, we named the new Execution the same as the Template:
 |
Repeating these operations, you can create multiple Named Executions, each creating a different type of Sample type:
 |
Auto Execution |
"Auto Execution" automatically creates a new Workflow Execution either:
| • | Each time the AddToWorkflow Action is called (this can add multiple SDIs into a single Auto Execution). |
| or... | |
| • | Each time a Start Task that creates new SDIs is executed (such as LoginSample). |
Here are some rules and guidelines for using Auto Executions:
| • | Give each Auto Execution a meaningful label to distinguish it from all other groups. By default, an Auto Execution picks up the name of the first SDI added to it. |
| • | Once an Auto Execution has started, you cannot add additional SDIs to it. Adding SDIs to an Auto execution in process spawns new Executions. However, the Workflow Manager contain Queue-level maintenance tools that can override this restriction if necessary. |
| • | You can use Workflow Setup Variables with Auto Executions, but only when SDIs are added to the Workflow using the "Add to Workflow" button on SDI List pages, or by defining a Workflow Setup Variable for the AddToWorkflow Action. |
| • | When the Input Queues to all Tasks are empty, the Execution is Complete. Auto Executions have a beginning and an end, as opposed to Single and Named Executions (which do not have a specific end condition). Because of the specific end condition, Auto Executions are useful when a specific "Workflow Report" is required to summarize a single occurrence of an experiment. |
Auto Execution is useful when SDIs must be processed as a group, and each SDI (or group of SDIs) must be kept separated from all other SDIs. This will likely involve lower volumes to reduce the risk of an unmanageable numbers of Executions.
For example, the Workflow below is an Auto Execution:
 |
In the Workflow Manager, you will find that you cannot create a "New Execution":
 |
Now go to the Sample List page. Select a Sample, then click "Add to Workflow". Choose the Auto Execution Workflow (provide a different name if you like), and the Sample is added to the Task Queue:
 |
If you return to the Workflow Manager, you will see that an Execution has been automatically created:
 |
If you add more Samples to the Workflow, a new Workflow Execution will be created for each group of Samples added.
Workflow Variables |
|
|
As is the case with Tasks, Workflows can also have Variables. They are much simpler than Task Variables and are restricted to String data type. Workflow Variables:
| • | Ensure that all Task Setup Variables in multiple Tasks are set to the same value. |
| • | Allow different Workflow behaviors when creating Named Executions. |
| • | Pass information (other than Queue items) from one Task to another. |
Suppose three separate Tasks send an email to the same User:
 |
Rather than specifying the email address three times, you can create a Workflow Variable to hold the address:
 |
Now that there ia a Workflow Variable defined, you can map the Task Setup Variables for the three eMail Tasks to the Workflow Variable:
 |
| NOTE: | Newly created Workflow Variables are forced to lower case. |
Start Tasks and End Tasks |
|
|
A "Start Task" is a Task that can start a Workflow (such as "Login Sample") or a Task to which SDIs can be added (such as "Manage Samples"). A Workflow can contain one or more Start Tasks. Start Tasks are identified by a green arrow in the bottom left corner as shown below.
You can nominate a Task to be an "End Task". Using an End Task is not mandatory, since SDIs can just "fall off the end" of a Workflow. The reason for using an "End Task" is that an SDI generates an Event through the Event Plan functionality when the SDI "completes" the Workflow. You can use this Event to trigger the execution of a new Workflow or to resume another paused Workflow. End Tasks are identified by a red square in the bottom left corner as shown below.
|
Utility Tasks |
|
|
LabVantage provides these OOB "Utility" Tasks for performing basic operations or controlling flow:
| Type of Utility Task | Description |
| Converters | Swaps one set of SDIs for another. For example, "Convert Batch to Sample" accepts a Batch as input and outputs all Batch Samples. See Converters for details. |
| Notifications | Sends a Bulletin or email to one or more Users. See Notifications for details. |
| Splitters | Sends SDIs down two or more different branches, depending on a specified set of criteria. See Splitters for details. |
| Waits | Waits for an event on a Queue item to occur in the system. Queue items will proceed when the event occurs. See Waits for details. |