We’re trying to model user tasks which are executable by users, but whose lifecycle depends on the data, entered by said users. An example would illustrate this more easily:
Say an item is created and it has X and doesn’t have Y in its data. We’d create one user task for collecting Y and it would pop up in the task list of whoever is interested. Now a user modifies the item and an event is raised that ends up in Camunda. We would want to re-trigger the appropriate gateways and if “Y is present in the item”, close the “Collect Y” task, but if not - keep it. Same applies for the other way around - if X was there initially, no task would be created. Then the item is modified and X is no longer present, we’d like to open a user task for it.
Ideally, this could be modified in a reusable way, but that’s not mandatory. Any pointers to concepts that might help would be appreciated. So far the event sub-process looks promising, but it’s not clear how it could re-trigger something from its surrounding (sub-)process.
So you are trying to model a never ending process? Or what is the end of the process?
You could loop back after the sub process and wait till the item is changed again. item-example1.bpmn (11.3 KB)
You could also use the event subprocess and include the same logic from the main process item-example2.bpmn (12.0 KB) . This is not ideal and looks like a duplicate. Would it not be possible to end the process and start the same one again when an item is changed?
Thanks for the response. Yes, we’re modelling a process that can be worked on in a long period of time. At some point there is an end, which we modelled with an event. I took some time to experiment with the ideas that you suggested. Here’s a process that should work, but has some issues:
The main issue is that once an event is received, tasks in the subprocesses are deleted and recreated, even if the state ultimately remains the same. So my main question is what recommendation would you give for “data-driven” tasks, whose resolving depends on data in the context/events. Is the user task even a proper building block to be used?
As a workaround, a colleague of mine pokes around with the history/events API, in hope that we can treat delete + create of the same task as a whole (basically an update). However, with this modelling sometimes a delete of a task is semantically equivalent to that task being resolved (in case the data in the ItemModified leads to a different path in the gateway), and sometimes - it’s a regular delete. Could you or others shed some light onto the topic?
The message end event is set up to call a Java delegate and is manually passed the name of the “Collect Y” task. The delegate then finds the task (by execution id and name) and marks it as completed. This works but has the following disadvantages:
The “X present in item” logic is duplicated
Every message end event in such cases would have to be manually set up to finish some task/tasks
Ideally both of these would be handled using just standard modelling. However, the duplication seems to be the bigger issue, as the task completion delegate can set up and be reused from all end events.
We managed to remove the duplication of logic in the two gateways, by using scripting (in an external file). However, closing the task manually in the Java delegate is still there.
Could anyone give some insight on the topic? Both of the problems described in the posts above seem to be averted, but by using methods akin to “workarounds”. Moreover, both the external scripting and the java delegate with input parameters are Camunda-specific extensions. I’m wondering whether there is a standard-compliant solution for finishing tasks using data-driven events, and not by manual completion.
