processi

about processes and engines

replay_at_last_error

engine.get_journal.replay_at_last_error(workflow_instance_id)

Running processes will break. For sure.

Consider this process definition :

a simple process definition (in Ruby directly)

What happens if there is no participant “reviewer_b” registered as a participant in the OpenWFEru engine ? Or if there is a participant but the dispatch medium between the engine and it is temporarily broken ? The simple concurrence here will idly wait for a reply from the “reviewer_b”.

OpenWFEru already featured a journal component, it is not well documented, not because I’m lazy, but because it’s harder to explain than the usual workflow stuff.

I’ve thought about this “harder to explain” argument and came with a “maybe let’s bring something easier to explain”, enters the “replay_at_last_error” method of the journaling system.

The workflow for that kind of problem fixing may be summarized to :

  1. spot error in process
  2. fix cause of error
  3. restart process

You’d be able to spot the error in the engine log or directly in the process journal.

For a missing participant, fixing the error might amount to something like :

adding the missing participant

And then let’s restart / replay at the error [point] the process with :

restarting the process definition at the point where it failed

It’s in OpenWFEru 0.9.11 which will be released this week, just before the RubyKaigi2007.

I still have to provide a decent documentation for the journaling system as it is useful for process migrations, not just for fixing processes.

Update : I’ve update the journaling documentation to describe this replay_at_last_error() technique.

Written by John Mettraux

June 4, 2007 at 6:59 am

Posted in bpm, openwferu, workflow

One Response

Subscribe to comments with RSS.

  1. […] said earlier, this release contains the replay_at_last_error method and the listen […]


Comments are closed.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: