[erlang-questions] Workflow process model

[Martynas Pumputis]

Having done both approaches (one with "business process as an Erlang
process" and the other "database-centric with bunch of workers"), I
would suggest to answer yourself the following questions:

* is persistence needed? you might want to store either each
incoming/outgoing event or events + state transitions for each process.
The latter is needed, if your transitions have side effects which can't
be reflected by events and in a case of failure your system global state
can't be restored from events.
* do you need fault-tolerance ? Erlangish approach requires you to
ensure that only the one instance is running at given time (hence,
leader election).
* are transitions triggered only by request messages ? if not, then you
will need timers. it comes out of the box with Erlang processes. you
probably just want them to survive process crashes. implementing timers
might be quite painful, if your BP can be handled by any worker residing
on any node and you don't want to send duplicated timer events.
* live process logic (code) upgrade, do you need it or maybe you can
stop the system for doing that ?
* how many running instances do you plan to have at once?
* how many different types of process ? anyway, you will implement your
own generic behaviour.

Martynas

On 10/29/2013 08:02 PM, Charles Irvine wrote:
> I plan to write a BPM (Workflow) engine in Erlang. I’m struggling with what the process model ought to be. Suggestions would be greatly appreciated. Here’s the general structure of the system:
> 
> Users construct a process model for an purposeful activity. Let’s say the activity is to fix a software defect. The process model is a set of tasks sequenced to achieve the goal of the process. The process model for fixing a defect would be:
> 
> OpenDefect -> WriteCodeToFixDefect -> DeployFixCodeToTestEnv -> TestFix -> DeployCodeToProd
> 
> A single instance of this flow of task completion I call a workflow instance. There may be a large number of such instances in progress concurrently. The state of a workflow instance is a set of outstanding tasks ready to be performed and what I call a workflow context. A workflow context is a set of informational artifacts accumulated as the workflow progresses.
> 
> For example the state of defect resolution workflow instance might be an instance of the task WriteCodeToFixDefect and the context would be a defect description.
> 
> I’ve considered making each such workflow instance a process but I hesitate to do this since a process may have a relatively long lifetime and there might be a long duration between significant events. For example, a defect might not get fixed for weeks or months and a long time could elapse between the time the defect is reported and the time that someone starts working on it.
> 
> A little nudge or two from folks more skilled than me at this would be much appreciated.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>