1 2 Previous Next 23 Replies Latest reply on Aug 19, 2009 6:01 PM by Ronald van Kuijk

    GetOutcomes returns additional transition

    Shekhar Vemuri Newbie

      Is there a particular reason for why GetOutComes does this?

      Set<String> outcomes = new HashSet<String>();
      outcomes.add(Task.STATE_COMPLETED);
      .. logic to add other transitions specified in the activity.
      


      When the TaskService.getOutComes(long taskDbId) is called with a task id it returns completed as an entry in the list of Transitions that will eventually be shown to the user.

      But this particular transition is not even being modeled in the process_definition.

      There are other places in the code, where in if a transition/outcome name is not specified then the transition is assumed to the 'completed' and special handling is done,

       if (Task.STATE_COMPLETED.equals(signalName)) {
       if (outgoingTransitions.size()==1) {
       transition = outgoingTransitions.get(0);
       } else {
       transition = activity.getDefaultOutgoingTransition();
       }
       }
      


      The above snippet is from TaskActivity.

      What is the reasoning behind adding this to the transitions that can be taken out of a Task?



        • 1. Re: GetOutcomes returns additional transition
          Ronald van Kuijk Master

          I remember a discussion about the behaviour that should be there when there is only one transition and whether it should have a required name. afair (can't find the discussion now) a name was not made compulsory so in the outcomes list there would be nothing then. So maybe there should have been a check that *only* if the processing of other outcomes returns no entries, this one should be there as the only one. So it might be a bug since I cannot imagine the this should be filtered out on the 'client' side of the taskservice.

          Please file a jira issue for this.

          • 4. Re: GetOutcomes returns additional transition
            Tom Baeyens Master

            "completed" is always a valid outcome

            In TaskImpl:

            public void complete() {
             complete(Task.STATE_COMPLETED);
             }
            


            this also fits with the logic that the task outcome doesn't have to match with the transition name if there is only one.

            if there are more transitions, then still "completed" is a valid outcome. in that case the default outgoing transition will be taken from the activity if task is completed with outcome 'completed'.

            so in other words, i don't yet see the unlogicality. can you elaborate more concretely what you expected different ?

            • 5. Re: GetOutcomes returns additional transition
              Ronald van Kuijk Master

              What I expect

              - If there is only one transition, it is allowed to have no name. Completed can be returned as the *only* possible outcome then.
              - If there are more transitions, all with names, completed is not there (why should it? To give the user the explicit option to choose the 'default' transition which he probably does not know which one it is?)
              - Ending a task with 'null' or nothing makes it take the default transition
              - If there is more then one transition, none are allowed to have no name (throw an error when parsing)

              Even better (but that was in the previous discussion) I think a name on a transition should be required. So this ' completed' is not needed then and passing (null) or () makes it take the default transition. Much more clear to me.

              • 6. Re: GetOutcomes returns additional transition
                Shekhar Vemuri Newbie

                Agree with Ronald. That was what I also thought would be the case. Hence the question,

                The fact that jbpm now automatically adds an outcome to the list is quite counter-intuitive actually as that list of outcomes is what we present to the user as possible actions he can take as part of completing the task. So by choosing the action we are saying that the completion is implied. If an action is not chosen then we need to implicitly select an action/transition and then complete it. And that is being handled as expected.

                Let me see if I can make a point with an example:

                Here's the processdefinition:

                <?xml version="1.0" encoding="UTF-8"?>
                
                <process key="CompletedOutcome"
                 name="CompletedOutcome"
                 xmlns="http://jbpm.org/4.0/jpdl">
                
                 <start g="20,20,48,48">
                 <transition to="Please Pick A Designation"/>
                 </start>
                
                 <task name="Please Pick A Designation" g="96,16,127,52">
                 <assignment-handler
                 class="org.jbpm.examples.task.assignmenthandler.AssignTask">
                 <field name="assignee">
                 <string value="shekharv"/>
                 </field>
                 </assignment-handler>
                 <transition name="Manager" to="Manager"/>
                 <transition name="Programmer" to="Manager"/>
                 </task>
                
                 <end name="Manager" g="255,16,88,52"/>
                 <end name="Manager" g="255,16,88,75"/>
                
                </process>
                


                Here's the unit test: Am trying to mimic how a client application would interact with jbpm.

                public void test_task_has_correct_outcome() {
                
                 ProcessInstance pi =
                 executionService.startProcessInstanceByKey("CompletedOutcome");
                
                 List<Task> tasks = taskService.findPersonalTasks("shekharv");
                
                 System.out.println("shekharv has to complete the following task:"
                 + tasks.get(0).getName());
                
                 Set<String> outcomes = taskService
                 .getOutcomes(tasks.get(0).getDbid());
                
                 System.out.println("Task \"" + tasks.get(0).getName()
                 + "\" has the following possible outcomes:");
                
                 assertTrue(outcomes.contains("Stage 1"));
                 assertTrue(outcomes.contains("Stage 2"));
                 //assertTrue(outcomes.size() == 2);
                
                 for (String outcome : outcomes) {
                 System.out.println(outcome);
                 }
                
                 taskService.completeTask(tasks.get(0).getDbid()
                 , "Stage 1");
                
                 }
                


                output of the test case:
                shekharv has to complete the following task:Please Pick A Designation
                Task "Please Pick A Designation" has the following possible outcomes:
                Manager
                Programmer
                completed
                


                So the user will now see an option of 'completed', and depending on how the transitions are ordered in that task node it might result in either the "Manager" activity selected or the "Programmer". On the lighter end, that is scary :)

                In the context of this workflow the transition 'completed' does not even make sense.

                Another example is, what if I have workflows and the actions depicted in a non-english language, people might not even understand what 'completed' means.

                So if jbpm adds that transition by default the client applications have to filter it out, they will not have any other option but to.

                sorry about the length of the post, it just grew on me!


                • 7. Re: GetOutcomes returns additional transition
                  Ronald van Kuijk Master

                  The whole concept of something like a default transition is not something I ever used. Guarded transitions yes, but the defaults no. Unfortunately, the issue is rejected (see the jira) and it stays as it is (Logical to Tom, illogical to us)

                  Now I know I have to at least implement one additional line in each PAO I'll write. Filter this outcome out.... weird...

                  • 8. Re: GetOutcomes returns additional transition
                    sri r Newbie

                    well, a process can still have a transition with name="completed". Does jBPM4 prevent when deploying such process defs?

                    • 9. Re: GetOutcomes returns additional transition
                      Shekhar Vemuri Newbie

                      No.

                      It allows for that.
                      Here is a small excerpt from the TaskActivity class:

                      if ( (outgoingTransitions!=null)
                       && (!outgoingTransitions.isEmpty())
                       ) {
                       transition = activity.findOutgoingTransition(signalName);
                       if (transition==null) {
                       if (Task.STATE_COMPLETED.equals(signalName)) {
                       if (outgoingTransitions.size()==1) {
                       transition = outgoingTransitions.get(0);
                       } else {
                       transition = activity.getDefaultOutgoingTransition();
                       }
                       } else {
                       // if a user specified outcome was provided and it doesn't
                       // match with an outgoing transition name, then the process
                       // instance is suspended. parked for admin intervention.
                       ((ExecutionImpl)execution.getProcessInstance()).suspend();
                       }
                       }
                       if (transition!=null) {
                       execution.take(transition);
                       }
                       }
                      


                      1.) If signal name was null at the time of signal, then it will take default transition, or the only one that is there.
                      2.) If signal name was provided and the value could be 'completed' or anything else, it first does that

                      transition = activity.findOutgoingTransition(signalName);
                      


                      So it will always pick the one that you have setup in the process definition, whether it is 'completed' or any other value, it does not matter.

                      So in short answer to your question, the case you mentioned is handled as one would expect it.

                      • 10. Re: GetOutcomes returns additional transition
                        Ronald van Kuijk Master

                        Great thinking. Personally I would think that if jBPM uses ' completed' like this internally it should be a reserved and therefore disallowed name. The fact that jBPM handles it gracefully is strange. In all cases where you do not have a 'completed' by yourself, you get one for free. In other cases you don't. Some people might start searching for a bug but in the end will find out there is this default weird behaviour.

                        • 11. Re: GetOutcomes returns additional transition
                          Shekhar Vemuri Newbie

                          But having said that, here comes the fun part: I believe this qualifies as unexpected behavior.

                          consider this process-definition:

                          <?xml version="1.0" encoding="UTF-8"?>
                          
                          <process key="CompletedOutcome" name="CompletedOutcome" xmlns="http://jbpm.org/4.0/jpdl">
                          
                           <start g="20,20,48,48">
                           <transition to="review"/>
                           </start>
                          
                           <task name="review" g="96,16,127,52">
                           <assignment-handler
                           class="RandomTaskHandler"/>
                           <transition to="redpill"/>
                           <transition name="completed" to="bluepill"/>
                           </task>
                          
                           <end name="redpill" g="255,16,88,52"/>
                           <end name="bluepill" g="255,16,88,75"/>
                          </process>
                          
                          taskService.completeTask(777, null);
                          


                          Guess where the workflow will end when the task is ended. Irrespective of what OUTCOME you pass to the completeTask, null or 'completed' it will always end up in 'bluepill'.

                          Is there any way to get to the redpill 'end' state? NO! Now is this right or wrong? The more I look at this, the lesser and lesser sense it makes to me.

                          But if course, the JIRA is rejected :(.

                          • 12. Re: GetOutcomes returns additional transition
                            brittm Novice

                            Ronald, for what it's worth, I completely agree with you.

                            First, there should be no reserved words or special words for transition names. This is just a 'feature' that I don't really need but would have to always think about anyway.

                            Second, in 95% of the use cases, it doesn't make sense to not explicitly provide a transition name on every transition, and in the 5% of the cases where not providing a name might be considered useful, it's just too easy to go ahead and provide one for the sake of consistency. Taking the consistent approach makes coding everything easier.

                            While I don't have any issues with taking the first (default) transition if no name is specified, any further 'special' behavior just complicates my life with additional rules that I don't really need and wouldn't expect.

                            • 13. Re: GetOutcomes returns additional transition
                              Ronald van Kuijk Master

                               

                              "brittm" wrote:
                              Ronald, for what it's worth


                              Your opinion? Al lot ;-)

                              1 2 Previous Next