about processes and engines

Archive for the ‘rails’ Category

ruote on rails 2.0

update (2010/04/06) : this is an old post (2008), if you’re looking for ruote on rails, look at (rails3 branch is at


Two years ago I started writing Ruote, an open source workflow (incidentally BPM) engine written in Ruby. The immediate reaction was “how do I integrate that with Rails ? Please send me the code”. So I started writing an example Rails web application, it was initially nicknamed ‘densha’ and then renamed to ‘ruote-web’. There is a visible instance of this web application on a demo server.

But I’m not very good at web development and this was almost my first Ruby on Rails application. Time passed, I worked a lot on Ruote-Rest, a Ruby web application based on Rack (not Rails). Ruote-rest is meant to be consumed by HTTP clients that are not browsers, you could say it’s a RESTful webservice.

It is time for a second take at Ruote-Web. I started with a Rails plugin for easy integration of Ruote into a Rails application, it’s simply called ruote_plugin. It provides at first migration generation (workitem storage mainly, but also engine persistence via ActiveRecord instead of the filesystem if necessary) and then helper scripts for installing the engine and its dependencies under vendor/plugins/ or as gem.

The next step was building ruote-web2 on top of the ruote_plugin. Let’s note that the initial implementation of a “ruote plugin” was done by Tomaso Tosolini (who also wrote the rdbms based persistence for the process engine, Thanks a ton Tomaso !).

Ruote-web2 is way simpler than ruote-web, and it adheres to the resource structure laid by ruote-rest. It adds user and group resources though. For the user resource I didn’t look very far, I used the ultra-classic restful-authentication.

This will be an interesting packaging of Ruote for people of want to “just replace the Ruote logo and place theirs” to benefit immediately from a simple and robust open source workflow engine/suite (I’m quoting someone in the community for the “just replace the logo” thing).

Ruote process definitions can be expressed as XML, Ruby and now even JSON (or YAML if you push). I plan to integrate process definition tinkering into ruote-web2 (as I did in ruote-rest) and maybe more. That should mean edition of process definitions in the process portfolio and edition of definitions of processes in-flight (already implemented in ruote-rest).

The hardest part part of this implementation work is the QA, not only the classical QA but also the QA triggered by this goal : I’d like to have the same (RESTful) interface for ruote-rest and ruote-web2. The “connectedness” aspect deserves a big share of the design (and then QA) work.

Ruote-web2 is more perhaps “ruote-rest on Rails” than “ruote-web take 2”. There is a consequent amount of work left, but I’ll probably be done in three or four weeks.

It’s open source after all, so here are some links to the source of these tools :

And finally to the mailing list :

Written by John Mettraux

September 29, 2008 at 1:38 pm


Keith Swenson just wrote a great post entitled : “Human ‘Facilitator’ Processes”.

In one of his previous posts, Keith had introduced the concept of Automators and Facilitators.

we know that there are at least two distinct “camps” in the BPM field: those that want to support human work (”Facilitators”), and those that want to automate work that was previously done by humans (”Automators”).

The first comment to the “Human ‘Facilitator’ Processes” post goes :

the facilitator diagram represents the swan swimming gracefully on the lake, the automator diagram represent the swan’s not so graceful legs thrashing under water. You can’t have one without the other.

IMHO, you can get on without the automator diagram. Things like “convention over configuration” do help.

Being rather an “Abstractor” (more a Software Engineer than a Process Analyst), I tend towards the “Facilitator” view. Business processes should look concise.

The “Automator” diagrams feel like they contain the business process plus “Protocol” : ‘upon receiving an email, do that, check this, …’, does this belong to the business process ? Is it conventional ? Just plain Protocol that should not appear in the business process ? I think so and I will try hard to produce tools that fit this view.

Written by John Mettraux

September 29, 2007 at 4:04 am

Posted in bpm, bpmn, openwferu, rails, workflow

reply there

I had a long mail exchange with Pat on the OpenWFEru developer mailing list.

It all boils down to two pieces of code.

A participant which receives some work from the workflow engine via its consume() method. The participant task is simply to call a [web]service (SOAPey, RESTy, Messagesque, whatever), but the answer will come later… No direct reply.

This delayed reply will come back via an HTTP call (a Rails controller here). This controller will contact the participant and hand it back the request params. The participants will thus be able to answer to the engine.

The participant :

the participant

The controller :

the controller

This is the skeleton of a solution, I hope it captures the essence behind this whole asynchronicity…

Comments if any in the dev or the user mailing list please, not here.

Written by John Mettraux

September 24, 2007 at 1:59 am

Posted in openwferu, rails, ruby, workflow

OpenWFEru 0.9.14 released

flow.pngJust released OpenWFEru 0.9.14. The formal announce is visible here, in the users mailing list.

It’s also the first release of Densha, an Ruby on Rails web application that wraps an OpenWFEru workflow/bpm engine instance and extends it with a worklist system (users, groups, permissions, task lists). There is an online instance visible at

The demand for a Rails integration was immediate when the first releases of OpenWFEru came out. There have already been integrations of OpenWFEru within Ruby on Rails web applications, like for example GeoBPMS, but this one is a kind of showcase / example.

The nicest feature (imho) is the process definition rendering system, it draws process definitions, XML or Ruby, indifferently. It will get nicer in future releases, and you’re free to customize its CSS. I have also made sure it’s usable outside of Densha, for other web applications leveraging OpenWFEru.

There is a basic/generic form system for manipulating the workitem payload (task information) with hooks for plugging your own [rails] forms (on a task basis), but I shall blog about that later.

Many thanks to Juan Pedro Paredes who drove the implementation of the ‘engine administration’ screen, where you can pause, resume and cancel business process instances and also view process errors and restart after them if possible.

And of course, it’s far from perfect, the bug tracking system is ready as well as the users’ mailing list.

Written by John Mettraux

September 18, 2007 at 9:42 am

Posted in bpm, bpms, openwferu, rails, workflow

lost connection

screenshotI had put online a demo version of “densha”. It was quite shaky, very unstable. I had lots of “Mysql::Error: Lost connection to MySQL server during query: …”. I was thinking it was the machine, a rented virtual box.

Processes were breaking… Bad.

Solution :

sudo apt-get install libmysqlclient15-dev
sudo gem install mysql

Back to improving Densha and its documentation.

Thanks to Alain for his help.

Written by John Mettraux

September 6, 2007 at 11:45 am

Posted in openwferu, rails, ruby


It’s very young, needs lots of work, only works with Firefox, but is worth a look :

Densha (aka OpenWFEru on Rails).

Log in as “alice”, “bob”, or “admin”, the password is the username.

There is a quickstart for it, for local installs.

More later.

Feedback there.

Written by John Mettraux

September 4, 2007 at 9:22 am

Posted in bpm, bpms, openwferu, rails, ruby, workflow

web app building

ss2.pngSo “densha” is going along well, I even implemented process definition rendering (see the image).

Remember, “densha” is a Rails application wrapping an OpenWFEru workflow engine. It’s meant as a demo, an example, but with some work and customization it’s easy to turn it into a small BPM platform.

There are already people checking it out of the repository and having a try at it, even if there isn’t a single piece of documentation.

ss0.pngAlthough I hadn’t wanted that for this first iteration, I implemented a process definition rendering mechanism (like “droflo” in the old OpenWFE java). It’s quite ‘alpha’ for now, but it’s promising.

Unlike the old OpenWFE java webclient, you’ll be able to add workitem stores on the fly (yes, it’s not only the workflow engine that is wrapped, but also a worklist).

OK, back to work, I’d like to release it at the beginning of next week.

Written by John Mettraux

August 31, 2007 at 2:19 pm

Posted in bpm, openwferu, rails, ruby, workflow

riding the train

I was silently working on a web application based on OpenWFEru and Ruby on Rails, someone asked about this domain and I was glad I could reply straightway.

Densha is a Ruby on Rails web application that wraps OpenWFEru. It’s an OpenWFEru application example, a showcase, but I’m sure that lots of people will want to use it ‘out of the box’ (as happened with OpenWFE’s webclient). We’ll see, but at least it shows an integration of OpenWFEru within Rails.

Currently it’s only available via SVN :
svn checkout
(see also a fisheye view of it)

I will write specific documentation very soon and release OpenWFEru and Densha, together at 0.9.14, soon as well.

There are a certain number of people googling for “rails workflow engine” or “openwferu rails”, I hope this will satisfy them.

Written by John Mettraux

August 25, 2007 at 1:37 pm

Posted in bpms, openwferu, rails, ruby, workflow