[erlang-questions] Workflow process model

[Charles Irvine]

I do realize that workflow state will need to be stored to a database. I don't envision much in the way of client sessions. The thing that will drive the system are task completions. Task completion adds information to the workflow context and generates new tasks to be completed. 

I am new to Erlang and I read that the challenge is to create the correct process model. So, I am trying to figure that out.

Thanks!

Sent from my iPad

> On Oct 29, 2013, at 3:17 PM, Chris King <colanderman@REDACTED> wrote:
> 
> You probably want to use a database (such as mnesia).  Processes won't survive a system crash.  Use processes for more transient state machines (such as client sessions).
> 
> 
>> On Tue, Oct 29, 2013 at 3:02 PM, Charles Irvine <chuck.irvine@REDACTED> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131029/ad5b2c01/attachment.htm>