* Remove initial migrations
Deleted obsolete initial migration files from multiple databases: MySQL, SQL Server, SQLite, and PostgreSQL. This cleanup helps maintain a streamlined and updated migration history.
* Add Document base class and create tenant-specific indices
Introduced a new abstract `Document` base class to unify common properties. Implemented tenant-specific unique indices across multiple collections by including `TenantId` alongside `Id` to ensure uniqueness within tenant scopes.
* Remove outdated migration files
Deleted various migration files under MySql, PostgreSql, Sqlite, and SqlServer directories. This cleanup removes unnecessary schema definitions and helps to streamline the codebase.
* Refactor workflow identity assignment logic
Streamline workflow identity handling to ensure consistent assignment of Id, DefinitionId, and TenantId values. This change integrates tenant prefix and version suffix cleanly, enhancing clarity and maintainability.
* Enable multitenancy support
Added configuration for a new tenant (tenant-1) in appsettings.json and enabled multitenancy feature in Program.cs. This change allows the application to support multiple tenants, with specific configurations for each.
* Refactor route table update to run as startup task
Replaced `UpdateRouteTableHostedService` with `UpdateRouteTableStartupTask` to ensure route table updates are executed during application startup instead of as a hosted service. Updated configuration in `HttpFeature` and adjusted trigger validation logic in `ValidateWorkflowRequestHandler`.
* Add recurring task scheduling and single-node task support.
Introduce `IntervalExpressionType`, recurring task scheduling classes, and `SingleNodeTaskAttribute`. Update `RecurringTasksRunner` to handle schedules and add single-node task logic to `StartupTasksRunner`. Ensure proper namespace changes and configure sample recurring tasks.
* Refactor recurring tasks scheduling system
Replaced existing scheduling classes with a more modular and granular approach. Introduced new classes and interfaces like `ISchedule`, `CronSchedule`, `IntervalSchedule`, and `RecurringTaskScheduleManager`. Updated related methods and code to comply with the new design.
* Refactor background task management
Removed `ExpiredSecretsHostedService` and refactored it into a recurring task. Introduced `TaskExecutor` for shared task execution logic. Updated and renamed feature classes to better represent their purpose, improving task scheduling and execution management.
* Add BackgroundTask abstract class to Elsa.Common module
This new abstract class implements the IBackgroundTask interface with default methods for executing, starting, and stopping tasks asynchronously. It provides a basic framework for background task management in the Elsa.Common module.
* Switch to CreateAsyncScope in DefaultTenantScopeFactory
Updated the CreateScope method to use CreateAsyncScope instead of CreateScope. This change improves asynchronous handling of service scopes within the DefaultTenantScopeFactory class.
* Add tenant handling and move StartWorkers background task
Introduce ITenantAccessor in Worker class for multitenancy support. Rename and relocate StartWorkers service to BackgroundTask, ensuring smoother workflow initialization. Also, update the configuration to support Azure Service Bus connection string.
* Add tenant support and refactor ProtoActor client
Integrated ITenantAccessor in ProtoActorWorkflowClient class to handle multi-tenancy. Refactored methods in the client to support custom headers and added async disposable pattern in various services for proper resource management. Additionally, enabled Azure Service Bus and updated related documentation.
* Add support for custom headers in ProtoActor grain methods
Introduced a T4 template to generate grain methods with custom headers, enabling the use of tenant ID in requests. Updated `ProtoActorWorkflowClient` to employ these methods, removing redundant code and directly utilizing the client for various workflow operations.
* Add tenant middleware to MassTransit configurations
Introduced multitenancy middleware for MassTransit message handling. Added new message type `OrderReceived` and updated RabbitMQ setup in Elsa Server. Applied middleware to configure tenant data on send, publish, and consume operations.
* Add new product workflow and streamline ID handling
Introduced a new `RequestResponseWorkflow` for handling product requests. Simplified ID handling in `WorkflowBuilder` and `ClrWorkflowsProvider` by defaulting to empty strings and adding a version prefix. Enhanced `HttpWorkflowsMiddleware` to correctly parse full request paths.
* Remove redundant files and update configuration
Deleted unused files `Product.cs` and `RequestResponseWorkflow.cs` to clean up the codebase. Updated `Program.cs` configuration: switched MassTransitBroker to Memory and disabled multitenancy.
* Remove MultitenantRecurringTaskService and update AzureServiceBus
Removed `MultitenantRecurringTaskService` and adjusted related code for Azure Service Bus to work without it. This includes removal of tenant accessor dependency from `Worker` and cleanup of service configuration flags in `Program.cs`.
* Increase signal wait timeout to 10000 milliseconds.
Extended the default timeout for signal awaiting methods from 8000 to 10000 milliseconds. This change ensures more flexible and resilient waiting periods, reducing timeout occurrences in scenarios with longer processing times.
* Refactor scheduling service to be a background task
Renamed `CreateSchedulesHostedService` to `CreateSchedulesBackgroundTask` and refactored it to inherit from `BackgroundTask` instead of `BackgroundService`. Simplified the constructor by injecting the required dependencies directly, eliminating the need for a scoped factory.
* Refactor workflow version suffix formatting
Changed the version suffix format from `:v{version}` to `v{version}` and adjusted the ID concatenation accordingly. This improves consistency and readability of workflow IDs.
* Enable multitenancy support in Quartz scheduler
Added `TenantJobListener` to inject tenant context into jobs. Modified `QuartzWorkflowScheduler` to incorporate tenant IDs into job data maps and adjusted the configuration to acknowledge multitenancy settings.
* Remove ConfigureSchedulerHostedService and TenantJobListener
Consolidated tenant resolution logic into JobExecutionExtensions class. Updated ResumeWorkflowJob and RunWorkflowJob to use the new extension method for tenant retrieval. This simplifies the QuartzSchedulerFeature setup by removing the hosted service configuration.
* Refactor HTTP feature and update route table task
Move 'UpdateRouteTableStartupTask' from 'HostedServices' to 'Tasks' and update dependency injection configurations accordingly. Simplify 'DefaultRouteTableUpdater' by removing unnecessary options and tenant-agnostic settings from filters.
* Disable multitenancy in Program.cs
The useMultitenancy flag has been changed from true to false. This update affects the Elsa.Server.Web application configuration.
* Simplify variable usage in HttpWorkflowsMiddleware
Replaced 'fullPath' variable with 'path' to streamline code. This change enhances readability by reducing redundancy and ensures consistency in variable naming throughout the method.
* Enable multitenancy and refactor tenant handling logic
Enable multitenancy in the application and refactor tenant handling logic to use ITenantFinder and ITenantContextInitializer interfaces. Added header constants, updated middleware to use these interfaces, and moved extension methods to the appropriate namespace.
* Add input validation to user registration form
Implemented checks to ensure all required fields are filled and that input data adheres to format requirements. This change reduces errors and enhances form reliability.
* Remove unused import from TenantPrefixHttpEndpointRoutesProvider
This change cleans up the code by removing an unnecessary import statement. It improves code readability and reduces clutter, making future maintenance easier. The functionality remains unchanged.
* Rename filter scope to "tenantPublish" in Probe method
Updated the Probe method in TenantPublishMiddleware.cs to use "tenantPublish" instead of "tenantSend" for better clarity. Ensures consistency with the method's context and aligns with naming conventions.
* Refactor: Remove extraneous whitespace
Eliminate unnecessary whitespace in ProtoActorWorkflowClient.cs for cleaner code. This change helps maintain consistent formatting and improves readability.
* Refactor DefaultRegistriesPopulator for cleaner initialization
Converted constructor to use read-only fields directly, removing unnecessary instance variables. This change simplifies the code by reducing redundancy and making the constructor cleaner.
|
||
|---|---|---|
| .github | ||
| .nuke | ||
| build | ||
| design | ||
| docker | ||
| docs | ||
| gen | ||
| scripts | ||
| src | ||
| test | ||
| .editorconfig | ||
| .gitignore | ||
| build.cmd | ||
| build.ps1 | ||
| build.sh | ||
| CONTRIBUTING.md | ||
| Directory.Build.props | ||
| Directory.Packages.props | ||
| Elsa.sln | ||
| Elsa.sln.DotSettings | ||
| icon.png | ||
| LICENSE | ||
| NuGet.Config | ||
| README.md | ||
ELSA 3.0
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
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
- Known Issues and Limitations
- Features
- Roadmap
- Use Cases
- Programmatic Workflows
- Designed Workflows
- Contributing
- Support
Documentation
For comprehensive documentation and to get started with Elsa, please visit the 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.
- The designer is not yet fully embeddable in other applications; this feature is planned for a future release.
- C# and Python expressions are not yet fully tested.
- Bulk Dispatch Workflows is a new activity and not yet fully tested.
- 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, andForEach. - 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
The following features are planned for future releases of Elsa:
- Multi-tenancy
- State Machine activity
- Designer support for Sequence activity & StateMachine activity
- BPMN 2.0 support
- DMN support
- Workflow migration to new versions via UI
- Capsules ("hot" deployable workflow packages containing activities and configuration)
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.
Programmatic 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!")
}
}
};
}
}
Designed 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:
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.

