8 Replies Latest reply on Mar 18, 2008 3:50 AM by tom.baeyens

    conditions on transitions

    tom.baeyens

      To put conditions on transitions, has anyone got a good proposal for putting guard conditions on transitions ?

        • 1. Re: conditions on transitions

          As a first thought:

          - Conditions should be evaluated internally by the PVM not by the NodeBehaviours

          - Conditions could be a java expression (if like) or a EL (I think this will be part of the PVM, right ?)
          In both cases conditions leverages variables.

          - Conditions evaluation could be performed either inside the "take" method (ExecutionImpl) or in the TakeTransition atomicOperation ?

          "take" method can be called from either the PVM internals or from one node behaviour. This method gets the default or a selected transition as a parameter.
          This method will perform the TakeTransition atomic operation.

          I would suggest to evaluate conditions inside the take method just before calling the performActivityOperation.

          - When a condition is evaluated to false, the execution is cancelled ?. This will have an impact on the Join nodes implementations (some childExecutions will be never executed). This requires to handle cancelled executions.

          In Bonita, support for conditions on trasitions was pretty intuitive. When an activity was finished, the engine get the outgoing transitions and evaluates conditions first and then propagates to the next activities. Conditions evaluated to false set this execution branch to dead.

          regards,
          Miguel Valdes


          • 2. Re: conditions on transitions
            tom.baeyens

            i think that adding conditions to transitions in the process definition structure is a good thing.

            but i'm not yet sold on a unified runtime enforcement of guard conditions. i would guess that the process languages have too different requirements for that.

            I would start with a simple interface. Something like

            public interface Condition {
             boolean evaluate(Execution execution) throws Exception;
            }


            then different implementations can be build for that, including an implementation that is based on EL expressions.

            I'm pretty comfortable with adding methods
            getAvailableOutgoingTransitions()
            and
            isOutgoingTransitionAvailable(Transition)
            on the execution.

            But I think we should leave it up to the process langauges to use it and enforce it as they want.

            WDYT ?

            • 3. Re: conditions on transitions

              Who would be responsible for calling the "evaluate" method, the PVM or Node Behaviours ?

              regards,
              Miguel Valdes

              • 4. Re: conditions on transitions
                tom.baeyens

                PVM.

                There would be 2 conditions on a transition. 1 would be the guard condition.

                A second one would specify wether the transition is taken automatic or wether it requires an external trigger.

                The second condition is the one we're talking about and that one should be called by the PVM.

                • 5. Re: conditions on transitions
                  charoy

                  Hello

                  what is the current status about condition.

                  It seems that the GuardCondition is never used by the PVM. Only the WaitCondition is evaluated.

                  It means that the GuardCondition is not evaluated in the PVM but in the ExternalActivity as it is the case in NovaBonita. This contradict the previous discussion on the design of PVM.

                  Is it a temporary situation ? If not, keeping the GuardCondition at the PVM level is useless and may even be confusing.

                  François

                  • 6. Re: conditions on transitions
                    tom.baeyens

                    guard condition can be used by activity implementations to evaluate it and act upon it. e.g. decision could be based on it. and a dynamic fork could be based on it.

                    i didn't yet see a reason to *enforce* that check in the PVM itself. if that condition would fail, then that implies a bug in the activity implementations.

                    that is the background that explains why it is done this way. that doesn't mean it is perfect. so please keep discussing if you would like to see it different.

                    • 7. Re: conditions on transitions
                      kukeltje

                       

                      i didn't yet see a reason to *enforce* that check in the PVM itself. if that condition would fail, then that implies a bug in the activity implementations.
                      Why not use it in a way that when it is taken it is considered as non-existent and throw an error? Maybe a more explicit error like 'TransitionNotAvailableNowException" or something like that ;-)

                      • 8. Re: conditions on transitions
                        tom.baeyens

                        in that case we have to enforce it.

                        the underlying problem is the performance that is consumed by evaluating the expression. that can potentially be expensive. so in case of a decision, the evaluation of the transition that is taken will be calculated twice.

                        process languages can build in such a check if they want by subclassing the ExecutionImpl and overriding some methods.