On Fri, May 9, 2008 at 1:45 AM, Tomaso Tosolini <[EMAIL PROTECTED]> wrote: > Hi John, hi All > > apart other things in the last weeks i tried to make some considerations > about creating a method to have more comfortably designs like the trouble > ticket process, were the basic idea is that given a workitem positioned into > a particular place in a directed graph when "step" replies, engine would > dispatch to one following "step" (or to a set of them), depending on a > generic choice method.
Hi Tomaso, since that touble ticket process (http://jmettraux.wordpress.com/2008/01/04/the-trouble-ticket-process/) I have been thinking to have something for people more transition oriented into OpenWFEru (http://rubyforge.org/tracker/index.php?func=detail&aid=18935&group_id=2609&atid=10195). Incidentally that is what I was working on yesterday evening (http://github.com/jmettraux/ruote/commit/0a3dd6115304a5c57f88323d1c2a2f0051a6feff) (branch "step_expression"). I will try to explain here what I have done yesterday evening with the "step" expression and where the "state" and "transition" concepts come into play. I'm trying to let people express their idea in a concise way and I'm also trying [hard] to reuse the concepts already present in OpenWFEru. I quite liked the "step" expression I implemented (directly in the OpenWFEru process language) for the "trouble ticket" example : ---8<--- process_definition :name => "step" do sequence do # participant performs activity participant :ref => "${part}", :activity => "${desc}" # then, call next step (via a subprocess) subprocess :ref => "${field:next}" end end --->8--- In a single stroke, you have a link between a state (a participant pointed at via the "part" parameter subprocess parameter) and a transition (a call to a subprocess whose name is held in the "next" field). So we have cheap state names as participant names, to look up a state we simply leverage the participant lookup mecha in Ruote and we're done. For transitions, we use the subprocess name lookup mecha to trigger the next segment in the process. Another nicety, there is no <if> or <case> implied (that was one of the constraint derived from Keith Swenson BPMN diagram (can't remember if he is the author though)). My idea with the step "expression" was to make this concept available to all processes. I went a bit further and hardcoded it from a subprocess to an expression. This is how it looks : http://github.com/jmettraux/ruote/tree/b89b4b75637d489c6c89d4b515f4b68749d4553a/lib/openwfe/expressions/fe_step.rb#L48 I generalized the lookup for both the state and the transition. It means that you can point at a participant or a subprocess for the "state body" and at a process or a participant as the "next / outcome" to transition to. For "boot transition", I think that the classical "body" of a process definition is OK, the rest being just subprocesses (and participants). If you need multiple outcomes, you can point to a subprocess that wraps a concurrence. I think that my approach is not very verbose and it leverages the current Ruote. Would that suit your state-transition needs ? What is missing ? Cheers, -- John Mettraux - http://jmettraux.wordpress.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
