processi

about processes and engines

Archive for the ‘bpms’ Category

resource lifecycle tuple

I came across this passage :

Moving from design to implementation, we need to think about the protocol in a slightly different way. In a resource-oriented distributed application, an application protocol can be thought of as a function of one or more resource life cycles and the business rules that connect these resources. Because of its resource-centric nature, the Restbucks service does not host an application protocol state machine. In other words, there’s no workflow or business logic for the application protocol as such. Rather, the service governs the life cycles of the orders and payments participating in the application protocol. Any workflows in the service implementation relate to resource life cycles, not the application protocol life cycle. While we’ve been explicit in modeling the business process as an application protocol state machine, we’ve been diligent in implementing it wholly in terms of resource state machines.

REST in practice, page 131, (emphasis mine).

 

I had to link that passage to this blog post :

The bottom line is that a business entity lifecycle represents some business logic that is “business process independent”. This is probably news to many of you and some of you might say that a BEL is a “long running process” but it is not. It is long running. It is a process in the sense of an operating system point of view (nearly), but it is not and will never be a “business process”. The business process is represented by the activities (human or automated) that advance the lifecycle of one or more business entities.

Lifecycle example, from Carnets de Bord

 

Written by John Mettraux

October 27, 2010 at 5:24 am

ruote and decision tables

ruote 2.1.7 is out and it felt like it was time to update the CsvParticipant that could be found in ruote 0.9.

Ruote has been relying on rufus-decision for its decision table needs and ruote 0.9 was integrating a CsvParticipant directly. For ruote 2.1, the DecisionParticipant is left in the rufus-decision gem.

It’s not the first time I write something about decision tables. But I noticed that I hadn’t really written anything about how to mix ruote processes and decision tables.

Let’s consider the decision table in the adjacent figure.

Given two input values “type of visit” and “participant physician ?” the level of “reimbursement” is decided.

The CSV version of this decision table is available online.

Clearly this decision has to take place after the customer filled his reimbursement claim and it got reviewed by a clerk in the organization.

Up until now, applying the reimbursement rules was part of the tasks of the clerk (with probably some downstream checks), and our goal is to remove some of that burden.

Our process definition would look like :

Ruote.process_definition :name => 'reimbursement', :revision => '1.0' do
  cursor do
    customer :task => 'fill form'
    clerk :task => 'control form'
    rewind :if => '${f:missing_info}'
    determine_reimbursement_level
    finance :task => 'reimburse customer'
    customer :task => 'reimbursement notification'
  end
end

There are four participants involved in that process definition. Customer, Clerk and Finance our implemented with classical inbox/worklist participants : workitems for them get placed in their workqueue. (With ruote 2.1 I tend to use StorageParticipant for that or I emit the workitem via a ruote-amqp participant towards the target worklist or task manager).

“rewind” isn’t a participant, it’s a ruote expression working with the cursor expression.

That leaves us with the participant “determine_reimbursement_level” to implement.

The straightforward Ruby implementation of the participant would leverage a BlockParticipant and look like :

engine.register_participant 'determine_reimbursement_level' do |workitem|
  workitem.fields['reimbursement'] =
    case workitem.fields['type of visit']
      when 'doctor office'
        workitem.fields['participating physician ?'] == 'yes' ? '90%' : '50%'
      when 'hospital visit'
        workitem.fields['participating physician ?'] == 'yes' ? '0%' : '80%'
      when 'lab visit'
        workitem.fields['participating physician ?'] == 'yes' ? '0%' : '70%'
      else
        '0%'
    end
end

Given the values in the fields ‘type of visit’ and ‘participating physician ?’ this participant sets the value of the field ‘reimbursement’.

All is well, but you may have noticed that the decision table is rather simplistic. And how does it cope with change ? What will it look like when the rules get hairy ? Will the Ruby developer have to intervene for each change ?

(it might not be a bad thing to rely on the Ruby developer, they tend to test carefully their creations)

Those rules are produced by ‘business users’ and one of their favourite tools is the spreadsheet. Rufus-decision can read CSV output of decision tables. The decision participant would look like :

require 'rufus/decision/participant'
  # gem install rufus-decision

engine.register_participant(
  'determine_reimbursement_level',
  Rufus::Decision::Participant,
  :table => {
in:type of visit,in:participating physician ?,out:reimbursement
doctor office,yes,90%
doctor office,no,50%
hospital visit,yes,0%
hospital visit,no,80%
lab visit,yes,0%
lab visit,no,70%
  })

Well, OK, that’s nice, but… We still have to restart the application at each change to the decision table or at least re-register the participant with the updated table. Tedious.

If our business people publish the decision table as CSV somewhere over the intranet (yes, I know, it’s an old-fashioned word), the decision participant can be simplified to :

require 'rufus/decision/participant'
  # gem install rufus-decision

engine.register_participant(
  'determine_reimbursement_level',
  Rufus::Decision::Participant,
  :table => 'http://somewhere.example.com/decision_tables/reimbursement.csv')

Each time a decision will have to be taken, the table will be read. This lets business users modify the rules at will.

The whole example is packaged as reimbursement.rb. It runs the process from the command line and grabs the decision table online. It shouldn’t be too difficult to take inspiration from it and integrate decision tables in web applications (like ruote-kit or barley).

There are many open possibilities when combining a workflow engine and a decision mechanism. One immediate advantage is that they can evolve with different rhythms. They can also be used in isolation : the clerk in our process could talk the claim over the phone with the customer and run blank decisions to help the customer with incomplete forms.

Of course, you can use rufus-decision without ruote, it’s a plain ruby gem.

 

http://github.com/jmettraux/rufus-decision – the source code of rufus-decision
http://github.com/jmettraux/ruote – the source code of ruote
http://ruote.rubyforge.org – ruote’s documentation
http://groups.google.com/group/openwferu-users – the mailing list for ruote and rufus-decision

 

Written by John Mettraux

February 17, 2010 at 4:32 am

Posted in bpm, bpms, decision, ruby, rufus, rules, ruote

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

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

OpenWFEru 0.9.17 released

Writing documentation can be painful, but it’s a necessity. So my main task these days about OpenWFEru is writing down an example, it’s about the Tea Testing Team. This piece of documentation is not yet complete, but it might be a good start.

The example is based on the latest Densha, a Ruby on Rails based web application wrapping a workflow / BPM engine. It adds a small worklist implemented thanks to ActiveRecords, that makes a quite decent BPMS (business process management system). So this eye-candy Densha is used in the Tea Testing example to demonstrate what OpenWFEru is about.

(Somehow, supporting this example is the main motivation behind this release of OpenWFEru + Densha 0.9.17)

There is an online demonstration of Densha at http://difference.openwfe.org:3000.

I’ve written before about the main feature this 0.9.17 Densha brings, I labeled it process gardening, cancelling pieces of business process instances. Well, the 0.9.17 goes a bit further, you can download as yaml a part of a process instance, modify it, then reload it in the engine… Business process modifications on the fly (these are admin features, you don’t want your users to directly modify process instances, whatever their IT literacy level is).

Densha has a ‘fluo’ component, it’s a javascript library that turns the process definitions into graphical process representation (the graphical notation used is BPMN, as far as possible). It’s implemented in javascript so it can be reused in other web interfaces, whatever the web framework (or the language).

It’s one of my goals to provide soon a web process designer leveraging this ‘fluo’ javascript library.

For the edition of workitem payloads, Densha uses a very limited forms system, just string and hashes. It should be enhanced a bit in the upcoming releases, but I shall write soon documentation on how to use custom forms (up to one custom form per activity / participant). It would be nice to have xforms as well.

Densha itself is not meant to be a state of the art Ruby on Rails application, it’s rather an example, a proof of concept and others have already used pieces of it (or simply as an inspiration) for building their own systems.

