Part 1 - UI driven by Elsa Workflows
This series describes the implementation of a User Interface driven by an Elsa workflow engine.
Several different steps will lead to a fully working implementation. This implementation might not give you the silver bullet for your specific needs. Still, it will provide insights into the various options. This series is not an extensive step-by-step implementation guide. There will be code snippets but, it is more about the concepts, and the effects they might have on the application setup.
For those who don’t know Elsa, Elsa is an open-source suite of .NET Standard libraries and tools that enable developers to implement long-running workflows. Elsa’s core philosophy is to connect small executable units, called activities. These small units allow you to orchestrate business processes such as document approval, customer onboarding and order fulfillment.
Here’s what we’ll be doing:
- Create a unit that suspends the execution of a workflow until a signal and additional data are received. This will be the base for the user task activity.
- Create a UI that can collect all the user tasks waiting for execution.
- Send the signal from the UI to the engine to continue the execution.
- Extend the user task so it can describe the requested data.
- Make the UI reactive by waiting for engine signals instead of polling the engine.
Because there’s a substantial amount of code editing involved, we’ll be doing all this in separate parts:
- Part 1 — Settings up the project
- Part 2 — Creating the user task activity
- Part 3 — Extend the user task with data
- Part 4 — Make User Interface to be guided by a workflow
- Part 5— Use notifications to update the User Interface
- Part 6— Use a user task at the start of a workflow
The techniques used in this series are
- Elsa 2.10.467
- Blazor App
- C#
- SignalR
Even though Blazor is used to build the User Interface, the same concepts will apply to other UI solutions. So, the main giveaways will still hold up.
The complete solution can be found here, including a branch for each part.
Key concepts
Before we can do the actual work, it might be handy to briefly introduce the different elements in the context of Elsa’s workflow execution.
Blocking activities
In Elsa, blocking activities can be used to trigger the start of a workflow or resume suspended ones.
The workflows in ELSA 2 are executed in a per branch execution, which means that when the workflow splits into multiple execution branches, the engine will execute each branch until it reaches the end of the workflow or it encounters a blocking activity. Blocking activities will not stop the entire workflow but only the specific branch.
Bookmarks
A bookmark is a small information indicating workflow instances waiting to be started or resumed to the Engine.
You can think of bookmarks as indicators where you stopped reading the book and where to continue after you paused.
Controller
A controller provides endpoint(s) to extend the Engine to have more entry points for interaction.
The controller allows interaction with the Engine. Elsa’s open architecture enables extending additional functionality. One is to add controllers to the extent of the API in the Engine.
Details can be found here: Writing Blocking Activities · ELSA (elsa-workflows.github.io)
If you read this article, you will find that Elsa already has a user task activity. However, this series creates a new activity that distinguishes the activity from the existing one because the new one is specifically for a UI user task. Besides that, it also shows how you can create your activities.
Part 1 — Setting up the project.
The solution consists of 2 projects: a Blazor app and an Elsa Engine. Just create a solution and add the projects. For the Elsa engine, you can also opt for having the dashboard installed. It provides accessible insights into the execution of the workflows. In addition, it gives options to see if the workflow instance holds the values provided by the UI.
The Elsa server project is a straightforward implementation of the engine and a Blazor app. The tutorial for setting up the engine will not cover all details when using .NET 6.
The adjustments needed for the .Net6 setup, including the swagger base implementation, are mostly in the startup class.
The Blazor application is a typical installation.
In the following parts of this series, this application is extended with the logic to interact with the engine. It is essential to know that the design will not reference the engine. So, in some cases, the DTO objects are defined in both projects.
The project aims to have an engine that drives an independent UI application. The Elsa engine, in turn, doesn’t know the details of the UI application. Instead, the Elsa engine will provide details about the expected data types. It is up to the UI application to opt for using that info or having its implementation.
The end result of the installation can be found here:
FransVanEk/ElsaDrivenUI at feature/phase1-construction (github.com)
Next: Part 2- Creating the user task activity
Used version: Elsa 2.10.467
