On Fri, Feb 03, 2012 at 04:32:40PM -0800, kedar mhaswade wrote: > > Well, I meant process definitions. And that is the confusion I have. My > understanding with dynamic workflow was that it is a process that is not > fully determined at the time of initial creation and instead is defined (at > least partially) at run-time. For instance, the user who created the > process determines next steps after a checkpointing step has been reached. > And it is this user who I termed as process administrator. I guess my > terminology is wrong. Does such an interpretation of "workflow" make sense? > Or does the process definition have to be usually determined a priori?
Maybe this might interest you: http://jmettraux.wordpress.com/2010/01/29/barley/ Maybe "process owner" or "process initiator" is better. On the other hand, if you like "process administrator", you could rename the guy who plays with ruote-kit the "ruote administrator" or simply the "system administrator". > > The admin interface is handy for administering the system, not really to > > design process definitions. > > I see. But since some of my users need to be given a web interface to > create/modify the processes, it is important for me to do more than text > editor? Unfortunately, I'm sure you'll find the process editor included in (and extractable from) ruote-kit very limited, it will certainly set off your users. On the other hand, if you go for very dynamic workflows, process edition can be limited to "choose who comes next" and there is no need for a text area or graphical process editor for that. > > Maybe you meant modifying process instances and in that case, yes, the > > admin > > interface offered by ruote-kit is handy (for process administrators). > > Process instances are modified by the actions taken by participants is what > I thought I read, e.g. in the "getting started" example (which I ran), the > state of process instance was modified when :alpha got a message and then > passed it on to :bravo via the workitem. The process definition itself was > fully determined -- a sequence of two participants, :alpha and :bravo. > > Am I not understanding it right? Makes sense, I would rather say "handling a workitem" or "performing a task" in those cases, but you are right, it modifies the process instance. I was thinking you were still referring to "in-flight process modification". > That's what I am trying to assess. And though the complexity seems to > increase with the use of ruote, what I am doing seems to be modeled > corrected as a "process" or "business process". And going back and forth > between ruote and state_machine confuses me even further. A business process orchestrates business objects. When there is no orchestration (nothing wrong with that), the objects synchronizes their states with each other, hopefully letting a useful choreography emerge. > To make it somewhat more concrete, what I am trying to do is model a hiring > process. Every company seems to have a process for it (e.g. phone screen(s) > followed by technical interviews followed by HR interview, followed by > background check and a negotiation phase ... and some of these are > optional). Any applicant applying for a job at such a company would need to > pass through this process. The process creator needs to assign actual users > to certain roles (e.g. interviewer), schedule the interviews etc. And this > is a typical process or it may needs to be modified from company to company > (and that's why I need a proper user interface for the users who do that). > My gut tells me that using workflow to model such a situation is the right > way to go. Yes, it feels right to have a "pattern" to follow. > Would you disagree? Is a state_machine (or a few of them) in a better > position to capture the essence of this? Quick concept: ---8<--- define 'hiring process' do cursor do applicant :task => 'fill in initial details' hr_clerk :task => 'initial screening' stop :if => '${bad}' rewind :if => '${not_enough_info}' cursor do concurrence do hr_manager :task => 'interview' tech_lead :task => 'interview' end rewind :if => '${not_enough_info}' end applicant :task => 'decision notification' end end --->8--- With a state machine, you'd flag the "application" business object with "in progress", "doing this", "doing that", and ... Well you know. Best regards, -- John Mettraux - http://lambda.io/processi -- 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