OpenWFEru shall reach 1.0 soon. I’d like to work on a few simplifications before that, then it will be ready.

The quickstart for OpenWFEru is available at : http://openwferu.rubyforge.org/quickstart.html

The quickstart for Densha is at : http://openwferu.rubyforge.org/rquickstart.html

As always, feedback is welcome on the OpenWFEru users mailing list.

Incidentally, this is my 300th post. Long way.

Written by John Mettraux

March 17, 2008 at 3:29 pm

Posted in bpm, bpms, openwferu, ruby, workflow

process gardening

My current objective is the release of OpenWFEru 0.9.17. There are many changes in the engine itself, but not much on its “interface”. There is however an interface that changed a lot, it’s the one of the [demo] web application around OpenWFEru.

The 0.9.16 release of this Densha web application features limited process administration capabilities : pausing/resuming a process instance, cancelling it.

“this business process instance has gone wrong, we have to cancel it”

The upcoming 0.9.17 release (already deployed on the demo web site) adds batch pausing / cancellation of processes and also some “process gardening” tools.

Process instances being execution trees, I’ve made it easy to chop off some branches (currently executing or not yet executed).

The [process] administrator can browse the execution tree of a running process instance and chop off (cancel) branches of it.

“this segment of this business process instance is not required any more, let’s remove it”

The web interface also allows modifying the process variables directly.

Workitems waiting in participant expressions are editable as well (though they could get overriden by the workitem coming back from the participant itself). Modifying the workitem waiting in a sleep expression might be more useful.

The next step for these process gardening tools will be the edition (instead of pure removal) of process branches. It’s already possible programmatically, but packaging that into a web interface is a hard task (will probably have to implement that process designer before). 0.9.17 will probably sport a primitive interface for process modification on the fly.

Written by John Mettraux

March 10, 2008 at 4:32 am

Posted in bpm, bpms, openwferu, workflow

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

state machine

“where are we in the process ?” is a question often heard (in the realm of workflow / process engines). A way of thinking about workflow is the “state machine” way, thus dividing the concept among “states” and “transitions”. Most of the time, this works out well.

With a state machine, it is a rather easy question to answer. OpenWFE[ru] is not based on state machines, it’s rather an interpreter.

Someone will still ask the question.

Read the rest of this entry »

Written by John Mettraux

December 3, 2007 at 9:58 am

Posted in bpms, openwferu, ruby, workflow

OpenWFEru 0.9.16 released

OpenWFEru 0.9.16 is available for download.

OpenWFEru is an open source workflow / BPM engine written in Ruby. Its nickname is “Rufus”, as OpenWFEru can be hard to spell.


This release includes the database persistence implemented by Tomaso Tosolini for the engine.

In no particular order :

  • The listen expression got improved
  • Added a lookup_processes() method to the engine, for querying about processes given variables and values
  • Scheduler jobs now have a schedule_info() method
  • The sequence expression implementation has been simplified for improved performance
  • Lots of work on the Atom and AtomPub front, resulting in the creation of the ActivityFeedParticipant, AtomPubParticipant (and BlogParticipant) and a rewrite of the AtomFeedParticipant
  • many small improvements and bug fixes

Densha, the example Ruby on Rails application embedding OpenWFEru has been improved as well :

  • Ability to query workitems in the stores
  • Process definition syntax highlighting (thanks to Alex Gorbatchev syntaxhighlighter library)
  • Integration of the ActivityFeedService to allow feed readers to subscribe to the engine’s activity feed

There’s a quickstart and further documentation.

Download via RubyForge or
sudo gem install openwferu openwferu-extras

Participate via the users mailing list (there’s also a dev list)

Many thanks to everybody who contributed with questions, patches and suggestions.

Written by John Mettraux

November 19, 2007 at 11:50 pm

Posted in bpm, bpms, openwferu, ruby, workflow