ruote-rest and :on_cancel expression

[Gonzalo]

Hi all,

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

I have two questions:

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.

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.

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...


Well, many thanks for your help and tips.
Best regards to all,

Gonzalo.

[John Mettraux]

On Wed, Oct 14, 2009 at 7:54 PM, Gonzalo <gonzalo....@gmail.com> 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

[Gonzalo]

Hi John,

Somehow I didn't test my process definition thoroughly ... I've just
defined a simple workflow with two sub-process and :on_cancel
expression
and everything worked pretty fine. Sorry about this :(

Thank you for your comments and tips on :on_cancel expression
behaviour
for ruote 0.9 and 2.0. I'll probably try to use process variables to
communicate
the main process with the canceling (sub-process).

Best regards,

Gonzalo.

[Gonzalo]

Hi John,

I launched this workflow definition within a clean install of ruote-
rest:

class Test0 < OpenWFE::ProcessDefinition
sequence :on_cancel => "exit" do
participant :ref => "alpha"
participant :ref => "bravo"
end
process_definition :name => "exit" do
participant :ref => "charly"
participant :ref => "zulu"
end
end

At alpha or bravo stage I just cancel the workflow. Then, a new
subprocess called 'exit' is started
and workitem is delivered to participant charly. As far as I see, the
new subprocess is given a new
id which is the old one (main process) plus ".0" so it looks similar
to: 20091019-godepoyoyu.0

Then I GET /processes and see that there is still a process with id
'20091019-godepoyoyu', but the name
has changed to 'exit'. I expected to see the new id '20091019-
godepoyoyu.0'. Then I do a GET on that
process (GET processes/20091019-godepoyoyu) and shows up the following
error:

undefined method `each' for nil:NilClass
(erb):27:in `get_binding'
/home/gonzalo/ruote-rest/vendor/rufus-sixjo/lib/rufus/sixjo.rb:212:in
`get_binding'
/home/gonzalo/ruote-rest/vendor/rufus-sixjo/lib/rufus/sixjo.rb:225:in
`erb'
/home/gonzalo/ruote-rest/lib/helpers/application.rb:42:in `_erb'
/home/gonzalo/ruote-rest/lib/rep/processes.rb:61:in
`render_process_html'
/home/gonzalo/ruote-rest/lib/inout.rb:75:in `send'
/home/gonzalo/ruote-rest/lib/inout.rb:75:in `rrender'
/home/gonzalo/ruote-rest/lib/res/processes.rb:108:in `call'
/home/gonzalo/ruote-rest/vendor/rufus-sixjo/lib/rufus/sixjo.rb:267:in
`service'
/home/gonzalo/ruote-rest/vendor/rufus-sixjo/lib/rufus/sixjo.rb:265:in
`catch'
/home/gonzalo/ruote-rest/vendor/rufus-sixjo/lib/rufus/sixjo.rb:265:in
`service'
/home/gonzalo/ruote-rest/vendor/rufus-sixjo/lib/rufus/sixjo.rb:125:in
`call'
/home/gonzalo/ruote-rest/lib/auth.rb:48:in `call'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/showexceptions.rb:24:in
`call'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/commonlogger.rb:20:in
`_call'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/commonlogger.rb:13:in
`call'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/builder.rb:60:in `call'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/content_length.rb:13:in
`call'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/chunked.rb:15:in `call'
[...]

It seems that the workflow representation hasn't been created
correctly or the reference to it is wrong.
It's something a bit weird because workitem 'charly' is correctly
created, and I'm able to
do GET /expressions/20091019-godepoyoyu and see that there are
environment (context for 'exit',
process definition (definition for 'exit') and participant ('charly')
expressions.

Thanks for your help and tips.
Best regards.

Gonzalo.

[John Mettraux]

Hello Gonzalo,

my mistake : ruote-rest has some weak points when it gets to
subprocesses. I have to fix that.

IIRC, you already pointed to some of those issues 2 months ago.

Thanks a lot,

[Gonzalo]

Hi John,

Nando or me probably reported to you this issue in the past... I just
didn't remember :(
Thank you very much for the early answer.

Best regards,
Gonzalo.

[John Mettraux]

On Mon, Oct 19, 2009 at 10:29 PM, Gonzalo <gonzalo....@gmail.com> wrote:
>
> Hi John,
>
> Nando or me probably reported to you this issue in the past... I just
> didn't remember :(
> Thank you very much for the early answer.

Still have to fix that new "version" of the issue though :(

[John Mettraux]

On Mon, Oct 19, 2009 at 6:16 PM, Gonzalo <gonzalo....@gmail.com> wrote:
>

> I launched this workflow definition within a clean install of ruote-
> rest:
>
> class Test0 < OpenWFE::ProcessDefinition
>  sequence :on_cancel => "exit" do
>    participant :ref => "alpha"
>    participant :ref => "bravo"
>  end
>  process_definition :name => "exit" do
>    participant :ref => "charly"
>    participant :ref => "zulu"
>  end
> end
>
> At alpha or bravo stage I just cancel the workflow. Then, a new
> subprocess called 'exit' is started
> and workitem is delivered to participant charly. As far as I see, the
> new subprocess is given a new
> id which is the old one (main process) plus ".0" so it looks similar
> to: 20091019-godepoyoyu.0
>
> Then I GET /processes and see that there is still a process with id
> '20091019-godepoyoyu', but the name
> has changed to 'exit'. I expected to see the new id '20091019-
> godepoyoyu.0'.

Hello Gonzalo,

this is right : the process is still the main "...poyoyu".

> Then I do a GET on that
> process (GET processes/20091019-godepoyoyu) and shows up the following
> error:
>
> undefined method `each' for nil:NilClass
> (erb):27:in `get_binding'

I have added a small test [1] for that case. But it doesn't fail. Am I
not doing it right ? Should I really try with an on_cancel subprocess
? Or maybe are we not using the same version of ruote / ruote-rest ?

[1] http://github.com/jmettraux/ruote-rest/blob/master/test/ft_subprocesses.rb#L42-45

Cheers,

[Gonzalo]

I John,

I've just tried test [1] above and it works fine. The HTML view
renders perfectly and XML output has the correct links to /expression
resources.

Then I tested this simple workflow:

class Test0 < OpenWFE::ProcessDefinition

sequence :on_cancel => "foxtrot" do
alpha
bravo
end

process_definition :name => "foxtrot" do
delta
end
end

Once created, I can GET /processes/{wfid} and its expressions with no
problems. After that, I DELETE /processes/{wfid} and that makes ruote
call the "foxtrot" process definition. As expected, doing GET /
workitems shows that there is a workitem asigned to "delta"
participant which url points to a resource like this: workitems/{wfid}
_0/0_0
Requesting /expressions/{wfid} works fine too. In this particular
workflow there should be 3 expressions. Here is a short output:

GET /expressions/20091020-goguputzuri_0/0_0
class : OpenWFE::ParticipantExpression
name : delta

GET /expressions/20091020-goguputzuri_0/0e
class : OpenWFE::Environment
name : environment

GET /expressions/20091020-goguputzuri_0/0
class : OpenWFE::DefineExpression
name : process-definition

But now, whenever I try to do a GET /processes/{wfid}, the error
reported above shows up:

> Then I do a GET on that
> process (GET processes/20091019-godepoyoyu) and shows up the following
> error:

> undefined method `each' for nil:NilClass
> (erb):27:in `get_binding'

I hope this can help you recreate this issue.
Thanks a lot for your help.

Best regards,
Gonzalo.

[John Mettraux]

On Tue, Oct 20, 2009 at 6:14 PM, Gonzalo <gonzalo....@gmail.com> wrote:
>
> I hope this can help you recreate this issue.
> Thanks a lot for your help.

Hello Gonzalo,

I'm quite busy for now, I wil try to build a test case with all the
information you gave me and try to fix that next week.

Sorry for the delay, many thanks,

[Gonzalo Suarez]

Hi John,

No problem.
Thanks for your help.

Gonzalo.

[John Mettraux]

Hello Gonzalo,

sorry for the 12 days delay. I came up with a solution (in ruote itself) :

http://github.com/jmettraux/ruote/commit/bbb90e68d5399a2a62c020b83ecf65403ac0f75d

with the assorted test :

http://github.com/jmettraux/ruote-rest/commit/1a56bd3fb72150f14e2f3fef6c90a306217bca0b

Not 100% happy with the solution : if the process instance splits in
two independent subprocesses only one of them will get shown in
/processes/wfid. It's OK for your use case now. I'm working on a 100%
solution starting with ruote 2.0

Sorry again,

[Gonzalo Suarez]

Hi John,
No problem. Thanks a lot for the fix.

Best regards,
Gonzalo.