On Fri, Apr 9, 2010 at 11:48 AM, Kandada Boggu <[email protected]> wrote: > > Let me try to pose the question with a real life example of insurance > claims processing. > System starts a job upon receiving a claims request. The job has a > human task that is assigned > to ClaimsAgent role. When a claims agent checks his work queue he will > see the new claims request. > If he chooses to acquire the claim, then that task is taken off the > queue. Actual processing time > for the claim runs in to several days. Once the agent completes the > task the job moves to the next step. > > In this scenario: > 1) Does the system support asynchronous completion of tasks? Or Does > it simply perform a synchronous wait for completion?
Everything is asynchronous. The system waits indefinitely unless a timeout [4] is set for the participant or the segment of process. In case of timeout, the engine engines cancles the segment of progress and trigger :on_cancel if present [1] . When the cancelled segment of process contains an applied participant, a cancel notification is sent to the participant implementation. In the case of a storage participant the workitem is removed. By default the flow resumes after the timedout segment. > 2) What happens in the above scenario if the worker goes down before > the task is completed? ( this was answered partly in your > previous reply, but I am hoping that additional information might > help) The operation will be placed in the execution queue, waiting to be fetched and processed by a worker. If there is no worker it will just stay there. Outdated timeouts are triggered when a worker is available. >> From the point of view of the human, reverting/completing a task is >> the same thing : returning the workitem. When reverting, you'd flag a >> workitem field like 'reverted' => true. > > Who is supposed to put the task back to the queue? In my example, > claims agent(or an admin) can > put the claim back to the claims processing queue. Exactly. >> > Is it possible to add participants to the process definition of the >> > current job within a participant. >> >> I don't understand the question. > > This is case where you are adding new tasks to a running job. > Example: HR department has a workflow to handle employee complaints. > Depending upon the nature of the complaint a sub work flow is > executed. > The sub workflows are defined in a library. Every season new sub > workflows are added to the library based on the new corporate > directive. > Actual sub workflow to be executed for a complaint is determined by a > human operative. The human might make different decisions for the same > scenario > based on the context. Is it possible to insert a new task based to a > running job? > In other workflow systems I have used before, I could modify the > current job by inserting new tasks to the job. Other interesting > aspect this requirement > is a concept called design by discovery. Organizations used to run the > workflow in the dynamic mode and after several months formalize the > most optimal path as the official process. Yes, you can. I've seen people using loop and cursor [2] or concurrent-iterator [3] to add new branches. Please read the documentation. Ruote is very dynamic and since it's based on Ruby, it's even more dynamic. You'll find help for modeling and running processes here. We're open to suggestions, critiques, etc, but please read the documentation first. [1] http://ruote.rubyforge.org/common_attributes.html#on_cancel [2] http://ruote.rubyforge.org/exp/cursor.html [3] http://ruote.rubyforge.org/exp/concurrent_iterator.html [4] http://ruote.rubyforge.org/common_attributes.html#timeout Best regards, -- John Mettraux - http://jmettraux.wordpress.com -- 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 To unsubscribe, reply using "remove me" as the subject.
