Workflows & Activities
Workflows
Orchestrator differentiates two different aspects of a workflow, Design Time and Runtime.
During design time, the workflow itself, its arguments, variables, activities and their relations to each other are defined. These representations of workflows are used to determine the lifecycle of a workflow.
From these representations, the runtime representations are derived. The definitions are processed, parsed and compiled into executable workflows. They are then hosted within the Workflow Engine and can be executed through different kinds of triggers.
Workflow Information & Details
The WorkflowInformation class contains all metadata regarding a workflow and contains the following properties.
| Property | Description | Type |
|---|---|---|
ID |
Unique identifier of the workflow. |
string |
Name |
The name of the workflow. (Used to execute the workflow) |
string |
Description |
The description of the workflow. |
string (optional) |
DefaultVersion |
The version of the workflow that is going to be executed if no version is specified. |
int |
Status |
The status of the overall workflow. |
WorkflowStatus (Draft, Active, Disabled, Deleted) |
The WorkflowDetails class extends the WorkflowInformation class and acts as a envelope for one or more versions of the workflow.
It adds the following information.
| Property | Description | Type |
|---|---|---|
Versions |
List of version numbers available for this workflow |
List<int> |
Workflow Version
The WorkflowVersion class represents one specific version of a workflow implementation.
A WorkflowVersion is immutable, i.e. once created, it cannot be altered anymore.
Changes in the expected behavior of a workflow have to be done by creating a new version based on the latest existing version.
The WorkflowVersion class contains all information necessary for creating an executable workflow in the workflow engine.
Activities
Activities are the atomic building blocks that make up the structure of a workflow and define the execution flow based on their relation to each other. All of this is defined in a Workflow Version.
Similar to Workflows, Activities can be versioned. Meaning their behavior can be adapted or extended over time. A Workflow Version therefore always refers to an activity in a certain version.
Activity Types
In Orchestrator there are two different kinds of activities that can be used to construct a workflow.
Primitive Activities
Primitive Activities are all-purpose activities that are likely to be used in any kind of workflow. They are mainly intended to control the actual structure of the workflow. Currently following activities exist:
Set |
Assigns a value to a given variable / argument |
|---|---|
If |
Branches the workflow into two branches (true & false) based on a given condition |
Switch |
Branches the workflow into multiple branches based on the value of a given variable / argument |
TryCatch |
Tries to execute another activity and can execute another activity in case of an error |
Foreach |
Loops over a given list of items and executes an activity, keeping track of the current item in the list |
While |
Executes another activity while a certain condition applies |
Container |
Groups a set of activities and executes them according to their relations |
Execution Activities
The other type of activities are Execution Activities, which are intended to execute a single atomic action (e.g. call a REST API, copy a file, …). Execution Activities are also the basis for all custom activities that can be added to Orchestrator.
Activity Describers
A given workflow version doesn’t directly refer to a certain activity but rather to a so called Activity Describer. An Activity Describer is the blueprint of a certain activity in a certain version. The describer contains all necessary information which is later used to create the actual executable workflow in the engine.
Describers for Execution Activities are automatically generated based on their defined interface, while describers for Primitive Activities need to be specifically created, in order to account for their special functionality.
Relations
Activities can contain certain relations, which are used to define the flow of execution in the workflow. Execution Activities are only intended to be called sequentially, i.e. they shouldn’t branch the flow of execution. Therefore they contain a single relation to the next activity that should be executed after itself. Certain Primitive Activities might contain two or more relations. The If activity for example contains two relations, one for each branch that can be executed. If no value is provided for a certain relation, this marks the end of execution for a given workflow.