I’m trying to model the following behaviour:
“If a user assigns a task to itself and doesn’t complete it after a certain time, the task is automatically unassigned (or re-created)”.
I thougth that I could model it with a variable “task_assignement_status” with possible values “assigned”, “unassigned”, “(assignation) expired”, and conditional events. Something like this:
The variable is initialized inside the start execution listener with value “unassigned”, then changed to “assigned” (or again to “unassigned”) inside the assingnment task listener. And it is also set to “expired” inside the timer end listener.
The problem is that the variable changes that are done inside the assignement listener aren’t triggering any conditional event. I don’t know if this is expected behaviour, me doing something wrong, or a bug. Nevertheless, if I do the variable change manually using Cockpit I see the conditional events being triggered.
Also, I would like to ask if there is a better or easier solution to model this. For the moment as a workaround I’m just using a boundary interrupting timer that goes back to the task, and that is initialized with a very long time period (ideally I wouldn’t need a timer if the task is not assigned), then changed dinamically to a shorter time when the task is assigned (inside the asignement listener) using Java delegation code (and changed back to the long time period if it is unassigned again).
An alternative could be to model the reassignment as a separate process, like this:
Whenever a user is assigned, you start a new process instance referencing the process instance with the user task. In Reassign, you reassign the task via TaskService API if it still exists. If the task is completed or reassigned in the meantime, you delete this process instance.
That way, you do not have this behavior as part of the process model, which can be nice if you want to apply this pattern to a lot of user tasks.
The conditional boundary event should trigger after the variable is created/changed inside the assignement listener, and after the process terminated. The problem is that the conditional event is never triggered.
I have also verified that if I create the variable inside the init execution listener, this works as I expected and the process is terminated.
/* Licensed under the Apache License, Version 2.0 (the “License”);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an “AS IS” BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
package org.camunda.bpm.unittest;
public class TestConditionalEventInAssignmentListener {
@Rule
public ProcessEngineRule rule = new ProcessEngineRule();
@Test @Deployment(resources = {“testProcess.bpmn”})
public void shouldExecuteProcess() {
// Given we create a new process instance
ProcessInstance processInstance = runtimeService().startProcessInstanceByKey(“testProcess”);
// The task is created and the assignment listener called This is because we have an Assignee
// in the .bpmn file.
assertThat(task(processInstance)).isAssignedTo(“User1”);
assertThat(processInstance).hasVariables(“assigned”);
// Process should be terminated
assertThat(processInstance).isEnded();
}
I’m sorry I don’t have the time to look into this further. As an enterprise customer you can raise a support ticket and ask for both a bug fix and a workaround. We describe how to do that here: Camunda Enterprise Support Guide | docs.camunda.org
