Question: How to follow Dev Branch?

[GeorgeS2019]

@sfmskywalker
Thx for making great progress.

Just wonder how to follow and test what has been developed

The WASP client itself will not run on its own?

[sfmskywalker]

Thanks!

The studio needs to be able to connect to a running Elsa Workflows server. What I do during development is have the Elsa.WorkflowServer.Web project running (from the v3 branch in the elsa-core repo in the bundles folder).

Before you can run the Studio (either Server or Wasm from the hosts folder), you need to build client assets using npm install & npm build, in the Elsa.Studio.Workflows.Designer project’s ClientLib folder (look for the folder containing package.json).

I’m also happy to share a screen and show you, just let me know.

[GeorgeS2019]

@sfmskywalker

Here is the break when attempting to run Elsa.WorkflowServer.Web with the error below

What steps did I miss. Thanks

Microsoft.Data.Sqlite.SqliteException
  HResult=0x80004005
  Message=SQLite Error 1: 'table "WorkflowDefinitions" already exists'.
  Source=Microsoft.Data.Sqlite
  StackTrace:
   at Microsoft.Data.Sqlite.SqliteException.ThrowExceptionForRC(Int32 rc, sqlite3 db)
   at Microsoft.Data.Sqlite.SqliteCommand.<PrepareAndEnumerateStatements>d__64.MoveNext()
   at Microsoft.Data.Sqlite.SqliteCommand.<GetStatements>d__54.MoveNext()
   at Microsoft.Data.Sqlite.SqliteDataReader.NextResult()
   at Microsoft.Data.Sqlite.SqliteCommand.ExecuteReader(CommandBehavior behavior)
   at Microsoft.Data.Sqlite.SqliteCommand.ExecuteNonQuery()
   at System.Data.Common.DbCommand.ExecuteNonQueryAsync(CancellationToken cancellationToken)
--- End of stack trace from previous location ---
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.<ExecuteNonQueryAsync>d__15.MoveNext()
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.<ExecuteNonQueryAsync>d__15.MoveNext()
   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.<ExecuteNonQueryAsync>d__15.MoveNext()
   at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.<ExecuteNonQueryAsync>d__1.MoveNext()
   at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.<ExecuteNonQueryAsync>d__1.MoveNext()
   at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.<ExecuteNonQueryAsync>d__1.MoveNext()
   at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.<ExecuteNonQueryAsync>d__1.MoveNext()
   at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.<MigrateAsync>d__15.MoveNext()
   at Elsa.EntityFrameworkCore.Common.RunMigrationsHostedService`1.<StartAsync>d__2.MoveNext() in \elsa-core\src\modules\Elsa.EntityFrameworkCore\Common\RunMigrationsHostedService.cs:line 22
   at Elsa.EntityFrameworkCore.Common.RunMigrationsHostedService`1.<StartAsync>d__2.MoveNext() in \elsa-core\src\modules\Elsa.EntityFrameworkCore\Common\RunMigrationsHostedService.cs:line 23
   at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>d__12.MoveNext()
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.<RunAsync>d__4.MoveNext()
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.<RunAsync>d__4.MoveNext()
   at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
   at Microsoft.AspNetCore.Builder.WebApplication.Run(String url)
   at Program.<Main>$(String[] args) in \elsa-core\src\bundles\Elsa.AllInOne.Web\Program.cs:line 75

[sfmskywalker]

Sounds like you need to delete the Elsa.SQLite.db file.

[GeorgeS2019]

Elsa.WorkflowServer.Web

• Elsa.Studio.Host.Wasm => fail

• Elsa.Studio.Host.Server => run

[sfmskywalker]

I tried the Wasm project, which didn't build due to, I guess, not having installed the latest .NET SDK while having updated the packages recently. After updating to the latest version of the SDK, I was able to build & run the Wasm project.

[GeorgeS2019]

Work -> Elsa.Studio.Host.Wasm

[GeorgeS2019]

@sfmskywalker

First Blazor Workflow Designer

AdrienTorris/awesome-blazor#639 (comment)

[GeorgeS2019]

@sfmskywalker

Please correct me if I am wrong, the diagram part uses typescript.

