How to persist workflows into storage?

[denis-ivanov]

Hello!
In my production project I want to persist workflows into PostgreSQL. In Startup I have the following Elsa configuration

services
    .AddElsa(elsa => elsa
        .AddEntityFrameworkStores<PostgreSqlContext>(options =>
            options.UseNpgsql(elsaConnectionString)))

When I start workflow, in WorkflowExectionContext I can see blocking activities, but all tables in the PostgreSQL are empty.

According to README

Elsa has native support for long-running workflows. As soon as a workflow is halted because of some blocking activity, the workflow is persisted. When the appropriate event occurs, the workflow is loaded from the store and resumed.

I thought that workflows are stored automatically, but it doesn't happen.
And my question is: is it bug or I have to do something special?

[ZlobnyiSerg]

The reason was we put complex object as variable into WorkflowExecutionContext, once this done, workflow stops persisting into DB without any errors. This can be potentially very dangerous bug and should be fixed, I think.
Consequently new question arises: is it possible to provide custom complex context to Activity without persisting it into DB? We have complex business-objects with large models, and would like to able to use these fields in workflow's expressions. How this can be achieved?

[denis-ivanov]

And next is question how to track such silent exceptions?

[sfmskywalker]

@denis-ivanov You shouldn't have to do anything specific for workflows to be persisted, so it might be a bug. I haven't been able to reproduce this with Sqlite, but I'll try with PostgreSQL as well.

[sfmskywalker]

@ZlobnyiSerg Can you explain why storing objects in WorkflowExecutionContext could be potentially very dangerous? What exactly should be fixed?

With regard to your question, there's currently no means to that end in Elsa 1, but in Elsa 2 there's a thing called a Workflow Context, which can store a complex object at runtime but that isn't persisted as part of the workflow, while at the same time, it is automatically loaded from and optionally persisted to your own data store by means of a custom workflow context provider. Every activity has access to this object, offering the best of both worlds: access to a complex object (provided using your own provider implementation for a given workflow context type) that is automatically loaded (with a configurable "fidelity", allowing the object to loaded once before a run-through of activities until the workflow finishes or gets suspended, or before every activity, in case of applications where the object might change often and you want to ensure to always have the latest version in memory).

[ZlobnyiSerg]

@sfmskywalker I meant that this is very serious bug if workflow does not persists state in database and fails silently.
Thank you for explanation about custom context-objects, it seems we need Elsa v2 for our needs.

[sfmskywalker]

Ah, yes that would be bad indeed. However, there should be an exception handler surrounding workflow execution, putting the workflow instance into the Faulted state. If this is not the case, might I ask you for repro steps?

[sfmskywalker]

By the way, instead of storing values into the Variables object, you can use the TransientState object on the WorkflowExecutionContext. It's the same as Variables, with the exception that these values never get persisted.