I'm trying to implement a parallel split task using a workflow system. I'm using .NET but my process is very simple and I don't want to use WF or anything heavy like that.
I've tried using Stateless. So far is was easy to set up and run, but I may be using the wrong tool for the job because I'm not sure how you're supposed to model parallel split workflows, where you have multiple sub-tasks required before you can advance to the next state, but the steps don't require being performed in any particular order.
I can easily use the dynamic configuration options to check my data model manually to see if the model is in the correct state (all sub-tasks completed) and can transition to the next state, but this seems to completely break the workflow paradigm. What is the proper, orthodox way to implement a parallel split process?
Thanks
Best Answer
In this new answer I will try to explain based on the "Stateless" library mentioned in OP.
Draft.
More information will be added after I get my hands on Stateless.
In any sense, extension to Stateless is required. Fortunately this is highly doable because Stateless is highly extensible using its partial class approach.
A simple description is that:
StateMachine
object. See link to library.Stateless
library object), which might be implemented in several ways.The typical states in a Activity object:
Sometimes, a single activity in human sense must be broken down into multiple activities in software implementation. This will have implications on the design of the Graphical User Interface (GUI). In short - GUI can get very complicated.
Example: a business process modeler will regard "wait for email approval" as one activity. Internally, it is broken down into these activities:
Displaying all these details on the GUI will make it difficult for the user. Instead, the user should only see options that the user intends to configure.
Almost all interactions (dependencies) between activities are modeled as the "Waiting" state.
WaitingOnPreconditions is the simplest type. Simply speaking, it can wait on final states but not states that flip-flop. Usually, it waits for a set of activities to all transition into the "Succeeded" state. (On the opposite side, it can also wait on "any activity that transitions into the "Faulted" state - this makes it an exception catcher.)
Because the inputs to WaitingOnPreconditions are not allowed to flip-flop, the outcome of WaitingOnPreconditions will also not flip-flop. This is the essential distinction between WaitingOnPreconditions and WaitingOnInternalTrigger, described below.
WaitingOnInternalTrigger is more dynamic than WaitingOnPreconditions. It waits on some observable variables on the business process object to change to a certain value, or some other activities to change their states.
Once entered this state, the activity's
StateMachine
stays there, unless requested (programmatically) to re-check. The check might be performed with a predicate,Func<bool>
, or lambda expression.The business process object contains some variables that have
INotifyPropertyChanged
interface. When that event is raised (that is, when the variable value is updated), activities that are in this state (WaitingOnInternalTrigger) will be re-checked.To avoid indeterminacy or deadlock, the re-check is only allowed to use variables which it can observe. Otherwise, nobody will notify the activity of the relevant changes, and the activity will thus stuck in this state forever.
WaitingOnBusinessProcess is used when an activity embeds another business process. That other business process runs somewhat independently (in software sense), and the current activity will wait for it to finish, cancel, or fault.
WaitingOnBusinessProcess is re-checked whenever the business process it is waiting on has changed state.
WaitingOnExternalTrigger is a mechanism to block the activity until it is unblocked by some other means. For example, it might be waiting on some user interaction, or an approval email. Unblocking is done programmatically - not by another activity or business process.
Every WaitingOnExternalTrigger must have an associated exception catcher (mentioned earlier). This is because all external processes are presumably unreliable, e.g. the employee responsible for this business process might be fired on the spot, (or the email server was struck by a disaster) and thus unable to continue the process.
Other references (not used in my answer)
Disclaimer: my employer makes BPMN software. However, I do not work in the BPMN product team, and my answer is not representative of my employer's viewpoint. I do not have any privileged knowledge of the BPMN product.