On Dec 11, 10:56 am, Enrico Bianco <[email protected]> wrote: > On Dec 10, 3:34 am, John Mettraux <[email protected]> wrote: > > > > > > > As a side note, I came to appreciate this article : > > > http://www.infoq.com/articles/seven-fallacies-of-bpm > > > Here is my favourite quote : > > > ---8<--- > > I know a lot of people will tell me that it is a process, but it is > > not. It is a service implementing the lifecycle of a Job Application > > independent of the processes and activities that may advance the state > > of the job application. A process is the set of activities that > > advance its state. Resource Lifecycles and processes are decoupled, I > > don't think anyone can argue with that, yet everyone is trying to > > model and implement processes without a clear understanding of the > > resource lifecycles, they are more or less "built-in" the process > > model. > > --->8--- > > I would like to add that I learned this lesson the hard way when > trying to automate a member registration process for the company I'm > working at. I was trying to manage both the processing of the > application (by which I mean the application that the end user is > submitting to become a member) and its lifecycle within the process > definition, but that made the process very vulnerable to definition > changes. If we wanted to change the definition and have that apply to > currently running process instances, we'd have to either rewrite the > expressions (ick!) or cancel and restart the process, which would > cause the current state of the application to be lost! > > Based on an exchange I had with John on this mailing list, I've re- > implemented that process so that the state of the application and the > steps to advance the application through its lifecycle are separate. > The lifecycle is now represented by a state machine (implemented using > state_machine) and the process definition is structured such that it > determines which steps need to be taken based on the state of the > application and triggers state changes as necessary. Now, changing the > process is as easy as manipulating the state machine objects directly, > cancelling the running processes, and restarting them. We could even > subtract ruote from the picture entirely and manage applications in an > entirely different way, if we wanted to. > > In summary, separating the lifecycle of the object from the process > that brings the object through that lifecycle has solved many problems > for us and given us a great deal of flexibility moving forward. > > - Enrico B
I should also add that in contrast to Kenneth's example, I'm actually using one large process instead of many small ones. The state machine doesn't cause any processes to be launched; instead, the process is launched and then queries the underlying state machine to figure out what it is supposed to be doing and fires off events within the state machine as it progresses. -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
