Conditions¶

Conditions are made of predicates that can be nested as desired using logical operators - and, or and not. There are predefined predicates available in selinon.predicates. However you can define your own predicates based on your requirements.

These conditions are evaluated by dispatcher and if a condition is met, desired node or nodes are scheduled. If the condition is evaluated as false, destination nodes on the given edge are not run. Note that conditions are run only once only if all source nodes successfully finish.

If you do not state condition in edge definition, edge condition will be evaluated always as true.

Since there could run multiple nodes of a type (name) due to cyclic dependencies, an edge condition is evaluated for each possible combination (and only once for the given combination). If you want to avoid such behaviour, check Useful flow patterns section for possible solutions.

Starting nodes¶

You can have a single or multiple starting nodes in your flow. If you define a single starting node, the result of starting node can be propagated to other nodes as arguments if node_args_from_first is set. If you define more than one starting node, the result cannot be propagated (due to time-dependent evaluation), however you can still explicitly define arguments that are passed to the flow (or make part of your flow a sub-flow).

Flows¶

Flows can be nested as desired. The only limitation is that you cannot now inspect results of sub-flow using edge conditions in a parent flow. There is a plan to remove such limitation in next Selinon releases. Nevertheless you can still reorganize your flow (in most cases) so you are not limited with such restriction.

Running a flow¶

Once you set up Selinon and Selinon does not report any errors in your configuration files, you can run flow simply by calling the run_flow function (see documentation of run_flow()):

from selinon import run_flow

dispatcher_id = run_flow('flow1', {'foo': 'bar'})

If you wish to do selective task runs, please refer to Selective task run documentation.

Node failures¶

You can define fallback tasks and fallback flows that are run if a node fails. These fallback tasks and flows (fallback nodes) are not prone to time-dependent evaluation (to be more precise - there is no such thing in the whole Selinon design, so you can be sure that such thing does not occur on Selinon level). These fallback nodes are scheduled on task or flow failures and their aim is to recover from a failure.

Failures are propagated from sub-flows to parent flows. You can find analogy to exceptions as known in many programming languages (like in Python). If a node fails and there is no fallback node that would handle node failure, the whole flow is marked as failed. You can than capture this failure in the parent flow, but this failure will be marked as failure of the whole flow. Note that even in this case, there is no time-dependent evaluation - so if a node in your flow fails, dispatcher can still continue scheduling nodes that are not affected by the failure and once there is nothing to do more, dispatcher marks the flow as failed.

Now let’s assume that you defined two fallbacks. One waits for Task2 failure (Fallback1) and another one waits for a failure of Task1 as well as Task2 failure (Fallback2).

Let’s say that Task1 failed. In that case the decision which fallback would be run depends on Task2 failure (not on time-dependent evaluation). Fallback evaluation is greedy, so if Task2 fails, there is run Fallback2. If Task2 succeeds, Fallback1 is run.

Results of tasks¶

Results of tasks are stored in databases transparently based on your definition in YAML configuration files. The only thing you need to provide is a database adapter that handles database connection and data storing/retrieval. See storage section for more info.

YAML configuration example¶

In this section you can find YAML configuration files that were used for generating images in the previous sections. You can separate flows into multiple files, just provide flow-definitions key to find all flows defined in the YAML file.

---
  flow-definitions:
    - name: 'flow1'
      edges:
          - from:
            to:
              - 'Task1'
          - from:
              - 'Task1'
            to:
              - 'Task2'
              - 'flow2'
            condition:
                name: 'fieldEqual'
                node: 'Task1'
                args:
                    key: 'foo'
                    value: 'bar'
          - from:
              - 'Task2'
              - 'flow2'
            to:
              - 'Task3'
          - from:
              - 'Task3'
            to:
              - 'Task1'
            condition:
                name: 'argsFieldEqual'
                node: 'Task3'
                args:
                    key: 'foo'
                    value: 'bar'

---
  flow-definitions:
    - name: 'flow2'
      edges:
          - from:
            to:
              - 'Task4'
          - from:
              - 'Task4'
            to:
              - 'Task5'

Configuration for failures and failure handling fallbacks that were introduced in Node failures section can be found bellow (no storages in the example).

---
  flow-definitions:
    - name: 'exampleFallback'
      edges:
        - from:
          to: 'Task1'
        - from:
          to: 'Task2'
      failures:
        - nodes:
            - 'Task1'
            - 'Task1'
          fallback:
            - 'Fallback1'
        - nodes:
            - 'Task1'
          fallback:
            - 'Fallback2'