about processes and engines

ruote 2.1.10 released

ruote is an open source workflow engine implemented in Ruby.

It takes as input process definitions and interprets them. It routes work among participants according to the flow described in those process definitions.

Version 2.1.10 is out and contains lots of small improvements and features requested and developed with the help of various people.

I have also updated/upgraded the various storage libraries around ruote and added to their ranks two new gems.


in ruote

The changelog has all the details, but let’s look at the LocalParticipant module which saw the most improvements. Following suggestions by Oleg and Avishai, I added the on_reply, re_dispatch, reject and put/get methods
to it.

A participant has a consume(workitem) which is called as the participant gets handed a workitem. When dealing with a remote participant, it’s sometimes necessary to have logic alongside the consume method to deal with the workitem when it comes back. That’s the role of the on_reply(workitem) method.

re_dispatch(workitem) forces a re-delivery from the participant expression to the ‘real’ participant.

The reject(workitem) method is about participants that reject a workitem, forcing the worker to let another worker deal with the dispatching to the participant.

LocalParticipant now has a pair put(k, v) / get(k) for stashing data between consume / on_reply. The data is stashed directly in the ParticipantExpression.

around ruote

Since CouchDB 0.11 is out and it allows ?feed=continuous&include_doc=true, I could drop the polling work from ruote-couch and simply keep connected and “react” on incoming changes in messages and schedules. It makes for a robust ruote-couch. I also made sure ruote-couch 2.1.10 can be shared by multiple workers.

This ruote-couch isn’t very fast, but I’ve come to appreciate CouchDB and use it in 2 or 3 projects. I like the comfort of having Couch as a storage for ruote.

I have upgraded ruote-dm as well. It’s a DataMapper backed ruote storage gem. I made sure ruote-dm could be shared by multiple workers (though I still have an issue with one of those special tests, I hope to fix that in the coming weeks).
It seems to work well with the latest DataMapper (1.0).

For the fun, I wrote a ruote-redis gem. As the name implies, it uses Redis as a persistence mechanism for ruote. It’s fast, multi-worker ready and was fun to develop. Not sure if I will use in production, but it can sit as an example at least.
There have been very interesting developments in Redis, this ruote-redis only uses a very limited set of those features. There is probably a better way.

I got interested in Beanstalk, its simplicity and minimal size are seducing. I started working with it as a kind of transient storage, but ended up writing a server/client thing. You can start a ruote-beanstalk storage linked to a beanstalk queue, a server and then start an engine and some workers that will communicate with the real storage via the beanstalk queue. Queue in the middle.

My initial purpose when investigating Beanstalk was to use it to pass workitems between the engine and the ‘real’ participants. I didn’t forget this and ruote-beanstalk comes with participant and receiver implementations.
It could become an alternative to ruote-amqp, it is at least a good example of a participant / queue / receiver set.

Finally, there’s ruote-cukes, a gem that adds extensions/examples for testing ruote process definitions with Cucumber.

next steps

I still have to improve the documentation, there are lots of weak / missing points in it.

The listen expression will be enhanced, I want it to listen (react) to process errors and to flows entering or leaving a given tag (told you).

Lots more things.


Many thanks to Torsten, Ian, Oleg, Avishai, Patrice and Matt. And also many thanks to Wes Gamble (and Sergio) for organizing a ruote BOF at the latest Railsconf.

BTW, David Greaves is writing an overview in the ruote wiki as he’s assembling his build system. Feel free to chime in.

This release is dedicated to my friend Sawada Tomoaki, who left us last friday.


Written by John Mettraux

June 15, 2010 at 6:57 am

Posted in ruby, ruote, workflow

%d bloggers like this: