processi

about processes and engines

Search Results

restful bpm

Until now I mainly wrote about exposing a workflow/BPM engine as a set of resources. I’ll write a few line about the other side. I could have named this post “RESTful orchestration”, but BPM is shorter and is music related as well.

For orchestration vs choreography, the best quote, via Stefan Tilkov, might be :

In orchestration, there’s someone — the conductor — who tells everybody in the orchestra what to do and makes sure they all play in sync.

One might argue that the conductor is merely a metronome that cares about BPM and that every participant knows where he fits in the ensemble. Would ‘orchestration’ rather refer to the preparation work of the execution ? Arrangements ?

Let’s forget about big words and acronyms, there’s work to do and no time for taking part in an already old argument. Let’s get started with the resources and where they live. I’ll go with a content management example, it’s a just a few steps away (not hardcore ROA).

There is one staging server, one preview server and two production servers. Content is developed on the staging server, pushed on the preview server for approval and then passed to the production servers.

Read the rest of this entry »

Written by John Mettraux

May 27, 2008 at 9:07 am

Posted in bpm, openwferu, rest, ruby, workflow

restful workflow engine (on Sinatra)

 

2010 update : this is an old post, the latest incarnation of this rest[ful] workflow thing is ruote-kit, and yes, OpenWFEru got renamed into ruote a while ago.

 

It may seem as an exercise, writing something restful. In the first take, I used Ruby on Rails to wrap OpenWFEru with a RESTful interface.

In this second take, I considered the alternatives among the Ruby web frameworks and went for Sinatra by Blake Mizerany.

Ruote-rest is mainly the result of a collaboration with a company which is integrating OpenWFEru (ruote) among its .NET applications. Its software artifacts speak XML over HTTP with ruote.

Ruote-rest, as a “take two”, is also the refinement of the concepts explored in the take one.

So what’s this RESTful workflow/BPM engine ?

It’s named “ruote-rest” and it’s available from GitHub at http://github.com/jmettraux/ruote-rest.

It provides for now 3 resources, /processes, /participants and /workitems (and the special /expressions resource).

  • /processes – running [business] process instances
  • /participants – participants in the processes (out of the box there are two ‘worklist’ participants provided ‘alpha’ and ‘bravo’, but you can POST others and DELETE those)
  • /workitems – the workitems held by ‘worklist’ participants (for human consumption generally)

These resources are sufficient for

  • launching processes
  • fetching workitems, update their payload and let them resume in their business process
  • canceling part or all of a process
  • modifying a process on the fly
  • adding or removing participants to business processes

Ruote-rest currently provides two representations of its resources, an XML one and an HTML one. The XML representation is meant for automated consumption, the main case, while the HTML one is meant for learning / debugging.

The installation instructions are in the README.txt, and there is also a packaged release available.

— warning : boring technical post ahead —

Read the rest of this entry »

Written by John Mettraux

May 7, 2008 at 8:49 am

Posted in bpm, openwferu, rest, ruby, workflow

taskr – restful scheduler – by Matt Zukowski

Matt just announced he developed Taskr a RESTful cron / scheduler daemon written in Ruby.

A cron / scheduler managed via REST, that’s neat. PUT a task for execution in 5 days or every day at 6 am. There are facilities for the tasks to interact with other RESTful services.

taskr_screenshot

It’s based on Camping and on the OpenWFEru scheduler. For the Ruby on Rails aficionados, there is a Taskr Rails plugin.

I like the idea, it’s very focused, with a big potential. Congrats to Matt !

Written by John Mettraux

January 4, 2008 at 4:09 pm

restful workflow engine

update : the work announced here has been renamed “ruote-kit”, you can find it at http://github.com/tosch/ruote-kit


I’ve been working on this vaporous thing / project for a while, now it’s here, in its first iteration. It’s called Kisha (steam train).

The short designation is “RESTful workflow engine”, the long one is “RESTful Rails® enveloppe for an OpenWFEru engine [and a worklist]”.

Kisha is leveraging Ruby on Rails 2.0.2 to present a RESTful interface to the OpenWFEru workflow engine.

This first iteration implements 2 core use cases via 2 resources.

The use cases are :

  • launching a new instance of a process
  • editing and then proceeding/saving a workitem

quick wiki quote :

A business process or business method is a collection of interrelated tasks, which solve a particular issue

The 2 resources are “processes” and “workitems”. Thus, RESTfully yours, these paths are available :

  • /processes the list of processes currently running in the workflow engine
  • /processes/{process_instance_id} accessing a particular process instance
  • /workitems all the workitems awaiting manipulation/proceeding from an external participant (you)
  • /workitems/{workitem_id} a particular workitem

Launching a process is done by POSTing a process/launchitem representation to /processes, while modifying/proceeding a workitem is by PUTting an updated representation of that workitem at /workitems/{workitem_id}.

(there is a working draft enumerating those resources at kisha.txt)

That’s for the theory.

Kisha is available in its first iteration as a zip download or via the source (see this piece of documentation).

For documentation and test purposes, I took care of providing a well-connected set of HTML representations of the resources, here are a few screenshots :

Kisha screenshot

What’s in this first iteration :

  • well connected HTML representations (learn the interface by playing around)
  • Rails ActiveResource JSON and XML representations
  • Atom representations as well
  • Possibility to post resources (/processes for now) via AtomPub
  • limited Authentication scheme (127.0.0.1 is trusted as well as the canonical “user” user, via basic http authentication)
  • binary Authorization (once you’re authentified, you can do everything)
  • a chart representation for workitems and processes (it’s taken out of densha)
  • a plain model for participants : there is one ‘catch-all’ participant (an expressions with a typo could be mistaken for a participant)

I’ve tried hard to accept a large set of variants for the process/workitem input (json, xml, yaml, atom entries, …), Kisha should be able to accomodate them all, this has proven the most time consuming aspect for now.

What will be in further iterations :

  • more authentication schemes (Pat is petitioning me about them)
  • a better authorization system (who can launch, who can proceed, who can pause)
  • more resources (process errors, process variables, maybe process definitions, …)
  • why not a /participants resource ?
  • more efficient usage of the resources (etag & co)
  • polishing the AtomPub interactions
  • activity [atom] feed
  • more documentation

Over for now.

Feedback is welcome on the OpenWFEru mailing lists.

Written by John Mettraux

December 20, 2007 at 5:52 am

ruote 2.1 released

Just released ruote 2.1.1. That requires a long, boring, explanatory blog post, especially since I was promising a ruote 2.0.0 release and now I’m jumping to 2.1.1.

My prose isn’t that great, the transitions from one paragraph to the next are often poor. Let’s try anyway.

Ruote is an open source ruby workflow engine. Workflow as in “business process”. Sorry, no photo workflow or beats per minute.

0.9, 2.0, 2.1

In May 2009, I had the feeling that ruote 0.9 was a bit swollen and very baroque in some aspects, some early design decisions had forced me to do some juggling and it felt painful. At that point, I was working with other languages than Ruby and I had written the beginning of a ruote clone in Lua.

Fresh ideas are tempting, after a while I got back to Ruby and started a ruote 2.0 rewrite.

I was fortunate enough to benefit from the feedback of a startup company that pushed ruote in a terrain that it was not meant to travel. Whereas I built ruote and the systems that came before for small organizations and trusted integrators to divide the work among multiple engines, these people started stuffing as much possible work into one engine, with extra wide concurrent steps.

Those experiments and deployments brought back invaluable learnings, matured the 2.0 line very quickly, but, in October, I was seriously tempted to venture into a second rewriting.

Ruote 2.0 was a complete rewrite, ruote 2.1 is only a rewrite of the core. The test suite is mostly the same and working from the 2.0 test suite allowed me to build a 2.1 very quickly.

things learnt

So what triggered the 2.1 rewrite ?

At first, a feeling of unease with the way certain things were implemented in 2.0. Some of them were inherited from the previous ruote 0.9, while others came from the rewrite, in both cases, I made bad decisions.

Second, those load reports. The 2.0 workqueue is only a refinement of the 0.9 one. The workqueue is where all the tasks for the expressions that make up the process instances are gathered. It’s a transient workqueue, processed very quickly, internal to the engine.

Ruote, being a workflow engine, is meant to coordinate work among participants. Handing work to a participant occurs when the process execution hits a ‘participant expression’. This usually implies some IO operations since the ‘real’ participant is something like a worklist (a workitem table in some DB), a process listening somewhere else and reachable via a message queue (XMPP, AMQP, Stomp, …).

As IO operations depend on things outside of the engine, the dispatch operation was usually done in a new thread, so that, meanwhile, the engine’s workqueue could go on with its work (and the other process instances).

When farming out work to ‘real’ participants with wide concurrency, as the engine is spawning a thread for each dispatch, it gets crowded. The engine got vulnerable at this point. Right in the middle of dispatching, with still lots of tasks in the transient workqueue, the best time for things to go wrong, the engine to crash, and processes to stall.

Third ? Is there a third ? Ah yes, I started playing with CouchDB (Thanks Kenneth), and many of the ideas in it are seducing and inspiring.

rubies

My passion for workflow engines comes from my [naive] hopes of reducing human labour, reducing total work by reducing/removing the coordination chores, the friction. Tasks left should be automated or left to humans. Left to humans… the bottleneck is in the human participants… Then there is this half-conviction that a workflow engine doesn’t need to be that fast, since most of the time, it sits waiting for the human-powered services to reply (or to time out).

Also I had settled on Ruby, a beautiful language, with not so fast interpreters (though this is changing, on many fronts, with so many people liking Ruby and giving lots of their times to make it better). The value of a workflow engine lies at its edge, where coordination meets execution, in the participants. That’s where Ruby shines (once more), since it makes it easy to write custom participants very quickly and to leverage all the crazy gems out there.

(I say Ruby shines once more, because I think it shines as well as the implementation language for the engine itself. It feels like the boundary between pseudo-code and code vanished)

Slow people, slow me, slow rubies.

storage and workers

I mentioned a few lines before CouchDB, that database made “out of the web”. Writing things to the disk is a necessity for a workflow engine. It’s an interpreter, but its processes are meant to last (longer than the uptime of a CPU).

One of CouchDB strengths comes from its eventual consistency and it made me wonder if, for ruote, it shouldn’t be worth sacrificing a bit of short-term performance for medium-term scalability / robustness.

A frequent complaint about Ruby is its global interpreter lock and its green threads, making it not so sexy in a 2+ core world. Threads are easy to play with from Ruby, but they’re quite expensive (some patches address that) and if you want to get past of the global lock, there seems to be only JRuby now.

Workqueue, queue ? Worker. Why not multiple workers ? One [Ruby] process per worker, that would be ideal ! Let them share a storage for Expressions, Errors, Schedules, Configuration and… Messages.

Ruote 2.1 has a persisted workqueue. For the items placed in the queue, I use the term “message”, it covers “tasks” (sent for execution by expressions) and “events” (intra-engine notifications).

An interesting consequence : a persisted workqueue can be shared by multiple workers, workers not in the same Ruby process.

A message ordering the launch of a ruote process looks like :

  {"type": "msgs",
   "_id": "1984-2151883888-1261900864.59903",
   "_rev": 0,
   "action": "launch",
   "wfid": "20091227-fujemepo",
   "tree":
     ["define", {"name": "test"}, [
       ["sequence", {}, [
         ["participant", {"ref": "alice"}, []],
         ["participant", {"ref": "bob"}, []]]]]],
   "workitem": {"fields": {}},
   "variables": {},
   "put_at": "2009/12/27 08:01:04.599054 UTC"}

Note the process definition tree passed in to the ‘tree’ part of the message, the empty workitem, the freshly minted process instance id in ‘wfid’, and yes, this is JSON. The process, named ‘test’ is simply passing work from alice to bob (in a sequence).

What about the worker that has to handle this message ? It would like :

  require 'ruote'
  require 'ruote/storage/fs_storage'

  storage = Ruote::FsStorage.new('ruote_work')
  worker = Ruote::Worker.new(storage)

  worker.run
    # current thread is now running worker

Whereas the 2.0 workqueue was transient, 2.1 has an external workqueue exploitable by 1+ workers. Simply set the workers to share the same storage. 1+ workers collaborating for the execution of business process instances.

Apart from tasks that need to be handled ASAP, some tasks are scheduled for later handling. A workflow engine thus needs some scheduling capabilities, there are activity timeouts, deliberate sleep period, recurring tasks… The 0.9 and 2.0 engines were using rufus-scheduler for this. The scheduler was living in its own thread. The 2.1 worker integrates the scheduler in the same thread that handles the messages.

(Since I wrote rufus-scheduler (with the help of many many people), it was easy for me to write/integrate a scheduler specifically for/in ruote)

A storage is meant as a pivot between workers, containing all the run data of an engine, ‘engine’ as a system (a couple storage + worker at its smallest). Workers collaborate to get things done, each task (message) is handled by only one worker and expression implementations are collision resilient.

The result is a system where each expression is an actor. When a message comes, the target expression is re-hydrated from the storage by the worker and is handed the message. The expression emits further messages and is then de-hydrated or discarded.

This the code of the worker is rather small, there’s nothing fancy there.

There will be some daemon-packaging for the worker, thanks to daemon-kit.

storage, workers and engine

We have a storage and workers, but what about the engine itself ? Is there still a need for an Engine class as an entry point ?

I think that yes, if only for making 2.1 familiar to people used to Ruote pre-2.1. At some point, I wanted to rename the Engine class of 0.9 / 2.0 as ‘Dashboard’, and forcing the engine term to designate the storage + workers + dashboards system. But well, let’s stick with ‘Engine’.

Throughout the versions the engine class shrinked. There is now no execution power in it, just the methods needed to start work, cancel work and query about work.

Here is an engine, directly tapping a storage :

  require 'ruote'
  require 'ruote/storage/fs_storage'

  storage = Ruote::FsStorage.new('ruote_work')
  engine = Ruote::Engine.new(storage)
  
  puts "currently running process instances :"
  engine.processes.each do |ps|
    puts "- #{ps.wfid}"
  end

No worker here, it’s elsewhere. That may prove useful when wiring the engine into, say, a web application. The workers may be working in dedicated processes while the web application is given the commands, by instantiating and using an Engine.

Launching a process looks like :

  pdef = Ruote.process_definition :name => 'test' do
    concurrence do
      alpha
      bravo
    end
  end

  p pdef
    # ["define", {}, [
    #   ["concurrence", {}, [
    #     ["alpha", {}, []],
    #     ["bravo", {}, []]]]]]

  wfid = engine.launch(pdef)

The execution will be done by the workers wired to the storage, somewhere else.

It’s OK to wrap a worker within an engine :

  require 'ruote'
  require 'ruote/storage/fs_storage'

  storage = Ruote::FsStorage.new('ruote_work')
  worker = Ruote::Worker.new(storage)
  engine = Ruote::Engine.new(worker)
    # the engine start the worker in its own thread
  
  puts "currently running process instances :"
  engine.processes.each do |ps|
    puts "- #{ps.wfid}"
  end

This is the pattern for a traditional, one-worker ruote engine. With the exception that it’s OK to add further workers, later.

In fact, as long as there is one worker and it can reach the storage, the process instances will resume.

storage implementations

There are currently 3 storage implementations.

The first one is memory-only, transient. It’s meant for testing or for temporary workflow engines.

The second one is file based. It’s using rufus-cloche. All the workflow information is stored in a three level JSON file hierarchy. Workers on the same system can easily share the same storage. It uses file locks to prevent overlap.

The third one is Apache CouchDB based, it’s quite slow, but we’re hoping that optimizations on the client (worker) side like using em-http-request will make it faster. Speed is decent anyway and, on the plus side, you get an engine that spans multiple host and futon as a low-level tool for tinkering with the engine data.

Those three initial storage implementations are quite naive. Future, mixed implemenation storages are possible. Why not a storage where CouchDB is used for expression storing while messages are dealt with RabbitMQ ? (Note the doubly underlying Erlang here)

dispatch threads

As mentioned previously, the default ruote implementation, when it comes to dispatching workitems to participants, will spawn a new thread each time.

People complained about that, and asked me about putting an upper limit to the number of such threads. I haven’t put that limit, but I made some provisions for an implementation of it.

There is in ruote 2.1 a dedicated service for the dispatching, it’s called dispatch_pool. For now it only understands new thread / no new thread and has no upper limit. Integrators can now simply provide their own implementation of that service.

Note that already since 0.9, a participant implementation is consulted at dispatch time. If it replies to the method do_not_thread and answers ‘true’, the dispatching will occur in the work thread and not in a new thread.

2.1 participants

Speaking of participants, there is a catch with ruote 2.1. Participants are now divided into two categories. I could say stateless versus stateful, but that would bring confusion with state machines or whatever. Perhaps, something like “by class” vs “by instance” is better. By class participants are instantiated at each dispatch and are thus manageable by any worker, while by instance participants are already instantiated and are thus only manageable via the engine (the Engine instance where they were registered).

BlockParticipants fall into the by instance category.

  engine.register_participant 'total' do |workitem|
    t = workitem.fields['articles'].inject(0) do |art|
      t += art['price'] * art['count']
    end
    workitem.fields['total'] = t
  end

will thus only be handled by the worker associated with the engine.

A by class participant is registered via code like :

  engine.register_participant(
    'alpha', Ruote::Amqp::AmqpParticipant, :queue => 'ruote')

Whatever worker gets the task of delivering a workitem to participant alpha will be able to do it.

from listeners to receivers

Ruote has always had the distincition between participants that replied by themselves to the engine (like BlockParticipant) and other participants which only focus on how to deliver the workitem to the real (remote) participant.

For those participants, the work is over when the workitem has been successfully dispatched to the ‘real’ participant. The reply channel is not handled by those participants but by what used to be called ‘listeners’. For example, the AmqpParticipant had to be paired with an AmqpListener.

As on the mailing list and in the IRC (#ruote) channel, I saw lots of confusion between listeners and the listen expression. That made me decide to rename listenerers as ‘receivers’.

A receiver could also get packaged as a daemon.

I still need to decide if a receiver should be able to “receive” ‘launch’ or ‘cancel’ messages (orders). Oh, and the engine is a receiver.

releasing

I released ruote 2.1.1 at the gemcutter.

For some people, a gem is a necessity, while for others a tag in the source is a sufficient release.

I hope that by releasing a gem from time to time and tagging the repo appropriately I might satisfy a wide range of people.

I’m planning to release gems quite often, especially in the beginning.

The unfortunate thing with a workflow engine, is that many business process instances outlive the version they started at and it’s not that easy to stay backward compatible all along… That explains some of my reticence about releasing.

ruote-kit

ruote-kit is an engine + worklist instance of ruote accessible over HTTP (speaking JSON and HTML), it has a RESTful ideal.

It’s being developed by Kenneth, with the help of Torsten. My next step is to help them upgrade ruote-kit from ruote 2.0 to 2.1. It should not be that difficult. Apart from the engine initialization steps, the rest of ruote being quite similar from 2.0 to 2.1.

conclusion

Two major versions of ruote for 2009, that’s a lot. I hope this post will help understand why I went for a second rewrite and how ruote matured and became, hopefully, less ugly.

Happy new year 2010 !

 

source : http://github.com/jmettraux/ruote
mailing-list : http://groups.google.com/group/openwferu-users
irc : freenode.net #ruote

 

Written by John Mettraux

December 31, 2009 at 9:57 am

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 http://github.com/tosch/ruote-on-rails (rails3 branch is at http://github.com/tosch/ruote-on-rails/tree/rails3)

 

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 :

http://github.com/jmettraux/ruote_plugin
http://github.com/jmettraux/ruote-web2

http://github.com/jmettraux/ruote

And finally to the mailing list :

http://groups.google.com/group/openwferu-users

Written by John Mettraux

September 29, 2008 at 1:38 pm

ruote 0.9.19 released

I just released Ruote (OpenWFEru) 0.9.19. Ruote is an open source Ruby workflow / BPM engine.

This release comes in 4 packages : the ruote gem and three zip files : ruote-web, ruote-rest and ruote-fluo.

The core Ruote engine is a pure ruby workflow engine. It has its own process definition languages which can be expressed as XML or as Ruby code (or simply as a JSON string). I posted yesterday about how it works and there’s a quickstart available.

For a workflow pattern based evaluation of OpenWFE / Ruote process definition language see : http://eprints.qut.edu.au/archive/00014320/

http://github.com/jmettraux/ruote

Ruote-web is already known, it’s an integration of Ruote inside of a Rails shell. There’s a demo of it at http://difference.openwfe.org:3000. This new release integrates the latest ruote-fluo for rendering process definitions graphically, on the fly.

This is probably the last release of ruote-web itself. It will be replaced by ruote-web2 which will draw on the experiences and the design of ruote-rest. Ruote-web was written in haste to answer the frequent question “how do I integrate the ruote bpm engine into my rails application”. Now it’s time to get over that initial Rails implementation and do something better, based on Rails 2+, leveraging the lessons learnt in ruote-web and ruote-rest and using more of the tools found in the RubyOnRails ecosystem.

http://github.com/jmettraux/ruote-web

Ruote-rest aims at being a RESTful workflow server. It’s based on Rack and is thus rather light. It exposes 4 resources : processes, workitems, errors and participants. It currently speaks XML and JSON, but I hope that by the end of the year AtomPub will join the mix. It also speaks HTML for the sake of demonstrating its interface.

There’s a fifth resource exposed : expressions. Expressions are process instances atomic pieces. Processes can be updated on the fly over HTTP, get an expression, alter it and put it back. Ruote-rest even includes the editor version of ruote-fluo to facilitate such manipulations directly in the HTML interface. But I think the real value of this resource is when migrating processes ‘en masse’ to a new version via a few HTTP PUT requests.

Ruote-rest exposes a ruote workflow engine plus a simple worklist as a set of web resources. Ruote-rest HTML interface is worth a check as it shows how ruote-rest and ruote work in a direct “… and if I press this button ?” way.

There are already people in the community doing crazy things with ruote-rest. Composability over HTTP.

http://github.com/jmettraux/ruote-rest

Ruote-fluo main task is to render process definitions graphically on the fly. It’s now distributed separately because it’s now able to fulfill a second task : editing those process definitions. Well, it’s rather a process tree editor with the result rendered immediately, but I think it’s not that bad.

There is currently one big drawback about ruote-fluo : its rendering is Firefox 3 only ! I think webkit won’t stay behind in this race for displaying text in the canvas. It’s just a matter of time. (Yes, ruote-fluo is written in Javascript).

There is an online demo at http://difference.openwfe.org:4567/?pdef=pdef_ttt.xml

http://github.com/jmettraux/ruote-fluo

That’s it for this release. I hope to post a bit more about ruote-rest in the following weeks and to start the work on ruote-web2, as well as to enhance ruote-fluo’s editor aspect.

Feedback and participation (fork?) are welcome.

Written by John Mettraux

September 9, 2008 at 10:25 am

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

lunch with Keith Swenson

Last week, I had the privilege of having lunch with Keith Swenson. I have to admit I’m a fan of his “Go Flow” blog.

Keith Swenson is a fellow of the Workflow Management Coalition and he works for the R&D of Fujitsu Computers Systems. He has more than 15 years of experience in the workflow and business process management fields.

We talked about XPDL, federated workflows, RESTful BPM, WfXML-R and he gave me some explanations about the new Fujitsu process discovery service (I’d love to work on such a tool).

This meeting could have happened a bit earlier as we realized that our offices are just 4 blocks away from each other.

Keith gladly accepted to give a speech soon at a BPMinna meeting (Wakizaka-san, we have to talk about that).

This lunch was very instructive as well as friendly, I just forgot to ask for his business card, well, next time.

Written by John Mettraux

August 2, 2008 at 2:48 pm

Posted in bpm, rest, workflow, xpdl

ruote 0.9.18 released

OpenWFEru (Ruote) is an open source workflow and BPM engine written in Ruby. I just released version 0.9.18.

Why “Ruote” ? “OpenWFEru” is long to spell… The initial nickname was “Rufus”, but as I reused it for the subprojects not related to BPM, I needed another one. Tomaso suggested me “Ruote” and it sounded just right.

“Ruote” means “wheels” in italian, but it has migrated to english as well. Leopard’s dictionary says :

ruote |roōˈōtē|
noun
pasta that resembles small wheels with five spokes radiating from a hub.
ORIGIN Italian, literally ‘wheels’ .

And it’s OK to have a pasta as the nickname of a project that now allows to script spaghetti business processes thanks to the new step expression.

The complete release announcement as addressed to the users mailing list.

OK, back to work, I’d like to improve ruote-rest, I guess I’ll have to improve (finish) the example first before feeling restful.

homedemodownloadsourcequickstartissuesfeedback

Written by John Mettraux

May 22, 2008 at 5:33 am

Pat is a subsversive restafarian

Sandy almost called the security to get Pat bounced out of Architecture & Process 2008. I’m joking, she just wondered what was Pat doing there.

If you consider the fact that “Architecture and Process” website is hosted at http://www.transformationandinnovation.com, then RESTful BPM is a nice fit for this event.

If you’re still not convinced, go and read Jason’s reaction and Pat’s reply.

Congrats to Pat Cappelaere for his success with RESTful WfXML.

I’m working on it as well (with my limited vision), after Kisha, I’ve moved on to Ruote-Rest.

Too many links.

Written by John Mettraux

April 26, 2008 at 11:17 am

Posted in bpm, geobpms, rest, workflow