Get possible transitions

[Bykiev]

In Windows WF we can get possible transitions in StateMachine workflows. How can I get possible transitions for specific instance and move to specific state with Elsa? Btw, what is the difference between Resume and Invoke methods? Sorry, lack of docs makes it hard to understand how to use this awesome library...

[sfmskywalker]

@Bykiev No worries, I'm happy with the questions as it helps shape my priorities and understanding of people's use cases 👍

Perhaps you can explain a little bit more of your scenario? What you can do today is invoke a given workflow, which then executes that workflow.

The Invoke method creates an instance of the specified workflow definition and returns a WorkflowExecutionContext that contains the workflow instance and a list of activities that the workflow is being blocked on (in a state machine, this would typically be just one activity, aka the current "state" of the state machine).

The Resume method takes a workfow instance and continues execution from the current state of that instance.

There's more to all of this, and I do intend to document how things work over the next couple of weeks and months. In the meantime, I'm happy to answer any questions you run into, so keep'm coming!

[Bykiev]

@sfmskywalker, thank you!
My use case as follows: I have 4 states: State1 can be transitioned to State2 (manually) or to State3 (this state can be set only automatically by the delay, if understand correctly, it's a Cron Activity in Elsa). State2 can be transitioned to State4 only by users in specific roles. When I'm on State1 I need to get possible transitions (State2, not State3, because it's auto transition activity), and when we on the State2 get only possible transitions allowed to user role. In Windows WF It is possible by using Bookmarks, I've never managed to implement role-based transitions using ASP .NET Identity roles.

[sfmskywalker]

With Elsa, the way you would manually transition from State 1 to State 2 would be to "trigger" the workflow using "State 1" as the activity, which more or less is the equivalent of a WF Bookmark. And, as you said, using the Cron activity, or a Timer activity if you just want a (recurring) timeout, state would automatically transition to State 3, depending on what happens first: a manual trigger on State 1, or an automatic trigger on the Cron or Timer activity.

Regarding the role-based transition, you would be able to implement this today using a yet-to-be-implemented activity called e.g. Is User In role.

The following is a simplistic visualization of what the state machine would look like:

So, from your point of view, the following would happen:

1. You would first trigger the workflow, which will automatically execute the State 1 activity.
2. The workflow is now blocked on Cron and State 2.
3. If Cron triggers first (automatically), the workflow transitions to State 3, ending the workflow.
4. If you manually trigger State 2, the workflow transitions to the Is User In Role activity.
5. The Is User In Role activity only continues the workflow if the current user (to be specified as an input of the workflow) is in one of the specified roles (Admin and HR in this example).

Let me know if this setup would work, or if I'm missing something important.

[Bykiev]

@sfmskywalker, thank you! I've also another case, it's looking like a standard approval process: after creating document manager can approve document by selecting 'Approved' status or decline by selecting 'Declined' status. In such case I need to get a list of possible transitions for user to fill status list (the real order could be changed by system administrator (a new status can be added and etc.), so I need to follow workflow states order), how to achieve it?

[sfmskywalker]

@Bykiev You got it. The standard approval process is a perfect example. With Elsa, you would add e.g. a User Action activity, that you can configure with allowed actions (e.g. "Approve", "Decline", "Needs Work", etc, some description maybe, and basically anything else that would be relevant for your scenario.

I'll ensure that you'll be able to query workflow instances in all sorts of ways. For example, you'll be able to get a list of all workflow instances that are blocked on "User Action". You'll then be able to get the possible user actions for each such workflow instance, which enables you to e.g. render a UI with a list of tasks that a user need to review, and click on any of the available actions. Clicking an action will cause the workflow instance to be resumed with the clicked action. This UI & click handling will be up to you of course, but the library will provide the necessary APIs to achieve all this.

[Bykiev]

@sfmskywalker, awesome! Sorry, I didn't get the idea of using User Action activity, can you please explain it? All I need is a state machine and API

to get the possible user actions for each such workflow instance

I see one more use case: in approval process the document should be approved by at least N persons, how to achieve it with Elsa?
Thank you for your time and efforts!

[sfmskywalker]

@Bykiev No worries! So, the idea of the User Action activity is that it's a blocking activity (a trigger somewhere in your workflow). This means that in order for the workflow to continue, it needs to be resumed with a given action (one of the actions defined on the User Action itself). To resume such a workflow, your application will have to be able to query the workflow and the defined User Actions (associated with the User Action activity), so that your application can e.g. display these actions as buttons the user can click.

Here's a demonstration of how that works in Orchard: https://www.youtube.com/watch?v=iioKQkXUwXA

Regarding the number of required approvals, that too can be easily done using a While activity and the Set Variable activity. You would first initialize some variable, say Approvals to 0. Then the While activity would be configured to loop as long as Approvals < N. IF the condition is not met, it connects to the User Task activity. As soon as User Task is triggered, the While condition is evaluated again. Once the condition is met, it exits the loop onto the next activity, e.g. mark the document as approved.

Hope this helps, but let me know if you're unsure about anything I mentioned. I'll be sure to write a tutorial on how to achieve this as soon as I got my ducks in a row with the refactoring that's going on atm.

[sfmskywalker]

Created issue for User Task here: #43