On Wed, Oct 14, 2009 at 7:54 PM, Gonzalo <[email protected]> wrote:
>
> I'm working on a workflow that has to be aware of its 'own' cancel
> event. This process could be canceled at any time and if so happens, a
> new process should be started in order to tidy up some stuff like
> updating a database.
>
> I have something like this:
>
> class MyDef < OpenWFE::ProcessDefinition
>
> process_definition :name => "do_something" do
> sequence :on_cancel => 'update_database' do
> [...]
> end
> end
>
> process_definition :name => "update_database" do
> [...]
> end
>
> end
>
> 1. Is it possible to define the process that takes care of
> the :on_cancel expression ('update_database') within the same
> OpenWFE::ProcessDefinition class? I gave a look at some ruote
> functional test and seems that it is possible but it isn't working for
> me.
Hello Gonzalo,
What does "it isn't working for me" means ?
Your process definition holds two sub-process definitions but has no
body, could it be that ? Running that process would do nothing.
> 2. When the ':on_cancel' process is fired up ('update_database'),
> first dispatch to a participant delivers an empty payload. I would
> like the new process (called by :on_cancel) to be able to check if the
> latest payload held a special variable and if so do some jobs with it.
OK, so it seems that it works somehow :-)
Yes, the philosophy is currently (in ruote 0.9 and 2.0) that on_cancel
and on_error use the workitem as found at apply_time (not a reply
time). In ruote 2.0, the cancel mechanism would imply that in case of
a concurrence the last child to reply would have its workitem win the
"cancelling merge", to avoid that indetermination, the workitem at
apply time (root towards leaf) is used. Of course this is debatable,
I'm open to suggestions.
When the on_cancel covered zone (process segment / branch), there
should be enough information to cancel / roll back further changes.
Ideally...
You could eventually go via process variables instead of workitem
fields, or put the on_cancel much closer to the participant which sets
your fields (eventually splitting the on_cancel work).
> It would be something like if :on_cancel could select a participant
> expression a get its current payload:
>
> sequence :on_cancel => "call_subprocess", :local =>
> "<participant_expression>"
> [...]
> end
>
> I know this can't be exactly this way because :on_cancel event may
> happen anytime and <participant_expression> may or may not exist at
> that moment...
Indeed, that's a problem.
Maybe you could explain the whole use case, there is maybe another
solution, something other than on_cancel.
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
-~----------~----~----~----~------~----~------~--~---