I wonder how much work to replace that with Blazor Diagram, (more of trying to get the Blazor Diagram community to contribute) => to have a elsa-studio version using Blazor Diagram and ALL c#

[sfmskywalker]

You're not wrong, the diagram part uses X6, which is a JS library.

Although I am not planning on replacing that implementation with Blazor Diagram, Elsa Studio is designed in a way that allows for the existence of multiple diagram designers. This means that one could build a custom module that uses Blazor Diagram instead.

[Dishone]

Can you publish these packages on nuget?

[sfmskywalker]

Once the project is stable enough for a release candidate, I will update the build pipeline to deploy the packages to NuGet. Until then, you can get them from this feed: https://f.feedz.io/elsa-workflows/elsa-3/nuget/index.json

[Dishone]

thanks and have a nice day

Once the project is stable enough for a release candidate, I will update the build pipeline to deploy the packages to NuGet. Until then, you can get them from this feed: https://f.feedz.io/elsa-workflows/elsa-3/nuget/index.json

[sfmskywalker]

@GeorgeS2019 I think the question raised in this issue has been answered. If you agree, can we close it?

[GeorgeS2019]

I post here from a discussion from Discord:

Blazor with Elsa Combinations

There are several approaches to use Blazor with Elsa:

Approach One

This could involve embedding Elsa inside of the Blazor app, allowing it direct access to Blazor APIs.

Approach Two

Another approach is having a separate workflow server, where the Blazor app interacts with the workflow server via HTTP requests.

Approach Three

Yet another approach builds on the former one, but with bi-directional communication (e.g. via websockets / SignalR), allowing the workflow server to send messages to the Blazor APP when it is e.g. time to move to the next page.

Depending on the desired approach, one must create custom activities that model UI navigation at a certain level of abstraction. For example, you could envision a custom activity called DisplayPage. The implementation depends on the desired communication between Blazor and Elsa. If Elsa is hosted directly oinside of the Blazor app, the activity can interact with the navigation API directly. On the other hand, if Elsa is hosted in a separate ASP.NET Core app, the DisplayPage might create a bookmark and respond with an HTTP response to some initial HTTP request made from Blazor. The response includes necessary details to resume the bookmark when the user e.g. clicks "Next" - resulting in another HTTP request sent to Elsa, which resumes the workflow, until another DisplayPage is encountered.

With regards to the side question: Yes, one can mark workflows as "read only" - Elsa Studio will then display them as read only.

https://medium.com/@fanekkie/part-1-ui-driven-by-elsa-workflows-6d0e868ea6c

Other feedback

For my first test I am trying to create the workflows directly in Blazor but they're not in the same scope/thread as the UI so I'll probably have to do some sort of abstraction anyways. Just need to find a concrete example of what mechanisms I can use to facilitate that communication layer. Currently looking at how some folks have done it with background HostedService type deals for inspiration.

=============
I am looking to orchestrate a multi-page data entry wizard on Blazor Server with conditional branching into a workflow engine. I'm leaning towards Elsa because the studio looks pretty neat. All of the existing examples are heavily backend oriented though and I'm having trouble figuring out where to get started on the front-end. I'd like to build a simple PoC which takes a variable, navigates to one of two pages based on that variable, pauses (bookmarks?), waits for input from a form, posts it to an API, then navigates again when it gets the result.

I'm stuck on the first step: navigation. I can't simply create an activity that calls the navigation manager because it is on a different thread. In Blazor server each user must have their own instance of the workflow and the signalr connections are often brittle so it will need to be able to resume the workflow from any point if the connection is lost or the page is reloaded.

There is a bit of prior art here https://medium.com/@fanekkie/part-1-ui-driven-by-elsa-workflows-6d0e868ea6c, but it's using Elsa v2 and seems to only navigate as a result of a finished workflow.

Unrelated side question: I'll probably define workflows in code or JSON but it would be nice to have studio set up as a readonly showcase rather than a tool for authoring. Is this a supported use case?

I'll keep digging into this on my own but figured I'd post here to see if anyone had thoughts. Thanks!

https://elsa-workflows.github.io/elsa-documentation/application-types.html