<commit_before>---
layout: page
title: Documentation
countheads: true
toc: true
comments: true
---

{% danger_block %}

Work in progress! It contains a lot of tpyos, please let us know. There are comments at the bottom
or you can submit a PR against [pages branch](https://github.com/dynflow/dynflow/tree/pages).

Please help with the documentation if you know Dynflow.

Thanks!

{% enddanger_block %}

## High level overview TODO

*TODO to be refined*

Dynflow (**DYN**amic work**FLOW**) is a workflow engine
written in Ruby that allows to:

-   Keep track of the progress of running processes
-   Run the code asynchronously
-   Resume the process when something goes wrong, skip some steps when needed
-   Detect independent parts and run them concurrently
-   Compose simple actions into more complex scenarios
-   Extend the workflows from third-party libraries
-   Keep consistency between local transactional database and
    external services
-   Suspend the long-running steps, not blocking the thread pool
-   Cancel steps when possible
-   Extend the actions behavior with middlewares
-   Pick different adapters to provide: storage backend, transactions, or executor implementation

Dynflow has been developed to be able to support orchestration of services in the
[Katello](http://katello.org) and [Foreman](http://theforeman.org/) projects.

*TODO*

-   what problems does Dynflow solve?
-   maybe a little history

## Glossary TODO

*TODO to be refined*

-   **Action** - building block of execution plans, a Ruby class inherited
    from `Dynflow::Action`, defines code to be run in each phase.
-   **Phase** - Each action has three phases: `plan`, `run`, `finalize`.
-   **Input** - A `Hash` of data coming to the action.
-   **Output** - A `Hash` of data that the action produces. It's
    persisted and can be used as input of other actions.
-   **Execution plan** - definition of the workflow: product of the plan phase
-   **Triggering an action** - entering the plan phase, starting with the plan
    method of the action. The execution follows immediately.
-   **Flow** - definition of the `run`/`finalize` phase, holding the information
    about steps that can run concurrently/in sequence. Part of execution plan.
-   **Executor** - service that executes the run and finalize flows based on
    the execution plan. It can run in the same process as the plan phase or in
    different process (using the remote executor)
-   **World** - the universe where the Dynflow runs the code: it holds all
    needed configuration. Usually there's only one world per Dynflow process,
    besides configuration it also holds `Persistence`, `Logger`, `Executor` and<commit_msg>Finalizing Glossary<commit_after>---
layout: page
title: Documentation
countheads: true
toc: true
comments: true
---

{% danger_block %}

Work in progress! It contains a lot of tpyos, please let us know. There are comments at the bottom
or you can submit a PR against [pages branch](https://github.com/dynflow/dynflow/tree/pages).

Please help with the documentation if you know Dynflow.

Thanks!

{% enddanger_block %}

## High level overview TODO

*TODO to be refined*

Dynflow (**DYN**amic work**FLOW**) is a workflow engine
written in Ruby that allows to:

-   Keep track of the progress of running processes
-   Run the code asynchronously
-   Resume the process when something goes wrong, skip some steps when needed
-   Detect independent parts and run them concurrently
-   Compose simple actions into more complex scenarios
-   Extend the workflows from third-party libraries
-   Keep consistency between local transactional database and
    external services
-   Suspend the long-running steps, not blocking the thread pool
-   Cancel steps when possible
-   Extend the actions behavior with middlewares
-   Pick different adapters to provide: storage backend, transactions, or executor implementation

Dynflow has been developed to be able to support orchestration of services in the
[Katello](http://katello.org) and [Foreman](http://theforeman.org/) projects.

*TODO*

-   what problems does Dynflow solve?
-   maybe a little history

## Glossary

-   **Action** - building block of execution plans, a Ruby class inherited
    from `Dynflow::Action`, defines code to be run in each phase.
-   **Phase** - Each action has three phases: `plan`, `run`, `finalize`.
-   **Input** - A `Hash` of data coming to the action.
-   **Output** - A `Hash` of data that the action produces. It's
    persisted and can be used as input of other actions.
-   **Execution plan** - definition of the workflow: product of the plan phase,
-   **Triggering an action** - entering the plan phase, starting with the plan
    method of the action. The execution follows immediately.
-   **Flow** - definition of the `run`/`finalize` phase, holding the information
    about steps that can run concurrently/in sequence. Part of execution plan.
-   **Executor** - service that executes the run and finalize flows based on
    the execution plan. It can run in the same process as the plan phase or in
    different process (using the remote executor).
-   **World** - the universe where the Dynflow runs the code: it holds all
    needed configuration. Usually there's only one world per Dynflow process,
    besides configuration it also holds `Persistence`, `Logger`, `Executor` and
{'fraction_non_alphanumeric': 0.07722439843312814, 'fraction_numerical': 0.0, 'mean_word_length': 3.7747105966162064, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4924781', 'n_tokens_mistral': 1431, 'n_tokens_neox': 1381, 'n_words': 717}