about processes and engines

new ruote quickstart

picture-11Ruote has a new website, like the one for Rufus, it’s based on the excellent Webby.

I wrote yesterday about renovating the quickstart, I had initially written an example showing a mini todo tool, but this time I switched to a “mechanical turk” like example where a process instance fetches flickr pictures and presents them to human participants for evaluation and choice.

The process definition boils down to :

class PicSelectionProcess < OpenWFE::ProcessDefinition

  sequence do


    concurrence :merge_type => 'mix' do

      # display the pictures chosen by the users

the participant for fetching the pictures is called ‘get_pictures’ :

engine.register_participant :get_pictures do |workitem|

feed =”+
feed.update! = feed.entries.inject([]) do |a, entry|
a << [ entry.title,, entry.links.first.href ] end end [/sourcecode] That's it for the quickstart. Now I have to update the tea tasting team example and the japanese website.

Written by John Mettraux

December 16, 2008 at 6:57 am

Posted in atom, bpm, openwferu, ruby, ruote, workflow

6 Responses

Subscribe to comments with RSS.

  1. Hello

    I’d like to make a remark: I know that this is a quickstart meant to remain simple, but is it possible to enhance your script so that it would still work when you connect to the internet through a proxy ?

    Ruote aside, I’ve quickly found the appropriate info in the rdoc about proxies in the Net::HTTP stuff, but is there a nice workaround for this peculiar example with Atom::Feed ?

    Sorry if my question seems dumb or if the answer is obvious, but I’m fresh to both ruby and ruote and as I am facing the “problem”, it occured to me that it could help newbies like me to get a quicker start, although it forced me to start using the rdoc, which is obviously something I could thank you for ;)


    March 25, 2009 at 2:38 pm

  2. Hi Marc,

    this should do the trick :

    I’m sorry, I couldn’t test though (and it’s midnight)

    Best regards,

    John Mettraux

    March 25, 2009 at 2:58 pm

  3. Hi John,

    and thank you for your quick answer.

    Unfortunately, it didn’t work out. After looking at the doc in the source of atom-tools, it appears that the Atom::Feed initializer uses an Atom::HTTP object as second argument, which apparently doesn’t have a proxy feature (contrarily to Net::HTTP).

    If anyone can prove me wrong, I’ll be glad to read from him.

    Thanks again.


    March 26, 2009 at 2:43 pm

  4. Hi again (or maybe should I say Good morning, by the time you read this).

    I eventually found a workaround to my proxy issue, by using the atom module rather than atom-tools.
    The initializer of Atom::Feed (from atom) takes the answer to an http request as argument (rather than an url), which is easy to get even through a proxy thanks to Net::HTTP.

    Let me know if you’re interested (it just adds a few lines of code).

    Again, thank you for your time, and keep on the good work ;)


    March 26, 2009 at 4:23 pm

  5. Hi,

    yes, a link to your solution would be appreciated.

    Thanks in advance,

    John Mettraux

    March 26, 2009 at 11:00 pm

  6. Hi,

    here’s a link to my solution:


    March 27, 2009 at 10:20 am

Comments are closed.

%d bloggers like this: