Implement State activity

The State activity is a simple activity that enables implementing state machines with the following features:

• Exposes a property called Name representing the name of the state.
• Exposes a property called Transitions representing a list of possible transitions that yield activity outcomes.
• Sets a workflow variable called CurrentState to the name of the State activity.

The way it works is that as soon as the State activity executes, it will set the CurrentState workflow variable to the value of the state’s Name property. It will then return multiple Outcome results, one for each defined transition.

The idea is that each transition will be connected to a halting activity that represents an event. When such an event is triggered, the state machine will transition into the next State (assuming the connected activity is another State activity). All blocking activities connected to the previous State will be cleared. This works similar to the way the Fork and Join activities work together to branch out and merge back.

[craigfowler]

That might help. That said it’s kind of complex in our case but I wonder how much Elsa should be modified in order to accommodate one specific usage. Also as noted toward the end - we’re not 100% sure what we want to do with this architecturally in the long term. Right now we are concentrated on just swapping what we have with a new backend, but making as few architectural changes as possible.

What we have right now is essentially:

1. Halt the workflow
2. Enumerate a list of possible-actions which could resume the workflow (a bit like UserTask except that each of those actions has a small model of metadata attached, not just a string)
3. A service (alongside the workflow) which reads the current state of the workflow and also gets a list of the permitted actions which may resume it
   • It is in this service logic that we have all of our permissions logic
   • What we do is get the complete list of every possible action from the workflow, but then filter-out actions which the current claims principal wouldn’t be allowed to select
   • Some actions are also not allowed to be interactively selected and are selected by the app framework based on specific circumstances
   • The remaining actions that are allowed to happen next are displayed to the end user as buttons in the UI
4. We may then resume the workflow using one of those actions if it is either selected in the UI or auto-selected via a non-interactive process

An example of a non-interactive action is a “merge conflict” of sorts. We’re using Elsa for “Approval of draft data that is ultimately destined for the app domain database”. We also have validation alongside that. A creator/author of draft data can’t submit successfully if their data is invalid. Additionally (for accountability purposes) approvers are not permitted to edit the draft data upon approval. If they disagree then they may only reject & leave feedback messages suggesting fixes (the creator/author may then take another try at submitting).

Now, imagine the creator submits something that is valid for approval. But, by the time someone opens the draft data for approval it has somehow become invalid. There’s quite a few scenarios that could lead to this, but one of the most common is that a different user made a conflicting change to that same underlying data, much like a source control merge conflict.

In that scenario we automatically-select a “failed and not worth showing to the approver because they aren’t allowed to fix it” action and send it straight back to the creator/author with appropriate feedback so that they can fix it.

All of that logic we have implemented alongside Elsa right now (albeit still “behind” our workflow abstraction). We might be able to integrate some of that more closely with Elsa later down the line, but right now we are trying to keep those scope on the work down by doing a like-for-like replacement with our old workflow. Architectural improvements will come in a later release.

[sfmskywalker]

So perhaps the library might expose hooks or events during transitioning between two states, allowing application-specific code to control whether or not the transition is allowed.