changes for the ‘cron’ expression

It’s not a post about the ‘cron’ aspect of the Rufus::Scheduler (ex-OpenWFEru::Scheduler), it’s about the cron expression of OpenWFEru’s process definition language.

A vanilla use case for the ‘cron’ expression, sending a reminder (every 10 minutes) to participant “toto” until he finishes the required activity (BPM for slavery) :

  class SampleDefinition < OpenWFE::ProcessDefinition

    # body of the process
    #
    sequence do
      activity_1
      activity_2
    end

    # subprocess definition
    #
    process_definition :name => "activity_1" do

      concurrence :count => 1 do
        # expecting just 1 branch to reply

        participant "toto"
        cron :tab => "10 * * * *" do # every 10 mn
          send_reminder :to => "toto@localpub.co.uk"
        end
      end
    end

    # ...
  end

Up until now (OpenWFEru 0.9.17 included), the cron expression relied on the variable system for storing its schedule (and eventually get rescheduled in case of engine restart). Schedules bound at the engine level are meant to last longer than the business process that initiated them.

The initial implementation worked fine. Two problems though :

1) this “bound at the engine level” was implemented as a special case, that made the code more complex, more prone to errors

2) the biggest problem : engine level “crons” were thus sitting in the engine environment as variable values and were not cancelable without a tedious manipulation (basically launching a process that erased the engine variable or stopping the engine, editing the engine env and restarting the engine).

The improved process administration console of Densha revealed acutely this “can’t cancel cron” issue. That called for a change.

This initial implementation of ‘cron’ was immediately replying to the parent expression after “hiding” itself in the among the local variables (or the engine variables).

The new implementation blocks until cancelled, hence the example process definition at the top of this post, where the concurrence expression, upon receiving a reply from its “participant toto” branch cancels the remaining “cron” branch.

If you want a cron that outlasts its initiating process, you now have to wrap it in a [sub]process. This subprocess will be visible to the process administrators, like any other process, thus easily manageable.

(That reminds me I have to dig the BPMN spec to find decent graphical representations for the cron, the when and the sleep expressions).