Roadmap

[sfmskywalker]

This issue lists high-level functionality I'd like to add to Elsa 3 and beyond. It's not a final list and the order in which each milestone will be picked up might change over time and depends on business value & community interest.

Engine

• Non-blocking activity execution
• Fork & join
• Compensation
• Multi-associative workflow instance keys Multiple correlation fields #3440
• Generator activity execution Generator Activities #2964
• Activity as property input
• Multitenancy Multitenancy #764
• Variable History Tracking Feature: History Tracking for Workflow Variable Mutations #4351
• Data Processing Pipelines / ETL Data Processing Pipelines / ETL #4809
• Secrets [FEAT] Secrets #221
• Workflow Execution Recovery Workflow Execution Recovery #4833

Runtime

• In-memory provider for Proto Actor
• Kubernetes provider for Proto Actor Implement Kubernetes feature for ProtoActor runtime #3230
• Localhost
• Retention policies + archiving

Activities

• JavaScript
• Jobs
• Razor & Blazor navigation activities
• State Machine (State Machine Activity #5085)
• Parallel For Each
• Open API Open API Activities #2961
• GraphQL
• Soap
• Proto Actor Proto.Actor Activities #2960
• BPMN 2.0 (BPMN support? #39)
• Raspberry PI
• Kubernetes
• Azure Functions
• SQL activities
• Handle domain/DB entity changes Is there anyway to create a workflow that is triggered when a record in a postgres database reaches a certain value / new record inserted ...etc #3798

Tooling

• Activity Definitions Activity Definitions #3174
• Version Management Workflow Definition History UI #3028
• Navigator
• Auto Layout
• DSL / JSON / YAML
• Connect & Add
• Workflow Testing & Debugging
• Sequence Diagram designer Sequence Designer #3452
• User Tasks
• Forms

Integration & Modules

• OpenTelemetry OpenTelemetry #4711
• BPMN modeler & worker
• DMN 1.3 Worker
• Email template management

Studio

• Modular & Extensible Dashboard Framework
• Intelligence & Reporting (historical)
• Instance Management (active and historical)
• Retry
• Debug
• Journal
• Suspend / Resume (workflow definition, workflow instance, activity definition, activity instance)
• Filtering of instances
• Designer
• Localization Feature: Localization Support elsa-studio#23

Ecosystem

• Marketplace
• Orchard Core Integration

[cristinamudura]

@sfmskywalker For the tooling maybe we can include the Debugger as well.
And for activities the Soap Generator maybe 😄

[PeterHuang-ST]

@sfmskywalker What is the current ETA for V3? Also, is there going to be a migration process from V2 to V3 or this is not decided yet? TIA.

[sfmskywalker]

@PeterHuang-ST I’m hoping to be releasing a release candidate end of this year. Regarding migration path, I would love to do it but it depends on complexity and available resources. At the very least, we should write a migration guide.

[Nokecy]

v3 any update ? @sfmskywalker

[sfmskywalker]

Sure. There's still a ton of little things to do to achieve feature-parity with v2, but a preview is inching closer.
At the moment I am working with a client to implement a real-world telephony workflow using Telnyx, which reveals many small bugs and oversights, boosting the development of the overall engine and tooling significantly.

I hope to get started on "getting started" tutorials soon.

[hassanelsherbiny]

is version 3 ready or when it will be released? and how can i get a preview?

[sfmskywalker]

Not ready yet, preview release on NuGet probably later this month or sometime next month.

You can give it a spin by following the Installation section of the documentation (which is far from finished): https://v3.elsaworkflows.io

[sfmskywalker]

PS. I just realized that the preview package feed of DevOps is outdated. The part “Packages” needs to be “Elsa3”. Will fix.

[vgb1993]

Hey there!

I would be really nice if the Activity editor could be replaced to use custom Blazor components.

Perhaps a generic Attribute with some constrains making the editor "contract" compliant could work.

Also some activities may require complex controls and custom behabiour when configuring.

Say I have a FTP activity. I could try to connect using the credentials and give feedback to the user while it's configuring the activity.

Or build a drag and drop form within the activity that will somehow get shown to the user. Rember the chatbot? ;)

There are so many more examples I can think of. This would be pretty hard to do with the current stencil components.

Super powers for the people that want to create activities.

I'll create an issue for this :)

Have a nice day

[sfanwar]

When will we expect about Elsa 3 to be released as stable and final version.

[GeorgeS2019]

Can someone update commitment in using Blazor for UI and Designer?

[sfmskywalker]

@vgb1993 Agreed! We are going to re-implement the designer in Blazor, but after 3.0 release as to not further delay it unnecessarily.

@sfanwar We expect RC to drop end of May.

@GeorgeS2019 Done ;)

