Job in ACT_RU_JOB not being removed.

[richard1]

Hello all,
   I have an interesting problem with a TaskListener that I added to a UserTask for a CREATE event. I would like for it to check for a variable and if set to true set the DelegateTask to complete. I believe the correct way to do this would be to have an ExclusiveGateway before it and have that determine if the UserTask should be skipped or not. I chose to do it the wrong way since this skipping mechanism is only used by developers as we are testing and playing around and does not need to be visible to business analysts. I was able to do what I wanted to do by casting the DelegateTask passed to the notify method to a TaskEntity. From the TaskEntity I call complete(). This does what I want but I have run into another problem, which I believe was due to me breaking the rules. If I add a BoundaryEvent Timer to that UserTask, bad things happen. The tasks completes as we want but the Job in the ACT_RU_JOB table remains and then tries to fire at the desired time. This fails since the task it was attached to already completed and remains in the ACT_RU_JOB table until I manually remove it. Is this due to me breaking the rules or is it a bug? Is there a better way to do this within the TaskListener?

Thank You

Code Snippet:

  void notify(DelegateTask task) {
    //Casting to TaskEntity which is overkill since I am using Groovy, but there for dramatic effect
    TaskEntity entity = task;

    String mySkip = skip?.getValue(task)?.toString();

    if (mySkip && mySkip.equalsIgnoreCase('true')) {
      //Only update if we are in a CREATE listener
      if (entity.getEventName()?.equals(EVENTNAME_CREATE)) {
        //Bad things happen If there is a timer attached to the task
        entity.complete();
      }
    }
  }
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[frederikherema1]

Hi,

You shouldn't try to complete the task in a taskListener, it's just asking for trouble. Thats also the reason why the timer is still available even when task is finished, due to the fact that the finishing didn't happen the way it should (as normal flow would do)

[richard1]

Yes I agree but other than doing it the right way  and using an ExclusiveGateway to direct the path around the task we want skipped can you think of a less wrong way? We are trying to avoid the visibility of the UserTask skipping to the diagram and business analyst since skipping is not part of the regular workflow, it is used by the developers to test and force certain scenarios. If skipping were part of the actual flow we would do it the right way, we are just trying to be sneaking.

Thanks for your reply.

[frederikherema1]

I can't think of any other way that just completing the task using the API (not from the taskListeners).
Anyone any other thoughts?

[richard1]

After stepping back I saw the forest through the trees. Most of our user tasks are for automated processing so we have processes that act just like a user, grab a task, work it, then give it back. All this done using Spring Integration, so it is less work for us to build one of these processes to grab a task, do nothing, then give it back. This will do what we wanted, do it the right way, and really be a better test.

Thanks for your help, sorry for being stubborn about forcing it to do it the wrong way. 

[frederikherema1]

No problem, have fun using activiti