Running processes will break. For sure.
Consider this process definition :
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 :
- spot error in process
- fix cause of error
- 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 :
And then let’s restart / replay at the error [point] the process with :
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.