Orchard Core Workflows vs Elsa

[Skrypt]

Since the Workflow module in OC has not been updated with new features since a while I was asking myself which features Elsa now has that the OC Workflow module doesn't.

Also, @jtkech is currently planning working on the distributed aspect of OC Workflows which I can see that it's planned for 2.0 version of Elsa. In OC we have been specifically instructed to not use any message bus for doing this. Instead it is working with a distributed cache with locking mechanism and atomicity check.

The question I'm asking myself is if it would be worth starting to think about using Elsa and implement it inside Elsa instead of continuing investing time in the current OC Workflow module. Consider that we made some tweaks in the OC Workflow module over time that should be maybe also required in Elsa unless you tracked those over time.

[sfmskywalker]

Hi Jasmin, great to see you here :)

I think Elsa would be a great fit as the workflows engine of choice for Orchard Core.
As a matter of fact, I started working on a module earlier this year: https://github.com/elsa-workflows/elsa-orchard-core

A number of advantages to use Elsa:

• It's a general-purpose workflows library that is also used outside of Orchard Core, which means it is more actively maintained and has more developed features.
• Advanced features such as composite activities and workflow templates are coming. See also this backlog.
• Developing activities requires less ceremony than is the case with Orchard Core Workflows: no display drivers needed (unless you want to introduce custom activity property type editors)
• A better UI (coming with Elsa 2, thought this is currently under development). I'm working on both a full-blown Blazor application for the Elsa Dashboard as well as a set of react-based components for reuse in existing web applications (which is what I'd use when implementing Elsa in Orchard).
• Multi-node support via distributed locking. This is implemented using a provider model, which means applications can choose which strategy to use. Out of the box come SQL Server, Redis and Blob Storage. If Orchard Core has a distributed locking mechanism, the Elsa Orchard Core module could provide an implementation using that.
• It can be hosted in-process (like Orchard Core Workflows does today), but it also opens the door to allowing workflows to be hosted in a separate process (separate ASP.NET Core host application), in which case you use Orchard Core's admin to manage these workflows. Orchard Core after all can be put to good use as a modular dashboard application, which is something that the Elsa Dashboard application isn't (although I am working on a modular Blazor dashboard for Elsa).

My plan is to continue working on the Elsa Orchard Core module soon as Elsa 2 is merged to master and the React components are ready to be reused.

But if you're interested, I'd be happy to walk you through the Elsa Orchard Core module and perhaps continue working on it already on things like workflow management (which doesn't require the react components to be finished yet).

Bottom line as far as I'm concerned: Elsa will be coming to Orchard, even if just as a third-party module.

[Skrypt]

Ok, thanks for your detailed answer. I will take some time to analyze the React component.
How much work do you think is left to do on it to get a production ready component?
I think you need a hand here right?

[sfmskywalker]

Development of the react component has only just begun. In fact there's primarily some bootstrapping with a sample button component to try out Storybook. You can follow development of it here: https://github.com/elsa-workflows/elsa-designer-react

I'd say there's a fair amount of work left to be done, but I just got started and it's the top item on my shortlist for Elsa. Schedule-wise, I am working on this on and off during the evening, and more during the weekend. Starting January however, I'll be working on Elsa full-time, so the pave of development will pick up by then.

Obviously any help is welcome :)