Could discussion, guys. This helps a lot. Regards, Gerben On 11 dec, 17:10, Enrico Bianco <[email protected]> wrote: > 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