[bhanuchhabra7]

Do we know if the v3 will work with data from v2?
We had a lot of issues migrating from v1 to v2. If there are breaking changes, would there be any clean way to migrate data?

[sfmskywalker]

Elsa 3 is a rewrite, so by default, there is no compatibility. However, I might do some experiments related to data migration or even interpretation of the V2 model to help bring over existing V2 projects.

[bhanuchhabra7]

I think, as a practice, Elsa should think about backward compatibilities. It is not good if you want it to Project as THE LIBRARY for handling workflows. Every version having breaking changes is not a good experience.

[mircotamburini]

Mqtt Activities?

[zejji]

Re the rewrite of the designer in Blazor, I wonder if this is really a good idea?

While Blazor has a decent developer experience, it has very poor performance and extremely large bundle sizes. It's generally recognised that Blazor is a poor choice for anything other than internal/LOB applications.

Wouldn't it be preferable from an end-user perspective to have a relatively lightweight web component that can easily be embedded in another application (e.g. created using React/Vue/Solid/Svelte/Lit etc.)?

[GeorgeS2019]

@zejji
Blazor is the #Microsoft future web technology => high performance low latency is the GOAL and differentiation from other Web technology

That means, there is NOW fast iteration to make Blazor low latency with new innovation of hybrid/mixed frontend webassembly backend server performance optimization.

It is this committed Fast iteration and pushing new way to support global scalable web deployment with low latency the basis why we need to move to Blazor

Currently on preview .NET8 => Blazor United

Full stack web UI with Blazor - Big changes in .NET 8

[GeorgeS2019]

@sfmskywalker

The fundamental motivation for choosing Blazor is to REMOVE incompatibility between the backend .NETCore and the existing frontend designer not based on .NETCore.

By harmonizing .NETCore between backend and frontend designer, this opens NEW Innovation not possible before that keeps Backend separated from the frontend developers

[zejji]

@GeorgeS2019 - I'm aware of Blazor United, but it doesn't fix the fundamental problem that Blazor WASM (i) requires the whole .NET runtime to be downloaded to the browser sooner or later and (ii) uses JavaScript interop to access the DOM. It will always be less efficient than a JavaScript-based web app, since JavaScript is obviously the only inbuilt language in browsers.

I say this as someone who loves .NET and would love to be able to use Blazor for production applications. However, currently the developer UX is the only argument for using Blazor - all performance and bandwidth considerations indicate strongly against it.

Cf. https://krausest.github.io/js-framework-benchmark/index.html, where Blazor WASM has the worst performance of all tested frameworks for speed, startup time and memory allocation.

Re bundle sizes - see https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1#31f0 for a comparison of common JavaScript frontend framework bundle sizes, where many libraries require only tens of kilobytes. Contrast that with Blazor WASM app, where a 'Hello World' application is just under 2 MB when compressed with Brotli and fully-fledged applications tend to be much, much larger still.

[FransVanEk]

@zejji Is there a restiction to use the Blazor as a WASM solution? Blazor can be used as Server side as well which reduces the concerns you have regarding performace and bandwidth due to large packages and performance.

sure there are some challenges there as well but for me at least less intrusive as the WASM approach.

[GeorgeS2019]

@zejji

Issue 1

• 2021: Why you shouldn’t compare Blazor to other JavaScript SPA frameworks
  • 1. WASM

  Blazor’s output is WASM, unlike other SPA frameworks/libraries (Angular, Vue, React, etc.). WASM is the new standard and the future. Instead of running your codes in the browser JS engine, the browser executes your application in a binary format.

  • 2. Benefits of the .NET and C#

Issue 2

• https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1#31f0 <= your provided article is year 2020, and is old for blazor

  I am aware that with each new .NET version e.g. .NET7 to .NET8, the bundle size is increasingly getting smaller.

