On Fri, Feb 11, 2011 at 02:07:56AM -0800, rebo wrote:
>
> And no matter how many times you put up a dialog saying "Are you sure
> you want to do X" they will hit yes and then immediately realise they
> chose the wrong option.
>
> This is especially annoying when they are replying to a long running
> process. How best to deal with this?
>
> One way is to litter process definitions with rewinds after each
> participant expression that will rewind if the subsequent participant
> thinks a previous participant has made a mistake.
>
> i.e.
>
> alice :task => "Did John Doe pass his interview?" , :response =>
> "yes_or_no"
> _if :t => "${response} == 'true'" do
> bob :task => "Draft contract for John Doe"
> back 2 :if => "${alice_made_a_mistake}"
> end
Hello Rebo,
maybe it's better to rewrite this as
---8<---
cursor do
alice :task => "Did John Doe pass his interview?" , :response => "yes_or_no"
over :if => '${done}'
bob :task => "Draft contract for John Doe"
jump :to => 'alice', :if => '${alice_made_a_mistake}'
end
--->8---
it keeps it lean.
> but as you can see this quickly becomes incredibly complex and
> unmanageable.
If you read the documentation for the cursor expression
http://ruote.rubyforge.org/exp/cursor.html
(scroll to "cursor command in the workitem")
you'll notice that you can place cursor commands in the workitem directly, and
leave the over/jump/... out of the cursor :
---8<---
cursor do
alice :task => "Did John Doe pass his interview?" , :response => "yes_or_no"
bob :task => "Draft contract for John Doe"
end
--->8---
Alice can do something like
workitem.command == 'over' # break the current cursor
or Bob can do
workitem.command == 'rewind' # rewind the whole cursor
or
workitem.command == 'jump alice' # get back to alice
or
workitem.command == 'back 2' # get back to alice
> This suggests that a global process undo would be more
> useful which can reset the state of a process including all workitems
> to a previous saved state.
This is possible programmaticaly thanks to re_apply
https://github.com/jmettraux/ruote/blob/2545415dec1acc23eec44e83240457fe2807e9d7/lib/ruote/engine.rb#L219-239
or from the process definition via a redo
https://github.com/jmettraux/ruote/blob/e5952b53957642b443327761203f949015710398/test/functional/eft_9_redo.rb#L15-43
> Maybe it is possible with persisted storage somehow, creating a
> "backup" of the process.
That's what re_apply and redo do, they cancel a branch and re-apply.
> Now I know that the whole point of ruote and these kinds of workflows
> is that once a work item has been replied to that is it. That is the
> reality of the business decision and users should not be making these
> mistakes. However the practical reality is that mistakes do happen,
> and I dont want an entire process to be cancelled and restarted
> because an inattentive user presses the wrong button
You have to strike the balance between a big huge process and a set of smaller
processes that somehow communicate with one another and can be easily restarted.
If you look at this blog post, second diagram
http://mainthing.ru/item/403/
you'll notice two processes that communicate via a "DueInvoicesDB", not the
single process described in the first diagram.
I know it's easier to write than to do. It requires to step back a bit, it
requires a bit of experience...
Now from your issue description a bit of leaning up of the cursor section in
your business processes should do.
And don't forget to test your process definitions (I know, doc is lacking about
that).
We try hard to make the process definition language concise, if you spot
improvements, suggestions are welcome.
I hope this helps, 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
