The 7.12 webinar demo (see Examples of 7.12 webinar) showed a “force assign” feature that leverages the new timeout listener for user tasks.
However, the opposite (force unassign) is the more important use case … a user starts working on a task, interrupts his work and we have to free the tasks so team mates can take over.+
Currently we are solving this via custom command handlers that execute a timed job which is created on task assign … or run a cleanup job that searches the operation log for claim timestamps of tasks that are not yet completed … both not very elegant ways … I was hoping that the timeout listener could be an option here, but it seems that it just starts running the clock when the task is created and also runs only once.
Is it possible to couple the timeout with previous events (start running after claim)?
If not: what are use cases you had in mind? Given that the task can be created during the night, I am lacking phantasy to understand how a strict duration based timeout would support any relevant use case. Maybe you could give some examples?
No, that is not directly possible. We did consider building the feature like that but opted for a simpler solution that would be easier and more transparent to understand for most people. E.g. consider if a task is claimed/assigned multiple times in a row, then you get potentially many time out listener jobs which is not transparent to the end user triggering this.
Here are a couple of ideas how you can use the listeners in a more dynamic way:
- The timer definition supports exactly the same things that we support for non-interrupting boundary events, so the timer can trigger more than once. E.g.
R/PT5M will run the listener every five minutes
- The timer definition supports expressions, so you can adjust due dates to any kind of business hours
ManagementService#setJobDuedate you can change when a job triggers after it has been created
- Task-local variables can be used to keep context between invocations of an assignment and a timeout listener
I hope these things help you implementing what you want to achieve.
Guess we could create a background batch job that looks for user tasks that are stale and should be “unassigned”
See my original posting … it’s not that we do not have a solution for the auto-unassign, several way to do this … it was just that when I read “new feature: task timeout” I thought: wow, no custom jobs, no hacking, plain camunda feature … which it clearly is not …
Hi Thorben, thanks for the reply …
I understand what’s not possible, and I also understand how I can choose between clever and mybe-not-so-clever solutions to achieve the “unassign after timeout” feature.
But what I still don’t understand:
Since “force unassign” clearly is not a use case for the “task timeout” feature … what is. I mean, camunda did quite a big change here, including engine runtime, API and modeler adjustments …
You must have seen some business value in this change. There must be some really important "As a … I want to … " stories.
Do not get me wrong: great job, great release … but normally, when you present a new feature, I go “wow, cool, I suppose I can use this to do …” or at least “finally! now I can remove my hack” … but with this, I am just like “why would I ever need this?”. And I still believe that if you tell me the “why” I will go: “ah, now I get it … cool”
Please excuse my late reply as I was on holiday.
The use case of the customer that requested this feature was similar to what you describe: Unclaiming a task after a certain duration, e.g. if the worker is sick on the next working day. For the customer the proposed solution was fine and as it appeared to us to be a good trade-off between power of the feature, consistency with other features and ease of understanding, we implemented it that way. However, I have no information as to how they are implementing their use case in particular now that the feature is available.
When I saw this, I instantly had a use in mind:
In an upcoming project we have several processes with various different user tasks, that share similar time related rules. For example, a reminder or an escalation after a certain time. While this can be modelled technically in BPMN with Events the result would be quite an overloaded BPMN flow and reduced readability for our business.
So for us it could be quite a cool way to hide something from the BPMN that is not relevant for understanding the core business logic and still keeping it within camunda.