Evaluating ruote against our requirements

[denis....@bluewaterbrand.com]

Hi,

We are currently evaluating ruote against a set of requirements we came up with that a prospective workflow engine solution must meet.  So far ruote is stacking up pretty well against our requirements, but we have a few requirements that I am trying to figure out how we would satisfy them either using ruote out-of-the-box, or via some code we write that sits on top/alongside of ruote.

Can ruote do the following things, and if so, how?

1. Ability for an admin to set the current step/expression of a process instance (and then resume).  Here's the use case: something is broken in production that needs to be fixed, so pause the process instance, deploy a fix, and then resume the process at a specific step/expression.

2. Ability to assign a step in a process to a user, and to be able to show the user the steps assigned to him that currently require action on his part (i.e. steps in running processes that are waiting for a reply to continue).

3. Ability to query for completed process instances (e.g. get a list of all the processes that ran between 6/1/2013 and 6/15/2013).

4. Ability to query for the execution history of a process instance (i.e. be able to see what part of a process has been executed and where the process is currently at).

5. Ability to tag process instances and search/query based on those tags.

I realize that I may not be providing enough context to make those requirements clear, so please let me know if something is unclear and I will try to explain our needs better.

Thanks,
Denis

[Danny Fullerton]

Hello Denis,

Welcome to Ruote's mailing list.

I'll try to answer to the best of my knowledge but John will be able to complete if necessary.

