14 Replies Latest reply on Jan 20, 2009 10:20 AM by Tom Eugelink

    decision conditions

    Tom Baeyens Master

       

      "Jeff Delong" wrote:
      The doc says:

      "A decision takes the first transition (as ordered in the processdefinition.xml) for which the expression resolves to true. If none of the conditions resolve to true, the default leaving transition (== the first one) will be taken."

      What I have in my process definition is a transition without a condition, which was listed second. I was assuming that this transition would be taken if the first transition evaluated to false. I was thinking that transitions without conditions were taken if no other transition was taken before them (as ordered in the processdefinition.xml). I thought I had read this somewhere, but can't seem to find it now ;) The idea that an "otherwise" transition with no conditions is taken if none of the conditions on the other transitions evaluate to true must be baggage I carried over from some other product.

      I put a condition on both transitions out of the decision:

      <transition name="to end" to="end1">
       <condition expression="#{contextInstance.variables['status']=='accepted'}"/>
       </transition>
       <transition name="back to Review" to="Correct Error">
       <condition expression="#{contextInstance.variables['status']!='accepted'}"/>
       </transition>
      

      And now it works as expected in both cases.


        • 1. Re: decision conditions
          Tom Baeyens Master

          if i recall correctly, before 3.1, the first transition was taken that didn't have a condition or for which the condition was met.

          this has now been changed to: if there is transition with a condition that is met, take that. otherwise the default transition (the first!) is taken.

          i changed it because i felt that the default transition should be the same as the 'otherwise' branch in a decision with conditions. not sure if that was the best decision ever :-)

          regards, tom.

          • 2. Re: decision conditions
            Jeff DeLong Master

            Now that I understand it, I like how it works in 3.1. I think it is good to be explicit, and specify the transition on each condition. It makes for clearer process definitions. The way I modeled it at first is the lazy way, and makes assumptions about the underlying engine (which as it turns out changed from one release to the next).

            • 3. Re: decision conditions
              Alejandro Guizar Master

              So, what happens in 3.1 in these scenarios:
              The first transition has no condition. Are conditions in other transitions evaluated and if none is met, the first transition is selected?
              The first transition has a condition, but it is not met, nor are conditions in other transitions. Is the first transition still selected in this case?
              There is a transition below the first place with no condition. Is that allowed? Will it ever be selected?

              • 4. Re: decision conditions
                brittm Novice

                Conceptually, it seems to me that a transition should never be taken if it has an explicit condition that is not met.

                • 5. Re: decision conditions
                  Tom Baeyens Master

                  britt, you're right. completely overlooked that possibility. that is just plain wrong.

                  alex, your questions show that indeed the current design is problematic.


                  my current question is then: will reverting to the old way of doing things solve all the problems ?

                  so

                  a decision without a decision handler will scan all of its transitions in sequence.
                  the first transition is take that
                   * doesn't have a condition
                   or
                   * has a condition that is met


                  does that make sense ?

                  regards, tom.

                  ps. jee... what was i thinking (or drinking)...

                  • 6. Re: decision conditions
                    brittm Novice

                    Tom,
                    Ideally, users should:

                    1) Always consider providing a default transition (without a condition).
                    2) There should never be more than one default.
                    3) Any default should always be the last one in the list.


                    The old way of doing things that you quoted seems to support that scenario. Of course, it would always be nice to document and perhaps enforce intended usage, but that's another issue.

                    Am I missing anything?

                    • 7. Re: decision conditions
                      brittm Novice

                      It's worth mentioning that the scenario I just listed actually is similar to the default transitions in other types of nodes where the first non-qualified transition is taken--the conditions specified on the decision node's transitions simply pushs the natural default further down on the list.

                      • 8. Re: decision conditions
                        Alejandro Guizar Master

                         

                        Always consider providing a default transition (without a condition).

                        +1
                        2) There should never be more than one default.

                        +1
                        3) Any default should always be the last one in the list.

                        I don't think so. In programming languages the otherwise/default branch is always the last one, so one feels compelled to have the default transition at the end of the list. However, the "default leaving transition" in jBPM is always the first one in document order. Further, jPDL is a process language. Most people will use the GPD for edition, so we don't need to be consistent with programming languages.

                        • 9. Re: decision conditions
                          brittm Novice

                          Unfortunately, with the rules Tom quoted, the default transition would effectively be the last one anyway, because nothing after it would get an opportunity to be evaluated.

                          Alex, you're right that the default (non-conditional) transition could be the first one -- but of course all conditional transitions would have to be evaluated first before taking the default. That starts to look a bit strange:
                          We list the default transition first, then starting with the second entry we begin the list of orderd conditional transitions that we really want to evaluate before we consider the first transition we listed. So that we kind of have an ordered list--but kind of don't.

                          Even with the GPD, the XML should still read logically unless there is a compelling reason to do otherwise.

                          Just to be thorough...
                          Of course, we could always discard logical ordering for the default and do this:

                          <transitions>
                           <default><transition /></default>
                           <evaluation-list>
                           <transition />
                           <transition />
                           </evaluation-list>
                          </transitions>
                          Though this is entirely inconsistent with the rest of the jpdl as well.

                          Or, we could simply select one of the transitions in the ordered list as a default and label it as such with an attribute. This strategy could also be used throughout the jpdl to explicitly declare a default.

                          Now that I've worn out this horse, I still like my first idea best :)

                          • 10. Re: decision conditions
                            Matt Jackson Newbie

                            SO what are the current rules for transitions?

                            • 11. Re: decision conditions
                              David Hosier Novice

                               

                              "alex.guizar@jboss.com" wrote:
                              Further, jPDL is a process language. Most people will use the GPD for edition, so we don't need to be consistent with programming languages.


                              I just picked up this thread and wanted to comment on the above. I slightly disagree, since there is currently no way to specify conditions on a transition without directly editing the XML. I think it could be viewed like a switch statement in Java (and C/C++ or whatever) with an implied break. It goes down the list and takes the first transition whose expression evaluates to true. If that doesn't happen, it drops to the last one, just like a default: line. I figure I'm way late adding to this debate, but what the hell....

                              • 12. Re: decision conditions
                                Tom Eugelink Newbie

                                 

                                "brittm" wrote:
                                Conceptually, it seems to me that a transition should never be taken if it has an explicit condition that is not met.


                                Well, I'm not sure what the end-all outcome is of this discussion, however:

                                 <decision name='decision1'>
                                 <transition to='state1' name='path1'>
                                 <condition expression="#{x==1}"/>
                                 </transition>
                                 <transition to='state2' name='path2'>
                                 <condition expression="#{x==2}"/>
                                 </transition>
                                 <transition to='state3' name='path3'></transition>
                                 </decision>
                                


                                Jbpm 3.2.3:
                                if x = 2, path2 is taken.
                                if x = 5, path1 is taken.
                                if x not set, path1 is taken.

                                The last two feel incorrect to me. I can resolve this by moving the default transition (path3) to the first position, but the behavior seems incorrect by reason stated in the quoted post.

                                So, JBPM simply is executing transactions with invalid conditions?

                                • 13. Re: decision conditions
                                  Mauricio Salatino Master

                                  if you see the class Decision.java you should see the last lines:

                                   if (transition==null) {
                                   transition = getDefaultLeavingTransition();
                                   log.debug("decision didn't select transition, taking default "+transition);
                                   }
                                  
                                   // since the decision node evaluates condition expressions, the condition of the
                                   // taken transition will always be met. therefor we can safely turn off the
                                   // standard condition enforcement in the transitions after a decision node.
                                   transition.removeConditionEnforcement();
                                  
                                   } catch (Exception exception) {
                                   raiseException(exception, executionContext);
                                   }
                                  
                                   log.debug("decision "+name+" is taking '"+transition+"'");
                                   executionContext.leaveNode(transition);
                                  


                                  that means that if no transition is elected then the defaultTransition is taken.


                                  • 14. Re: decision conditions
                                    Tom Eugelink Newbie

                                     

                                    "tbeernot" wrote:

                                    So, JBPM simply is executing transactions with invalid conditions?


                                    After some discussion with a colleague... Even though we prefer to have JBPM execute the first unconditional transition if all conditional transitions fail (and only if there are no unconditional transitions, then execute the absolute first)... If this is the behavior, one can live with that: the default transition simply is always the first.