Add support for Workflow Model

Currently, a workflow can define variables to store and retrieve state using SetVariable and GetVariable activities and methods. This works fine, but the syntax can become a bit cumbersome.

What we could have in addition is the notion of a “model” (or data or state) that is just like a variable, but available through a new strongly-typed property called Model. This would be somewhat analogous to the Model property on a Razor view.

This allows the user to define workflows that look very similar to the way it’s done in Workflow Core:

public class MyModel
{
	public string Email { get; set; }
	public string Password { get; set; }
	public string UserId { get; set; }
}

public class MyWorkflow : IWorkflow
{
    public void Build(IWorkflowBuilder<MyModel> builder)
    {    
        builder
            .StartWith<CreateUser>()
                 .With(activity => activity.Email, model=> model.Email)
                 .With(activity => activity.Password, model => model.Password)
           .Then(context => context.Model.UserId = context.Input<string>())
           .Then<SendConfirmationEmail>()
                .With(activity => activity.Email, model => model.Email)
                .With(activity => activity.UserId, model => model.UserId)
           .Then<WaitForConfirmation>()
                .With(activity => activity.UserId, model => model.UserId)
           .Then<ActivateUser>()
               .With(activity => activity.UserId, model => model.UserId);
    }
}

[craigfowler]

@sfmskywalker This is very interesting, partly because it touches on something I was planning on discussing after Elsa 2.0. That’s the separation of State and Functionality within activities.

My waffling about architectural ideas

Right now anything implementing IActivity has to maintain both its own state as well as the methods like OnExecuteAsync etc. To simplify the API I was going to talk about separating those two things into two classes. There’s probably some fringe benefits too, such as making serialization easier and also reducing memory overheads because each specific activity instance is now a stateless service (so we need fewer instances).

What I had in mind was that IActivity defines only that the state of an activity is System.Object (which could be null for a stateless activity) but there would also be a generic IActivity<TState> where TState : class. Developers writing their own activities implement the generic interface and on the activity class they’re just writing the functional methods which define how the activity works. Then, for the activity state they write a small POCO model/state object.

Those functional methods (again, example is OnExecuteAsync) - in the generic version of the activity interface - would provide an instance of that model/state as an additional parameter:

ValueTask<bool> CanExecuteAsync(ActivityExecutionContext context, TState state);

Combined with some other tricks, we might be able to do away with the base Activity class altogether (and I’m a strong believer in eliminating class inheritance where possible). If consumers only need to implement an interface then their code becomes simpler and also easier to unit test (which means more chance that they will actually write them).

Triage & priority

Anyway - all of that aside - I’m going to mark this up as do later because you’ve not added it to the 2.0 milestone. I figure that means you intend to revisit this in 3.0 or later. Feel free to move to do soon if you think this should be looked-at earlier.

[zbogdanov]

Hi @sfmskywalker! First of all, thanks for all the great work you did so far.

Secondly, I’m currently evaluating Elsa for our own internal needs to power a very extendible and large set of mission-critical workflows. We decided to investigate third-party solutions when we finished the design (on paper) of our own in-house solution, and then comparing the two for requirements.

One of the most useful things for our needs is the “Workflow Context” concept, where as the workflow gets activated and starts to run, a last snapshot of the full context is retrieved from the data store and the rest is generated dynamically - creating one big model to be used by the workflow for evaluation and other needs. The context can get updated as the workflow runs also by set variable activities. Right now Elsa does not have this and this would be one of the first things we would need to extend if we decide to go with Elsa, so this feature is a great idea I think.

I’ll be keeping an eye on this PR and If we decide to go to Elsa, I’ll probably volunteer to help out with this feature if it will not be done by then.

Thanks again, keep up the fantastic work!