Bases: object
Workflow Controller base class.
Different workflow controllers implement different workflow algorithms. In practice it may actually mean that there may be multiple ways of describing workflow models (and even languages) that will be supported by Mistral.
Determines if all errors (if any) are handled.
| Returns: | True if either there aren’t errors at all or all errors are considered handled. |
|---|
Determines if there are any task cancellations.
| Returns: | True if there is one or more tasks in cancelled state. |
|---|
Calculates a list of commands to continue the workflow.
Given a workflow specification this method makes required analysis according to this workflow type rules and identifies a list of commands needed to continue the workflow.
| Parameters: | task_ex – Task execution that caused workflow continuation. Optional. If not specified, it means that no certain task caused this operation (e.g. workflow has been just started or resumed manually). |
|---|---|
| Returns: | List of workflow commands (instances of mistral.workflow.commands.WorkflowCommand). |
Evaluates final workflow context assuming that workflow has finished.
| Returns: | Final workflow context. |
|---|
Determines a logical state of the given task.
| Parameters: | task_ex – Task execution. |
|---|---|
| Returns: | Tuple (state, state_info, cardinality) where ‘state’ and
‘state_info’ are the corresponding values which the given
states of other tasks. ‘cardinality’ gives the estimation on the number of preconditions that are not yet met in case if state is WAITING. This number can be used to estimate how frequently we can refresh the state of this task. |
Determines if error is handled for specific task.
| Parameters: | task_ex – Task execution. |
|---|---|
| Returns: | True if either there is no error at all or error is considered handled. |
Gets commands to rerun existing task executions.
| Parameters: |
|
|---|---|
| Returns: | List of workflow commands. |
Bases: mistral.workflow.commands.SetWorkflowState
Instruction to fail a workflow.
Bases: mistral.workflow.commands.WorkflowCommand
No-operation command.
Bases: mistral.workflow.commands.SetWorkflowState
Instruction to pause a workflow.
Bases: mistral.workflow.commands.WorkflowCommand
Command for running already existent task.
Bases: mistral.workflow.commands.WorkflowCommand
Instruction to run a workflow task.
Bases: mistral.workflow.commands.WorkflowCommand
Instruction to change a workflow state.
Bases: mistral.workflow.commands.SetWorkflowState
Instruction to succeed a workflow.
Bases: object
Workflow command.
A set of workflow commands form a communication protocol between workflow handler and its clients. When workflow handler makes a decision about how to continue a workflow it returns a set of commands so that a caller knows what to do next.
Bases: dict
Workflow context view.
It’s essentially an immutable composite structure providing fast lookup over multiple dictionaries w/o having to merge those dictionaries every time. The lookup algorithm simply iterates over provided dictionaries one by one and returns a value taken from the first dictionary where the provided key exists. This means that these dictionaries must be provided in the order of decreasing priorities.
Note: Although this class extends built-in ‘dict’ it shouldn’t be considered a normal dictionary because it may not implement all methods and account for all corner cases. It’s only a read-only view.
Bases: mistral.workflow.base.WorkflowController
‘Direct workflow’ handler.
This handler implements the workflow pattern which is based on direct transitions between tasks, i.e. after each task completion a decision should be made which tasks should run next based on result of task execution. Note, that tasks can run in parallel. For example, if there’s a workflow consisting of three tasks ‘A’, ‘B’ and ‘C’ where ‘A’ starts first then ‘B’ and ‘C’ can start second if certain associated with transition ‘A’->’B’ and ‘A’->’C’ evaluate to true.
The intention of the module is providing various DB related lookup functions for more convenient usage withing the workflow engine.
Some of the functions may provide caching capabilities.
WARNING: Oftentimes, persistent objects returned by the methods in this module won’t be attached to the current DB SQLAlchemy session because they are returned from the cache and therefore they need to be used carefully without trying to do any lazy loading etc. These objects are also not suitable for re-attaching them to a session in order to update their persistent DB state. Mostly, they are useful for doing any kind of fast lookups with in order to make some decision based on their state.
Bases: mistral.workflow.base.WorkflowController
‘Reverse workflow controller.
This controller implements the workflow pattern which is based on dependencies between tasks, i.e. each task in a workflow graph may be dependent on other tasks. To run this type of workflow user must specify a task name that serves a target node in the graph that the algorithm should come to by resolving all dependencies. For example, if there’s a workflow consisting of two tasks ‘A’ and ‘B’ where ‘A’ depends on ‘B’ and if we specify a target task name ‘A’ then the controller first will run task ‘B’ and then, when a dependency of ‘A’ is resolved, will run task ‘A’.
Valid task and workflow states.
Bases: object
Explicit data structure containing a result of task execution.
Bases: mistral.utils.serializers.Serializer