[zejji]

@FransVanEk - There are also some (different) major downsides with using Blazor Server unfortunately:

1. The potential for high perceived latency for every user interaction, particularly where the server is geographically distant from the user, as every such interaction involves a network round-trip (unlike in WASM).
2. Each active user requires some memory allocation on the server to store their current state. This is different from the situation in most web apps, where significant memory is only consumed when processing web requests.

These are trade-offs one might be willing to make when designing a bespoke application, as it may be the case that the requirement for an extremely large number of concurrent users is not present and that speed and resource usage are only secondary requirements.

However, when designing a library, they are not trade-offs I would personally make, as you would effectively be dictating the performance characteristics of the consuming application.

If there were no alternatives, then one would have to accept this, but obviously much more performant JavaScript-based alternatives do exist.

@GeorgeS2019 - I'm currently developing a small application using Blazor WASM on .NET 7 and, even with relatively limited functionality and all optimizations enabled (after a significant amount of research, including following recommendations from Microsoft and third parties), the published Blazor application bundle (compressed using Brotli and excluding all CSS, JavaScript, assets etc.) is 2.75 MB. For comparison, the equivalent application in e.g. SolidJS is well under 100kb.

Furthermore, despite using SSR in the project to improve perceived page load, there is a significant (often up to 5s) delay in the page becoming interactive. It's not possible to improve on this, as this is the time taken to download and initialize the runtime and framework.

I've enjoyed working with Blazor a lot, but I can't see it being appropriate for a public-facing high-traffic website any time soon.

That said, if the decision is made to go with Blazor specifically for productivity reasons, that would certainly be understandable.

[bachratyg]

The bundle size/startup performance may not be the key issue here. Right now there is no direct integration with the DOM, any interaction has to pass through javascript glue code including DOM events. For a diagram designer I'd expect lots of drag&drop interaction and that translates to a massive event stream crossing the JS-WASM boundary (or for Blazor Server the network boundary). Microsoft has to work with the WASM limitations no matter how much they are committed to fast iteration and this likely won't change until proposals like GC integration are fully speced, implemented and deployed. That could take a long time. IIRC the current "suggested" workaround is to stay in JS. At least some exploratory testing for usability should be done before this is fully committed.

[GeorgeS2019]

If the Diagram designer is in blazor, there will be more users here who are Elsa backend developers will engage more regularly and directly with the diagram designer when it is Blazor using c# or c#-JS interop.

If it is not in Blazor, the situation will be the same now, we HOPE someone will take our feedback to implement the change to the Diagram Designer. Users here who could develop the Diagram Designer using the existing JS is perhaps 5% or even much smaller than the majority of the users here.

If it is important to engage iterative UI FEEDBACK from backend Elsa developers to have FAST iteration of the diagram designer, BLAZOR will have a significant advantage.

If we have a dedicated Diagram designer who will actively handle all issues raised by backend users, we could ignore Blazor suggestion. From what I observed at least last 2 years, this is NOT THE CASE.

Encouraging backend users to directly contribute to the Front end Diagram Designer will speed up the quality and usability of the Diagram Designer.

[sfmskywalker]

Here are some of the things I am taking into consideration.

• Blazor and JS have their own ecosystems with pros and cons, as outlined above.
• Using Blazor makes sense for .NET developers.
• Using [insert JS framework of choice] makes sense for JS developers (and, admittedly, for many .NET developers, too).
• Although Blazor may not have a small footprint like JS libraries do, it's not necessarily a problem to have to download a minified framework the first time. After all, the dashboard isn't typically used to handle high traffic situations. Ease of customisation, extensibility, in other words, productivity, may be more important here.
• There are many users out there that integrate the designer into their own React/Angular/Vue etc, dashboards, and I do not want to forget about that group.
• Some of them chose to build the designer themselves, others rely on the Stencil implementation (which provides a framework-agnostic reusable web component).
• It is important to realise why some teams decided to build their own designer. From what I gathered, and from what I imagine, the main reasons are that the designer is not very easy to customise and to extend, plus it uses its own look and feel that may not fit in a given dashboard.

Considering the above, it seems to me that there are 2 main groups of developers:

