1 2 Previous Next 24 Replies Latest reply on Mar 11, 2009 5:32 AM by kukeltje

    Cancelling a task fires task-end event

    kukeltje

      I know there is no task-cancel event, but having a task-end event on cancelling a task does not feel right.

      Any thought?

        • 1. Re: Cancelling a task fires task-end event
          tom.baeyens

          it is almost impossible to come up with a task lifecycle that satisfies all use cases. typically companies have their own view upon the task lifecycle.

          probably the generation of the task-end event is that cancellation also has to end the task. as usually cancallation of the task should not cancel the whole process instance. which exact events need to be fired when is certainly that we can have a debate about for jbpm 4. jbpm 3 should be kept stable.

          in jbpm 4, the task lifecycle is pluggable. it's a PVM process itself. (embeddable execution mode). so we should come up with the most general purpose task lifecycle that users then easily can tweak to their purposes.

          • 2. Re: Cancelling a task fires task-end event
            kukeltje

             

            it is almost impossible to come up with a task lifecycle that satisfies all use cases. typically companies have their own view upon the task lifecycle.


            Sure, but therefore we should at least support the task-cancel event. I in fact have a real nice use case. For the blog I'm writing an article on 'escalation' of task with lots of info declared in the process definition (that is where it belongs).
            The escalation tasks are not any where in the graph, they are separate nodes since they can be called from everywhere. Someone just has to act on it (e.g. changing the priority of the task that is overdue) but I do want this task (the one that is overdue) to just stay where it is. The task that is created this way, e.g. for the manager, is what I call ad-hoc tasks.

            Since I cannot act on a transition (there are no outgoing transitions), not on a node leave (the token always stays in the node, it is just ended), I can only run some code on a task-end. In this task-end, I declare that the priority of the task that is overdue should change to a fixed value, or a value set in the task-form. The task-node looks like this:

            <task-node name='task escalated'>
             <task name='escalated task 0' swimlane='escalationSwimlane'
             signalling='false'>
             <!--
             If task has no outgoing transitions,
             signalling gives an error IF
             the task is signalling
             -->
             <controller>
             <variable name='newPriority' />
             </controller>
             </task>
             <event type='task-end'>
             <action class='net.vankuijk.jbpm.utils.ChangeTaskPriority'>
             <taskNodeName>task</taskNodeName>
             <!--
             if the value of priority can be parsed as an int,
             it is used that way,
             otherwise it is tried as a process variable
             -->
             <priority>newPriority</priority>
             </action>
             </event>
            </task-node>
            


            But if the task that is overdue is carried out befiore the priority changes, it should be cancelled. That is easy BUT..... the task-end event fires and with the use of a variable priority I can do some checks on the value of the variable, but with a fixed value I cannot differentiate between an end (manager did something) and a cancel...

            • 3. Re: Cancelling a task fires task-end event
              kukeltje

              oh.. and besides that... the patch is so simple (yes I get to grips with the inner workings of jBPM better and better day by day)

              in TaskInstance.java change

               task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);
              


              to

               if (this.isCancelled) {
               task.fireEvent(Event.EVENTTYPE_TASK_CANCEL, executionContext);
               } else {
               task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);
               }
              


              and add

              public static final String EVENTTYPE_TASK_CANCEL = "task-cancel";


              to Event.java.

              After that ALL tests still run (hmmmm.... ;-)) so there is NO test on a task-cancel event.... I'll file a jira issue since I do think it should be in a release

              Besides that... after analyzing some more code... the end-tasks attribute on the task-node should realy be cancel-tasks (and the corresponding cancel on the tasks instead of end...)

              I'll file a separate jira issue for this.

              • 4. Re: Cancelling a task fires task-end event
                jbarrez

                Ronald,

                It is a difficult topic :p

                I have a use case in which having a cancel event would be great. In that use case is cancelling a task conceptually different from ending a task: ie. a cancelled task is a task which has not been ended (= finished correctly) by someone.

                But, Tom is right: for another customer the story could be different ...

                Perhaps for jBPM4, something drastical should happen to cover this since it will never be good for everybody... perhaps working with inheritance for events, so that you could catch Task-end and Task-cancel but also Task-finished (parent of end and cancel) event that is a catch-all if it doens't matter ... ?

                • 5. Re: Cancelling a task fires task-end event
                  tom.baeyens

                   

                  "jbarrez" wrote:
                  Perhaps for jBPM4, something drastical should happen to cover this since it will never be good for everybody... perhaps working with inheritance for events, so that you could catch Task-end and Task-cancel but also Task-finished (parent of end and cancel) event that is a catch-all if it doens't matter ... ?


                  That is what I was trying to indicate:

                  In jBPM 4, the task lifecycle will be expresssed in a resource file that can be customized by the user. The different states a task can be in and the events that are fired are then specified in that configuration file.

                  • 6. Re: Cancelling a task fires task-end event
                    kukeltje

                     

                    "jbarrez" wrote:

                    It is a difficult topic :p


                    I tend to disagree, see below

                    "jbarrez" wrote:

                    I have a use case in which having a cancel event would be great. In that use case is cancelling a task conceptually different from ending a task: ie. a cancelled task is a task which has not been ended (= finished correctly) by someone.

                    But, Tom is right: for another customer the story could be different ...


                    If they are the same for this user, They will just use one or the other (most likely end() ). But for others, they can put any logic they want on 2 'event-handlers' so..

                    "jbarrez" wrote:

                    Perhaps for jBPM4, something drastical should happen to cover this since it will never be good for everybody... perhaps working with inheritance for events, so that you could catch Task-end and Task-cancel but also Task-finished (parent of end and cancel) event that is a catch-all if it doens't matter ... ?


                    Could be, but that makes it more difficult to implement. You can get that functionality by declaring 2 event-handlers as mentioned above.... I would not make it overly complicate. But if kind of hierarchical events are introduced, that would be fine to. In that case we agree and is it less complex/difficult than we thought.

                    • 7. Re: Cancelling a task fires task-end event
                      kukeltje

                       

                      "Tom B" wrote:

                      In jBPM 4, the task lifecycle will be expresssed in a resource file that can be customized by the user. The different states a task can be in
                      and the events that are fired are then specified in that configuration file.


                      And we do provide a fully functional jbpm 3 compatable default I hope?

                      Otoh, I've not heard people complaining about taskmanagement regarding the 'states' of task management do you guys? Questions were more about declaring vars, typing them, giving default values etc

                      • 8. Re: Cancelling a task fires task-end event
                        tom.baeyens

                         

                        "kukeltje" wrote:
                        Questions were more about declaring vars, typing them, giving default values etc


                        Those should be addressed as well in jBPM 4. Let's make sure we address this in the jbpm team meeting.

                        • 9. Re: Cancelling a task fires task-end event
                          jbarrez

                          Ronald,

                          If you are using this construction:

                           if (this.isCancelled) {
                           task.fireEvent(Event.EVENTTYPE_TASK_CANCEL, executionContext);
                           } else {
                           task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);
                           }
                          


                          Then you are missing the TASK_END event if the task is cancelled. People for who see 'finishing a task ' (ie. cancelling or completing) as the end of a task (which is conceptually also correct) and now simply use an event handler for the TASK_END event are obliged to use 2 event handlers now.

                          So it comes down to a matter of conceptual view:
                          - Ending a task == the task is finished (removed by cancelling or successfully completed)
                          - Ending a task == completing the task successfully, BUT cancelling means here that the task did not end but simply dissapeared for some reason.

                          I have implemented both use cases in the past, so this is not some academic example. What we need here is a solid and clear definition ...


                          Otoh, I've not heard people complaining about taskmanagement regarding the 'states' of task management do you guys? Questions were more about declaring vars, typing them, giving default values etc


                          That's true ... but I did have a use case in which the states of a task were THE most import thing: cancelled, suspended, ended, assigned but not taken, working on it, etc. all those states were possible for a task. So you can imagine I would have been very happy at that moment if I had some more options ... we had to juggle a bit with task variables to get it all done.

                          • 10. Re: Cancelling a task fires task-end event
                            heiko.braun

                             

                            Let's make sure we address this in the jbpm team meeting.


                            Sorry to intervene at this point, especially when it doesn't relate to this thread.
                            But the team meeting should stay focused. Don't throw in stuff that can easily be discussed in the forums. IMO we need to make sure that conceptual things (bare bone) that relate to the API sand CTS have foremost priority when we meet. At least we should try to draw a line between implementation detail and concepts and leave the details to the person implementing it.

                            Something else:

                            If you come up with things that need to be considered, discussed or reviewed then raise an issue (JIRA) right away. Otherwise it get's easily lost.



                            • 11. Re: Cancelling a task fires task-end event
                              jbarrez

                              (sorry to intervene too ;-)

                              Heiko,

                              IMO is this API stuff. Human tasks are the most used concept of jBPM (in my experience).

                              This needs be discussed properly before being implemented by a single person or you would get situations like this thread where someone needs a cancel-event and it does not exist altough conceptually there are some use cases.

                              • 12. Re: Cancelling a task fires task-end event
                                kukeltje

                                 

                                Then you are missing the TASK_END event if the task is cancelled. People for who see 'finishing a task ' (ie. cancelling or completing) as the end of a task (which is conceptually also correct) and now simply use an event handler for the TASK_END event are obliged to use 2 event handlers now.


                                I know, but it should not limit us (and it should not be neccesarilly be in 3.3 (I created my own local patch), or we can even do something like

                                 if (this.isCancelled {
                                 task.fireEvent(Event.EVENTTYPE_TASK_CANCEL, executionContext);
                                 task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);
                                 } else {
                                 task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);
                                 }
                                


                                or even

                                 if (this.isCancelled && jbpm.properties.Task-cancel-event-backwards-compatibility != true) {
                                 task.fireEvent(Event.EVENTTYPE_TASK_CANCEL, executionContext);
                                 } else {
                                 task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);
                                 }
                                


                                and make that property by default true.... but that is probably what Tom want's in the task specific config file...

                                Still.... I get the feeling that extending the 'task handling process' a little is not wrong, but making it really configurable is imo well.. not realy a waste of time, but certainly not high priority... what we have is not that wrong. Putting two eventhandlers on a definition is supported *now*, making it configurable takes a lot of time

                                but I did have a use case in which the states of a task were THE most import thing: cancelled, suspended, ended, assigned but not taken, working on it, etc. all those states were possible for a task. So you can imagine I would have been very happy at that moment if I had some more options ... we had to juggle a bit with task variables to get it all done.

                                Hmm... I did something similar once in a p.o.c. but did not use/need any variables. Maybe because we took another angle on it, but I could deduce all from the methods on the task. Otoh, we did not have to query for them, the number of tasks we that limited that we could use the default tasklist query and filter afterwards.


                                • 13. Re: Cancelling a task fires task-end event
                                  jbarrez

                                  (Hijacking the thread again :p)

                                  Hmm... I did something similar once in a p.o.c. but did not use/need any variables. Maybe because we took another angle on it, but I could deduce all from the methods on the task. Otoh, we did not have to query for them, the number of tasks we that limited that we could use the default tasklist query and filter afterwards.


                                  Ronald, is it possible to make a blog post about it or was it for a customer? I'm interested in seeing your approach ... perhaps we can exchange our ideas?

                                  eg. we had to create a special actorId 'parser' by using a 'role:assigned_to' string: if the assigned_to it meant that no-one was working on it, else the task is visible to anyone of the role.

                                  • 14. Re: Cancelling a task fires task-end event
                                    kukeltje

                                     

                                    "jbarrez" wrote:

                                    IMO is this API stuff. Human tasks are the most used concept of jBPM (in my experience).

                                    Yep

                                    "jbarrez" wrote:

                                    This needs be discussed properly before being implemented by a single person or you would get situations like this thread where someone needs a cancel-event and it does not exist altough conceptually there are some use cases.


                                    forget the first example though in my previous post... does not solve my own problem. since I do not need the cancel-event (I was put on the wrong foot by Jorams reply), but do not want an end-event on cancel... conceptually different and as Joram states correctly more then implementation.

                                    1 2 Previous Next