Hi! thanks for the fast and kind reply as usual...
On Fri, May 9, 2008 at 3:04 AM, John Mettraux <[EMAIL PROTECTED]> wrote: > > 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"). Yes, i saw it: yesterday after posted here i went on github ans saw thay you committed the new branch four minutes before... perhaps this is a new form of workflow mind synchronisation :) > > > 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). I liked it too, and so i tried to study it quite deeply. I noticed that in the first commit you included the concept of "outcomes", already described in the TTP post. > > > 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. I agree, this is a very cheap but effective architecture . > > > 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)). Here i was thinking about situations like: activity1, when complete if ${x} >= 15 activity2 elsif ${y} == 'W_Ruote' activity3 else activity4 It is possible to gain the same things also in the step based arch, but either one has to redesign the step to include the if expression stuff or one must have thong hidden within the participant expression: in the activity1 the "last" operations should be if ${x} >= 15 set_field :next, "activity2 elsif ${y} == 'W_Ruote' set_field :next, "activity3 else set_field :next, "activity4 There is nothing wrong in this, only that the <on state="..."> [decision] </on> mecha seemed a little more expressive to me, expecially when compared to the latter step strategy that hides things in participant "activity". I'm not so sure that the step strategies i described before are the only ones possible so please let me know if there are others, i'd like to have a comprehensive knowledge about that matter, it is quite important also for me.... > > > > 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). > At first I introcuced it in my design because I was thinking about the possibility to have more than one entry point, but after some thoughts i noticed the non restrictivity of the single entry point hypotesis, but it seemed quite expressive for the process description so I decided to keep it. > > 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. I agree 100%: your approach has no impact in the current Ruote and brings new good functionality. After reading the last things i start thinking that that step method is similar to another design that i considered aside the proposed one: what changes is that one should put into each state expression the instruction about next state(s) selection. <state name=""> <activity_part> </activity_part> <transition_part or "were to go when done"> </transition_part> </state> I preferred not to choose this because the idea of a complete separation of the states(that resemble the operative nuclei within the process) from the transitions(that are the coordination of the operations) seemed me more elegant from a formal point of view and, but i'm not sure about this, more safe when process schema become large. Please let me know what you think... Thanks a Ton ;) Tomaso > > > 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 -~----------~----~----~----~------~----~------~--~---