1. Developers that prefer to use an existing dashboard framework that they can customise and extend.
2. Developers who have their own UI into which they need to integrate workflow management features.

For the first group, we can divide them into two subgroups:

a) Developers who prefer to extend the dashboard using Blazor.
b) Developers who prefer to extend the dashboard using JS.

For group no. 2, the dashboard application is useless. All they are interested in is to have a designer that they can embed in a page and interact with programatically.
A big challenge with this standalone designer is to make it customisable, extensible and theme-able without the use of a framework and design system. Even more so when you consider that Elsa comes with increasingly more modules that one might want to take advantage of. Just to name a few:

• Webhooks
• User & Roles
• Email (templates, mailing lists, etc)
• Secrets
• Forms
• Scripts

The above is easily implemented using component libraries, which may or may not support theming.
This is the main reason I want to do a dashboard application, and Blazor seems a fine choice to me. That being said, don't be surprised if I eventually start an Ionic dashboard implementation on the side ;)

Just to try and clarify certain points that were made by others:

Re the rewrite of the designer in Blazor, I wonder if this is really a good idea?

It depends on whom you ask. My initial idea was to wrap it in a custom element so that it doesn't matter what your application UI stack is. However, in order to make it extensible and customisable, being able to use an existing component library boosts productivity not just for me, but for anyone trying to customise and extend. So now I'm wondering the usefulness of a Blazor implementation of the designer outside the context of a Blazor dashboard. Instead, I think there are two main use cases (the two main groups of developers I mentioned earlier).

While Blazor has a decent developer experience, it has very poor performance and extremely large bundle sizes. It's generally recognised that Blazor is a poor choice for anything other than internal/LOB applications.

My personal experience with Blazor so far, is that it offers a great developer experience. Even without having figured out how to do hot reload from Jetbrains Rider. I just love the component model, the way binding works, and, best of all, using proper C#. As for the extremely large bundle sizes, you'd have to define "extreme". A couple of MBs seems not an issue for the average backend system (which, after all, is where most, if not all, workflow designers will end up anyway).

Wouldn't it be preferable from an end-user perspective to have a relatively lightweight web component that can easily be embedded in another application (e.g. created using React/Vue/Solid/Svelte/Lit etc.)?

Yes, absolutely. And I have tried to do this. But I don't think it's enough; I want the designer to be extensible and themeable, and have a solid component framework to build upon. It's possible to do, it currently has a concept of plugins, but for many users I have spoken with, it's a real barrier. And at the same time, there are many existing component libraries that can be reused. So maybe it's best to keep the Stencil component as-is for embedding, and not have it implement other modules, like the ones I listed. Instead, developers would implement those features themselves, and other developers who don't have their own dashboard, can chose to leverage the Blazor dashboard (and possibly in the future, a JS-implementation of the dashboard).

The fundamental motivation for choosing Blazor is to REMOVE incompatibility between the backend .NETCore and the existing frontend designer not based on .NETCore.

Actually, my motivation is a little bit different than that. My main motivation to use Blazor is because it enables me to use C#, .NET and Razor components, which in turn means I get to use component libraries such as MudBlazor, which boosts productivity like crazy. It also means that the dashboard can be made extensible and customisable extremely elegantly, which makes it easy for .NET developers to do.

By harmonizing .NETCore between backend and frontend designer, this opens NEW Innovation not possible before that keeps Backend separated from the frontend developers

@GeorgeS2019 I guess my previous statement puts a stain on this vision. Perhaps you can elaborate a bit on these opportunities? For example, are you talking about shared use of model classes, and/or making the backend and front end environments appear as "one" to the developer?

Let there be no confusion: The Elsa backend is equally intended to be consumable by whatever front-end, be it Blazor, JS applications, Postman automation, etc. At no point will the Elsa backend become tightly coupled with any kind of front end (and if that does happen, it's a mistake).

For a diagram designer I'd expect lots of drag&drop interaction and that translates to a massive event stream crossing the JS-WASM boundary

Actually, the Blazor dashboard implementation relies on the X6 diagramming library, which means that all drag & drop operations happen in JS-space. Except for dragging a new activity from the toolbox onto the designer - that toolbox is done in Blazor. But that's fine in terms of perf.

If the Diagram designer is in blazor, there will be more users here who are Elsa backend developers will engage more regularly and directly with the diagram designer when it is Blazor using c# or c#-JS interop

To be clear, the current diagram design surface is still provided via the X6 library. But, everything around it (activity picker, activity property panel) and even the activities being rendered themselves, are proper Blazor components.
In addition, when using the Blazor dashboard framework, it now becomes that much easier to replace it with a (custom) implementation if you want to, like Azure Design Studio and Blazor Diagrams.

Thanks everyone for sharing your insights!

[jensenw-pki]

is v3 released now?

[sfmskywalker]

Not yet. We hope to release RC2 end of this month, but it largely depends on how fast we can work through the issues with the RC2 milestone. After that release, maybe one month later we can release 3.0 proper, barring any blocking issues we find in RC2.

[GeorgeS2019]

Elsa-Studio

for Elsa v3 preview using Blazor works

@sfmskywalker <= thx

[Eitanski]

Hey, what is the plan for an official release of Elsa 3?
I am looking to use Elsa workflows at my workplace. However, since it is still in prerelease I'm not sure what to do.
Also I love to see what are the current differences between 3 and 2, so that I can know what to opt for. Thanks a lot.

[carlosmorenoaguilera]

Hey, what is the plan for an official release of Elsa 3? I am looking to use Elsa workflows at my workplace. However, since it is still in prerelease I'm not sure what to do. Also I love to see what are the current differences between 3 and 2, so that I can now what to opt for. Thanks a lot.

Same here, im trying to determine if worth start with v3 or go on v2

[sfmskywalker]

@Eitanski @carlosmorenoaguilera

Elsa 3.0 will be out this month. The source code has moved from the v3 branch into the main branch and we're working on some minor improvements before we deploy the 3.0.0 packages to NuGet.

Almost there!

[Eitanski]

@sfmskywalker
man, just wanted to say that this project is awsome and that you guys are great
super stoked for the release

[sfmskywalker]

Cheers @Eitanski

[kobeliu9527]

This project is great, please stick to blazor, this is Net's playground

[Sudarsanam-Krishnan]

Hi @sfmskywalker - Any update on 3.0 release?

[Sudarsanam-Krishnan]

Hey, what is the plan for an official release of Elsa 3? I am looking to use Elsa workflows at my workplace. However, since it is still in prerelease I'm not sure what to do. Also I love to see what are the current differences between 3 and 2, so that I can now what to opt for. Thanks a lot.

Same here, im trying to determine if worth start with v3 or go on v2

Same here too...Waiting for V3 to check it out.

[sfmskywalker]

The release will happen today or within the next few days, depending on what we still find in terms of blockers. But you don't have to wait for the release to give it a spin.The docker images and NuGet packages are all available.

[Sudarsanam-Krishnan]

The release will happen today or within the next few days, depending on what we still find in terms of blockers. But you don't have to wait for the release to give it a spin.The docker images and NuGet packages are all available.

@sfmskywalker - Facing a challenge with the pre-release version of V3. Please see below build error on WASM studio

On using Blazor Server studio, getting similar error on build

P.S.: Followed documentation on https://v3.elsaworkflows.io/docs/installation/elsa-studio-blazorwasm & https://v3.elsaworkflows.io/docs/installation/elsa-studio-blazorserver respectively

[sfmskywalker]

@Sudarsanam-Krishnan Thanks for reporting your findings. The documentation ha been updated to reflect the latest changes. Specifically, the build error you pointed out can be fixed by replacing the problematic lines with the following:

builder.Services.AddRemoteBackend(
    elsaClient => elsaClient.AuthenticationHandler = typeof(AuthenticatingApiHttpMessageHandler),
    options => configuration.GetSection("Backend").Bind(options));

I will close this issue as resolved, but please feel free to continue the conversation. Thanks!

[sfmskywalker]

Reopening, as this is the roadmap, not an actual issue 😄

[bbenameur]

Hello,

I don't know if you added autoscaling by event for example we can use the KEDA project, https://keda.sh/docs/2.13/scalers/mongodb/
by driving the scaling of any container in Kubernetes based on the number of events needing to be processed.
In our case for example we can use the requests sent to a database like mongodb or other.
It's very powerful.

[sfmskywalker]

I wasn't aware of that, thank you for the tip 😃