Find a file
Sipke Schoorstra 3a1ddb650f
Introduce token-centric Flowchart execution model with configurable MergeMode (#6632)
* Switch Flowchart to partial class and implement token-based logic

Refactored Flowchart to use a partial class structure for better modularity. Introduced a token-based execution option alongside the existing counter-based logic, enabling flexible activity scheduling strategies within the flowchart.

* Add token-based execution logic to Flowchart activities

Introduced token-based workflow execution for Flowcharts, enabling more granular control over activity scheduling. Refactored Start activity resolution and optimized connection handling within FlowGraph. Added extensions for improved activity query and execution management.

* Refactor token-based flowchart logic and add loopback detection

Replaced the legacy token-based flowchart logic with a cleaner, modular implementation. Introduced `LoopbackDetector` for identifying back-edges in workflows, enabling explicit handling of loopback connections for improved execution flow. Minor adjustments were also made for code consistency and clarity.

* Introduce token-centric execution model for Flowchart activity

Replaced the execution-count heuristic in Flowchart with a robust token-centric model, improving handling of loops, joins, and forks. Added join semantics via `JoinKind` and `IJoinHintProvider` to enable flexible configuration. Updated documentation and dependencies to reflect the new model.

* Refactor activity property handling and enhance JSON serialization.

Standardize key names in activity property management for consistency and improve error handling in `GetJoinKind` methods. Add support for enum serialization with `JsonStringEnumConverter` in JSON utilities.

* Refactor flowchart token handling for clarity and efficiency

Revised the flowchart token management logic to improve readability and maintainability. Simplified token creation, consumption, and scheduling while removing redundant code. Updated token structure and streamlined the flow execution process to handle dynamic and static connections effectively.

* Refactor Flowchart activity scheduling logic

Consolidated child activity scheduling into a single method, reducing duplication across token-based and counter-based workflows. Removed unused fields, redundant imports, and legacy logic to improve maintainability and clarity of the codebase.

* Update .gitignore to track Azurite data folder

Added `docker/azurite-data` to the ignore list to exclude local Azurite data files from being included in the repository. Ensures proper handling of temporary files related to Azure storage emulation.

* Refactor flowchart logic and extract activity context utilities

Reorganized flowchart logic by introducing reusable extension methods for activity context operations. Moved "HasPendingWork" and "HasFaultedChildren" methods into extensions to improve readability and maintainability. Updated related flowchart logic to utilize these methods for cleaner and more modular code.

* Refactor join logic and clean up Flowchart activities

Removed obsolete `JoinKind` enum and `IJoinHintProvider` interface, replacing them with the new `JoinMode` concept. Simplified flowchart logic by consolidating flow graph handling and refining activity execution extensions. Updated `FlowJoin` to recommend property-based configuration over explicit usage.

* Avoid invalid test execution when token flow is enabled.

The added check prevents the test from running when `Flowchart.UseTokenFlow` is enabled, as this scenario is incompatible. This ensures test reliability and avoids unnecessary execution.

* Refactor token-based logic in Flowchart activity.

Simplified token handling and introduced clearer logic for WaitAny and WaitAll joins. Improved efficiency by reducing redundant checks and streamlining activity scheduling. This ensures better maintainability and functionality in complex workflows.

* Refactor Token logic into its own model class

Moved the Token logic out of the Flowchart partial class to a standalone `Token` model for better modularity and clarity. Adjusted token consumption behavior to mutate the token in place rather than replacing it.

* Fix ancestor cancellation logic in Flowchart activities

Pass the correct activity to CancelInboundAncestorsAsync to ensure accurate ancestor determination and cancellation. Added validation to confirm the activity context is a flowchart to prevent invalid operations. These changes improve the reliability of flow control in workflows.

* Refactor Token model to add scheduling functionality

Replaced the `consumed` parameter with a `Scheduled` property and added a `Schedule` method for mark scheduling. This enhances the token model's flexibility, improving flowchart activity management.

* WIP on (no branch)

* Remove unused WaitAny guard logic from Flowchart activity.

The WaitAny guard logic and associated key have been commented out and effectively disabled. This cleanup simplifies the code, removing unnecessary operations that were no longer in use. The change ensures better maintainability and focuses on the core functionality.

* Add `MergeMode` enum and refactor flowchart merging logic

Introduced a `MergeMode` enum to define strategies for handling multiple inbound execution paths. Updated flowchart logic to replace the previous `FlowJoinMode` with `MergeMode`, and refactored related extensions to accommodate the new enum. This enhances clarity and flexibility in workflow merging behaviors.

* Mark `FlowJoin` obsolete and enhance merge mode handling

Added the `[Obsolete]` attribute to the `FlowJoin` activity and deprecated properties to encourage using `MergeMode`. Replaced synchronous `GetMergeMode` with an asynchronous `GetMergeModeAsync` to handle legacy `FlowJoin` mappings dynamically. Other minor changes include simplifying variable initialization in `WorkflowExecutionContext`.

* Mark FlowJoin activity as obsolete

The FlowJoin activity is now marked obsolete since all activities support the MergeMode property, eliminating the need for explicit join steps. This change includes an annotation update to clearly communicate its deprecated status.

* Refactor `OnActivityCanceledAsync` method location

Moved the `OnActivityCanceledAsync` method from the `Flowchart.Counters` file to the main `Flowchart` file for improved organization and readability. This ensures the method aligns better with its primary logic and related functionality.

* Refactor flowchart logic to improve cancellation handling

Refactored `OnActivityCanceledAsync` to handle token-based flow and legacy flow separately for better clarity and maintainability. Moved `CompleteIfNoPendingWorkAsync` to a single shared location and updated pending work checks to include unconsumed tokens and faulted activities. Simplified redundant logic and ensured consistency across methods.

* Remove consumed tokens after activity completion

This update ensures that consumed tokens pointing to the completed activity are purged from the token list. This helps maintain a clean state and prevents unnecessary token accumulation during workflow processing.

* Add support for blocking tokens in flowchart activities.

Introduced a `Blocked` property to the `Token` model to prevent scheduling activities prematurely in certain merge modes. Updated token processing logic to handle blocked tokens effectively and ensure proper scheduling or consumption. Simplified token management by removing redundant methods and cleaning up consumed tokens appropriately.

* Refactor Flowchart activity cancellation logic.

Streamlined cancellation logic by separating token and counter flow handling into dedicated methods. Removed redundant properties and logic, improving readability and maintainability. Simplified `OnChildCompletedAsync` and related methods for consistency.

* Refactor token-centric flowchart execution model.

Updated the flowchart ADR to clarify the token-centric approach, including `MergeMode` rules and scheduling logic. Enhanced the model to handle loops, forks, and resumable activities more robustly while improving state management and supporting cancellation. Updated sequence diagram for clarity.

* Remove JoinMode-related methods from ActivityExtensions

The GetJoinMode and SetJoinMode methods were removed as they are no longer needed. This cleanup reduces unused code and improves maintainability of the ActivityExtensions class.

* Remove unused JoinMode enum

The JoinMode enum was determined to be unnecessary and has been deleted to clean up the codebase. This helps reduce redundancy and improve maintainability.

* Remove unused LoopbackDetector class from Flowchart module

The LoopbackDetector class was removed because it is no longer used in the codebase. Its functionality appears to be obsolete or unnecessary for the current requirements of the Flowchart module.

* Update `UseTokenFlow` to be configurable

Made `UseTokenFlow` a static field to allow external configuration. This enables users to switch between the token flow and the old counter-based model as needed. Updated documentation accordingly.
2025-05-09 20:07:49 +02:00
.github Update branch reference in packages workflow 2025-04-30 21:16:39 +02:00
.nuke Upgrade to NUKE 9.0.4 and fix automatic workflow generation 2025-01-26 19:29:19 +02:00
build Update package and remove obsolete project entry 2025-02-23 23:38:48 +01:00
design Add new Elsa logo image 2024-10-03 11:16:14 +02:00
doc Introduce token-centric Flowchart execution model with configurable MergeMode (#6632) 2025-05-09 20:07:49 +02:00
docker Add Azurite service to docker-compose.yml 2025-04-28 19:07:24 +02:00
gen Update DSL and sample 2022-03-28 13:25:45 +02:00
scripts Support for Writing Custom Trigger Activities Using Existing Trigger Infrastructure (#6527) 2025-03-21 23:16:56 +01:00
src Introduce token-centric Flowchart execution model with configurable MergeMode (#6632) 2025-05-09 20:07:49 +02:00
test Introduce token-centric Flowchart execution model with configurable MergeMode (#6632) 2025-05-09 20:07:49 +02:00
.editorconfig Refactor to use target-typed object creation 2025-01-09 10:27:55 +01:00
.gitignore Introduce token-centric Flowchart execution model with configurable MergeMode (#6632) 2025-05-09 20:07:49 +02:00
build.cmd Add NUKE build support (#4815) 2024-01-21 10:53:07 +01:00
build.ps1 Add NUKE build support (#4815) 2024-01-21 10:53:07 +01:00
build.sh Add NUKE build support (#4815) 2024-01-21 10:53:07 +01:00
CONTRIBUTING.md Create CONTRIBUTING.md 2024-01-03 16:22:03 +01:00
Directory.Build.props Fix DbContext pooling (#6531) 2025-03-26 16:05:40 +01:00
Directory.Packages.props Introduce token-centric Flowchart execution model with configurable MergeMode (#6632) 2025-05-09 20:07:49 +02:00
Elsa.sln Introduce token-centric Flowchart execution model with configurable MergeMode (#6632) 2025-05-09 20:07:49 +02:00
Elsa.sln.DotSettings Merge remote-tracking branch 'origin/blueberry' into enh/multi-tenancy-refactorings 2024-10-11 19:45:40 +02:00
icon.png Debug 2022-12-20 12:47:41 +01:00
LICENSE Add sources from experimental repo 2022-01-04 09:42:12 +01:00
NuGet.Config Remove obsolete HttpContextExtensions reference and update NuGet URL 2024-11-12 11:04:51 +01:00
README.md Update README.md (#6629) 2025-05-09 19:55:21 +02:00

ELSA 3.0

Elsa Workflows

Elsa 3 Prerelease Nuget (with prereleases) feedz.io Docker Image Version (latest semver) Discord Stack Overflow questions Gurubase

For Elsa 2, Click Here

Introduction

Elsa is a powerful workflow library that enables workflow execution within any .NET application. Elsa allows you to define workflows in various ways, including:

  • Writing C# code
  • Using a visual designer
  • Specifying workflows in JSON

Elsa ships with a powerful visual designer

Try with Docker

To give the Elsa Studio + Elsa Server a quick spin, you can run the following command to start the Elsa Docker container:

docker pull elsaworkflows/elsa-server-and-studio-v3:latest
docker run -t -i -e ASPNETCORE_ENVIRONMENT='Development' -e HTTP_PORTS=8080 -e HTTP__BASEURL=http://localhost:13000 -p 13000:8080 elsaworkflows/elsa-server-and-studio-v3:latest

This Docker image is based on a reference ASP.NET application that hosts both the workflow server and designer and is not intended for production use.

By default, you can access http://localhost:13000 and log in with:

  Username: admin
  Password: password

Table of Contents

Documentation

Elsa Documentation Website.

Known Issues and Limitations

Elsa is continually evolving, and while it offers powerful capabilities, there are some known limitations and ongoing work:

  • Documentation is still a work in progress.
  • Input/Output is not yet implemented in the Workflow Instance Viewer.
  • Starting workflows from the designer is currently supported only for workflows that do not require input and do not start with a trigger; this is planned for a future release.
  • The designer currently only supports Flowchart activities. Support for Sequence and StateMachine activities is planned for a future release.
  • UI input validation is not yet implemented.

Features

Elsa offers a wide range of features for building and executing workflows, including:

  • Execution of workflows in any .NET application with support for .NET 6 and beyond.
  • Support for both short-running and long-running workflows.
  • A programming model loosely inspired by Windows Workflow Foundation.
  • A web-based drag & drop designer with support for custom activities.
  • Native support for activity composition, including activities like Sequence, Flowchart, and ForEach.
  • Parallel execution of activities.
  • Built-in activities for common scenarios, such as sending emails, making HTTP calls, scheduling tasks, sending and receiving messages, and more.
  • Workflow versioning and migration via API.
  • Easy integration with external applications via HTTP, message queues, and more.
  • Actor model for increased workflow throughput.
  • Dynamic expressions with support for C#, JavaScript, Python, and Liquid.
  • Persistence agnostic, with support for Entity Framework Core, MongoDB, and Dapper out of the box.
  • Elsa Studio: a modular Blazor dashboard app for managing and designing workflows.

Roadmap

See #3232

Use Cases

Elsa can be used in a variety of scenarios, including:

  • Long-running workflows such as order fulfillment and product approval.
  • Short-running workflows such as sending emails and generating PDFs.
  • Scheduled workflows such as sending daily reports.
  • Event-driven workflows such as sending welcome emails when a user signs up.

Coding Workflows

Elsa allows you to define workflows in code using C#. The following example shows how to receive HTTP requests and send an email in response:

public class SendEmailWorkflow : WorkflowBase
{
    protected override void Build(IWorkflowBuilder builder)
    {
        builder.Root = new Sequence
        {
            Activities =
            {
                new HttpEndpoint
                {
                    Path = new("/send-email"),
                    SupportedMethods = new(new[] { HttpMethods.Post }),
                    CanStartWorkflow = true
                },
                new SendEmail
                {
                    From = new("alic@acme.com"),
                    To = new(new[]{ "bob@acme.com" }),
                    Subject = new("Your workflow has been triggered!"),
                    Body = new("Hello!")
                }
            }
        };
    }
}

Designing Workflows

Elsa allows you to define workflows using a visual designer. The following example shows how to receive HTTP requests and send an email in response:

Elsa ships with a powerful visual designer

Contributing

We welcome contributions from the community and are pleased that you are interested in helping to improve the Elsa Workflow project! Here are the steps to contribute to our project:

1. Fork and Clone the Repo

To get started, you'll need to fork the repository to your own GitHub account. You can do this by navigating to the Elsa Workflow GitHub repository and clicking the "Fork" button in the top-right corner of the page. Once you have forked the repo, you can clone it to your local machine using the following command:

git clone https://github.com/YOUR_USERNAME/elsa-core.git

Replace YOUR_USERNAME with your GitHub username. For more information on forking a repo, check out the GitHub documentation here.

Incorporating the details about the "apps" folder and its projects into the second point about opening the Elsa.sln using your favorite IDE, we can expand the instructions to guide developers on where to start and what projects they might want to explore first. Here's an updated version of that section with the additional information:

2. Open Elsa.sln Using Your Favorite IDE

After cloning the repository, navigate to the cloned directory and open the Elsa.sln solution file with your preferred IDE that supports .NET development, such as Visual Studio, JetBrains Rider, or Visual Studio Code with the appropriate extensions.

Within the solution, you will find an "apps" folder containing three projects designed to help you get started and explore the capabilities of Elsa Workflow:

  • Elsa.Server.Web: This project is a reference ASP.NET Core application that acts as a workflow server. It's a great starting point if you want to understand how Elsa functions as a server-side workflow engine.

  • Elsa.ServerAndStudio.Web: This project serves a dual purpose. Like Elsa.Server.Web, it acts as a workflow server. Additionally, it hosts the Elsa Studio Blazor WebAssembly app. This is the perfect project to run if you want to see the full capabilities of Elsa, including both the server aspects and the client-side studio experience in one application.

  • Elsa.Studio.Web: This project is a reference Blazor WebAssembly application that solely hosts the Elsa Studio Blazor WebAssembly app. It requires a running Elsa server application to connect to. Use this project if you're interested in focusing on the Elsa Studio UI and its interactions with an Elsa workflow server.

3. Submit a PR with Your Changes

Once you have made your changes, commit them and push them back to your fork. Then, navigate to the original Elsa Workflow repository and create a new Pull Request. Ensure your PR description clearly describes the changes and any relevant information that will help the reviewers understand your contributions. For a detailed guide on creating a pull request, visit Creating a pull request from a fork.

4. Open an Issue First

Before you start working on your changes or submit a pull request, please open an issue to discuss what you would like to do. This step is crucial as it ensures you don't spend time working on something that might not align with the project's goals or might already be under development by someone else. You can open an issue here.

This approach helps us streamline contributions and ensures that your efforts are aligned with the project's needs and priorities. We look forward to your contributions and are here to support you throughout the process. Thank you for contributing to the Elsa Workflow project!

Support

There are various ways to get support for Elsa Workflows, ranging from community-driven channels to enterprise-level services.

Community Support

Elsa has an active and helpful community where you can find support through multiple channels:

  • GitHub Issues for bug reports and feature requests.
  • GitHub Discussions for open-ended conversations, questions, and community-driven support.
  • Discord for real-time support and interaction with the Elsa community.
  • StackOverflow for searching or asking technical questions.

Enterprise Support

For organizations requiring professional support and long-term commitment, ELSA-X offers enterprise-level services and ensures continuity and future development of the Elsa framework, provides custom solutions, and develops commercial extensions tailored to enterprise needs.