1. Yes, I seen some discussion on the mailing list about this. You should take a look at re_apply and the test cases ( http://ruote.rubyforge.org/process_administration.html#re_applying).

2. Yes but I'll leave this to John.

3. The moment a process is completed it gets erased. I believe the Audit Trail observer I'm working on (or your own implementation) should be able to answer this. Basically, once completed, the entire process tree and applied workitems gets saved iin an archive.

4. Yes, you should take a look at Ruote-kit which shows the current position of a process.

5. I'll leave this to John.

regards,

-- 
Danny Fullerton
Founder
Mantor Organization

--
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en
---
You received this message because you are subscribed to the Google Groups "ruote" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwferu-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[denis....@bluewaterbrand.com]

Hi Danny,

Thanks for the quick reply.  The support on this mailing list has been fantastic so far.

Regarding your Audit Trail observer, is this something you are developing with plans to release to the community?  If we decide to go with ruote (and that is looking likely), I would be willing to help you with this, since this is something we'll need as well (assuming your vision of Audit Trail observer line up with our needs).

Best Regards,
Denis

[Danny Fullerton]

Hello Denis,

Yes, this is the intent.

This Audit Trail is an essential part of a software (open-source) we intend to release in November.

Briefly, we need to be able to display an entire process while it's active and when it's completed. We can presently visualize the entire processes with workitem(s) filled in the past, current active workitem and future workitem(s) by using this Audit Trail and mixing in the active workitem.

If feasible, I would prefer if it could be an external gem others could uses.

If this sounds interesting, you can contact me personally and we could setup something to share this code and work together.

regards,

-- 
Danny Fullerton
Founder
Mantor Organization

[denis....@bluewaterbrand.com]

Thanks Danny.  If we decide to go with ruote, I will definitely be contacting you to see if we can work together on this.  I should know soon.

Best Regards,
Denis

[John Mettraux]

> On 13-06-19 04:56 PM, denis....@bluewaterbrand.com wrote:
> > Hi,
> >
> > We are currently evaluating ruote against a set of requirements we
> > came up with that a prospective workflow engine solution must meet.
> > So far ruote is stacking up pretty well against our requirements, but
> > we have a few requirements that I am trying to figure out how we would
> > satisfy them either using ruote out-of-the-box, or via some code we
> > write that sits on top/alongside of ruote.
> >
> > Can ruote do the following things, and if so, how?
> >

> > (...)

> >
> > 2. Ability to assign a step in a process to a user, and to be able to
> > show the user the steps assigned to him that currently require action
> > on his part (i.e. steps in running processes that are waiting for a
> > reply to continue).
>

On Wed, Jun 19, 2013 at 05:11:51PM -0400, Danny Fullerton wrote:
>
> 2. Yes but I'll leave this to John.

Look at the StoreParticipant. The simplest way to do it is to decide that
participant_name == user_name and do things like:

```ruby
Ruote.define do
alice :task => 'prepare doc'
bob :task => 'advise on doc'
charly :task => 'approve / reject'
end
```

Another technique is to use role names as participant names:

```ruby
Ruote.define do
writer
adviser
supervisor
end
```

Yet another technique is to use department names ...

I hope you get the trick.

> > 3. Ability to query for completed process instances (e.g. get a list
> > of all the processes that ran between 6/1/2013 and 6/15/2013).
>

> 3. The moment a process is completed it gets erased. I believe the Audit
> Trail observer I'm working on (or your own implementation) should be
> able to answer this. Basically, once completed, the entire process tree
> and applied workitems gets saved iin an archive.

Archival / history is left to you. Out of the box, ruote has a some kind of
history component:

https://github.com/jmettraux/ruote/blob/2048bc6ad7/test/functional/ft_36_storage_history.rb
https://github.com/jmettraux/ruote/blob/2048bc6ad7/test/functional/ft_37_default_history.rb

> > 4. Ability to query for the execution history of a process instance
> > (i.e. be able to see what part of a process has been executed and
> > where the process is currently at).
>

> 4. Yes, you should take a look at Ruote-kit which shows the current
> position of a process.

Combining the history above or Danny's AuditTrail plus the Ruote::Dashboard
ProcessStatus (used by ruote-kit) will give you that.

> > 5. Ability to tag process instances and search/query based on those tags.
>

> 5. I'll leave this to John.

It's possible, but not out of the box. It might be not very efficient.


Best regards,

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

[denis....@bluewaterbrand.com]

John,

Regarding my question about assigning a user to a step, is something like this possible today?

```ruby
  Ruote.define do
    prepare_doc :assigned_to => 'mary'
    advise_on_doc :assigned_to => 'joe'
    approve_reject :assigned_to => 'lauren'
  end
```

We'd like to be able to define arbitrary key/value pairs on a participant within a process definition, and then be able to access this meta data when a process instance is launched (both from within the participant implementation, as well as from the outside by querying the process instance).

We can think of some other uses for defining meta-data/configuration on participants as part of the process definition, so hopefully this is supported or wouldn't be difficult to add.

Thanks,
Denis

[John Mettraux]

On Thu, Jun 20, 2013 at 05:22:49AM -0700, denis....@bluewaterbrand.com wrote:
>
> Regarding my question about assigning a user to a step, is something like
> this possible today?
>
> ```ruby
> Ruote.define do
> prepare_doc :assigned_to => 'mary'
> advise_on_doc :assigned_to => 'joe'
> approve_reject :assigned_to => 'lauren'
> end
> ```

Yes, it's possible.

> We'd like to be able to define arbitrary key/value pairs on a participant
> within a process definition, and then be able to access this meta data when
> a process instance is launched (both from within the participant
> implementation, as well as from the outside by querying the process
> instance).

```ruby
class PrepareDoc < Ruote::Participant
def on_workitem
p workitem.params
reply
end
end

ruote.register do
prepare_doc PrepareDoc
end
```

When running the flow you wrote above, that participant implementations would
print something like:

```
{'assigned_to' => 'mary'}
```

For the "querying the process instance" part:

Process definition are turned into syntax trees by ruote.

```
[ 'define', {}, [
[ 'prepare_doc', { 'assigned_to' => 'mary' }, [] ],
[ 'advise_on_doc', { 'assigned_to' => 'joe' }, [] ],
[ 'approve_reject', { 'assigned_to' => 'lauren' }, [] ]
] ]
```

The root expression of a workflow instance contains a copy of that tree, so
it's accessible somehow.

Note that if you do something like

```ruby
Ruote.define do
set 'this_user' => 'mary'
prepare_doc :assigned_to => '${f:this_user}'
advise_on_doc :assigned_to => '${f:that_user}'
approve_reject :assigned_to => '${f:that_other_user}'
end
```

the tree will look like

```
[ 'define', {}, [
[ 'set', { 'this_user' => 'mary' }, [] ],
[ 'prepare_doc', { 'assigned_to' => '${f:this_user}' }, [] ],
[ 'advise_on_doc', { 'assigned_to' => '${f:that_user}' }, [] ],
[ 'approve_reject', { 'assigned_to' => '${f:that_other_user}' }, [] ]
] ]
```

The attribute substitution (dollar notation) happens when necessary and at
the local node level (not in the copy of the tree kept at the root
node/expression level).

> We can think of some other uses for defining meta-data/configuration on
> participants as part of the process definition, so hopefully this is
> supported or wouldn't be difficult to add.

Ruote will not prevent you from adding attributes to the process definition.
It will simply ignore attributes it doesn't use.

[denis....@bluewaterbrand.com]

Thanks John.  I discovered workitem.params on my own and have been playing with some sample code to prove out what we need.  The information you supplied definitely helps fill in the gaps though.

Best Regards,
Denis