nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

User task, ExecutionId and Timer Boundary Event

jackw

When the Timer Boundary Event is attached to the User Task, this task is created with executionId of "subprocess".
This suprocess probably handles branche of attached timer. But I think the user task should belongs (executionId) to main process instead of subprocess.

I have scenario with user task with recurrent mail notification. I use cancelActivity="false" since I want to user task remain after trigger fires and sends email (it is only notification).

Is this correct behaviour? Why?

Find more posts tagged with

Comments

jackw

I try to be more specific.

Process:

<br> <process id="Proces1" name="proces1"><br>&nbsp;&nbsp;&nbsp; <startEvent id="startevent1" name="Start"></startEvent><br>&nbsp;&nbsp;&nbsp; <userTask id="usertask1" name="User Form" activiti:assignee="none" activiti:formKey="FORM"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <documentation>User form</documentation><br>&nbsp;&nbsp;&nbsp; </userTask><br>&nbsp;&nbsp;&nbsp; <endEvent id="endevent1" name="End"></endEvent><br>&nbsp;&nbsp;&nbsp; <boundaryEvent id="boundarytimer1" name="Timer" cancelActivity="true" attachedToRef="usertask1"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <timerEventDefinition><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <timeDuration>PT1H</timeDuration><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </timerEventDefinition><br>&nbsp;&nbsp;&nbsp; </boundaryEvent><br>&nbsp;&nbsp;&nbsp; <serviceTask id="servicetask1" name="Mail Notification" activiti:expression="${mailto}"></serviceTask><br>&nbsp;&nbsp;&nbsp; <endEvent id="endevent2" name="End"></endEvent><br>&nbsp;&nbsp;&nbsp; <sequenceFlow id="flow1" name="" sourceRef="startevent1" targetRef="usertask1"></sequenceFlow><br>&nbsp;&nbsp;&nbsp; <sequenceFlow id="flow2" name="" sourceRef="usertask1" targetRef="endevent1"></sequenceFlow><br>&nbsp;&nbsp;&nbsp; <sequenceFlow id="flow3" name="" sourceRef="servicetask1" targetRef="endevent2"></sequenceFlow><br>&nbsp;&nbsp;&nbsp; <sequenceFlow id="flow4" name="" sourceRef="boundarytimer1" targetRef="servicetask1"></sequenceFlow><br>&nbsp; </process><br>

Test:

<br>public void testExecutionIdWithBoundaryEvent() {<br> runtimeService.startProcessInstanceByKey("Proces1");<br> List<Execution> list = runtimeService.createExecutionQuery().list();<br> Execution mainExecution = list.get(0);<br> Execution boundaryExecution = list.get(1);<br> // Why user task is created under boundaryExecution.id<br> // assertNotNull(taskService.createTaskQuery()<br> //&nbsp; .executionId(mainExecution.getId()).singleResult());<br> assertNotNull(taskService.createTaskQuery()<br>&nbsp;&nbsp; .executionId(boundaryExecution.getId()).singleResult());<br>}<br>

jackw

Sorry, It should be cancelActivity="false" in a process definition.

frederikherema1

Does this mean your problem is solved?

The seperate execution on the task with a boundry timer on it is indeed the correct behaviour, this is the way activiti handles this.

jackw

Sorry, still not clear. Yes I understand that there is new separate execution under the boundary event, but usertask1 should belongs to the main execution logically. Since cancelActivity="false" means "not remove main execution".
But in database, usertask1 is created as it belongs to boundary execution.

The problem is that it is not possible to render active task for executionId.
Of course, You can use processInstanceId, but it is still quite messy for me.

frederikherema1

It actually is "logically" part of the execution, using a child-execution

But I get the issue, since it's not trivial to find the user-task on the execution.

As I said, this extra execution is added for internal reasons (creating a scope, to prevent concurrency problems when timer fires and task is completed etc). So it's not likely this will disappear.

Maybe it would make sense to introduce a method on the TaskQuery like executionIdOrParentExecutionId(execution.getId()) to overcome this issue or even a query that gives all tasks that are part of ANY execution that is a child of (or the parent itself) the execution with the given Id (not only first level child). Just thinking out loud, but in this usecase it will definitely make sense….

jackw

Ok, Thank you. With concurrency it makes sense.

As I wrote, it is possible to use processInstanceId, but imho it is overhead to remember two IDs (executionId, processInstanceId) to query userTasks in one database hit. So such extension you mention above would be handy.
Maybe also for reducing database traffic.