Re: [ruote:4099] Implementing a "finally" behavior in a workflow

[John Mettraux]

On Thu, Jun 06, 2013 at 09:33:02AM -0700, Or Cohen wrote:
>
> I'm trying to implement some kind of "finally" behavior in a process
> definition.

Hello Or,

welcome to the ruote mailing list.

> My workflow needs to prepare an environment by suspending various resources
> and eventually resuming them.
> I've written the actual code (participants) that suspend and resume the
> resources, and a small working workflow but I felt it's a bit loosely
> described.
>
> The workflow is roughly described like this:
>
> define do
> resource1 :action => 'suspend'
> resource2 :action => 'suspend'
>
> do_some_stuff
>
> resource2 :action => 'resume'
> resource1 :action => 'resume'
> end
>
> (...)
>
> define do
> define 'prepare_resource1' do
> resource1 :action => 'suspend'
> apply
> resource1 :action => 'resume'
> end
> define 'prepare_resource2' do
> resource2 :action => 'suspend'
> apply
> resource2 :action => 'resume'
> end
>
> prepare_resource1 do
> prepare_resource2 do
> do_some_stuff
> end
> end
> end
>
> I like it better, but it still feels a bit off to me, not sure why. Maybe
> too much nesting or something.
> I might be way off, and the first workflow is the way to go. :)

I'd go for something like:

```ruby
Ruote.define do
sequence do
resource1 :action => 'suspend'
resource2 :action => 'suspend'
sequence :on_error => 'x' do
do_some_stuff
end
resource1 :action => 'resume'
resource2 :action => 'resume'
end
end
```

where 'x' is the name of a participant or subprocess that handles the error.
But that swallows the error.

I like your nested prepare, it feels like "using x; end using" in VB/C# or
like File.open with a block in Ruby. Granted, when there are ten resources
the nesting is awful, and it doesn't help when the resources change from one
instance of the flow to the other.

There is also no easy way to catch an error and re-raise it:

```ruby

# hypothetical process definition, doesn't work...

Ruote.define do
sequence do
resource1 :action => 'suspend'
resource2 :action => 'suspend'
sequence :on_error => 'intercept' do
do_some_stuff
end
resource1 :action => 'resume'
resource2 :action => 'resume'
reraise # if there is an intercepted error
end
end
```

For now, I can only suggest the on_error => 'x' above. If you really need the
error to be communicated outside of the sequence (after resource resumption),
please tell me.

I might need to add something (a "finally" or an easy way to store/reraise
errors).


Best regards,

--
John Mettraux - http://lambda.io/jmettraux

[Or Cohen]

On Friday, June 7, 2013 12:39:42 AM UTC+3, John Mettraux wrote:

On Thu, Jun 06, 2013 at 09:33:02AM -0700, Or Cohen wrote:

> I might be way off, and the first workflow is the way to go. :)

I'd go for something like:

```ruby
  Ruote.define do
    sequence do
      resource1 :action => 'suspend'
      resource2 :action => 'suspend'
      sequence :on_error => 'x' do
        do_some_stuff
      end
      resource1 :action => 'resume'
      resource2 :action => 'resume'
    end
  end
```

I agree, I'm starting to get the feel for it now. Still need to get used to describing flows like this.

Thank you very much, this has been very helpful.

[John Mettraux]

Hello,

just a quick note.

I've just added an on_error => store and and error :re feature to ruote on
master.

```ruby
Ruote.define do
sequence do
resource1 :action => 'suspend'
resource2 :action => 'suspend'

sequence :on_error => 'store:err' do

do_some_stuff
end
resource1 :action => 'resume'
resource2 :action => 'resume'

error :re => '$f:err'
end
end
```

The error gets placed in the "err" workitem field and raised later on.

Not sure it will help, but it might interest someone in the mailing list.