I’m pretty new to Camunda. I currently working on POC using camunda. For that POC I need to display all the tasks that should appear in the workflow. I now try to refer the workflow to a previous task in the workflow. I’m using the REST API process-instance/processId/modification. When I call the API the current task is deleted and the token is moved to the targeted task earlier in the process. However the tasks in between the deleted task and the new starting point are still in a completed mode.
Is there any way to delete the task that have been completed between the task canceled and the new starting point?
Just to be more explicit please find below a schema:
Task 1 => Task 2 => Task 3 => Task 4 => Task 5
Task 1-2-3-4 are completed
Task 5 in progress
I call the modification API to cancel 5 and startBefore 1. The new status is the following:
Task 1 → In Progress
Task 2-3-4 → Completed
Task 5 → Not Started
I would like to have Task 2-3-4 deleted as well.
Feel free to get back to me if you have any question.
I use the REST API /history/process-instance to get the status of my task. In the history of the Task 5 of my exemple I can see that the task deleteReason is set to deleted however the task 2 - 3 - 4, the deleteReason is still completed. I would have expected to see these tasks as deleted as well as they will be trigger even when task 1 will be completed.
Camunda stores it’s data in 2 sets of tables Runtime and History - you can read more about it in the docs.
The Runtime database contains only currently active tasks so would not return any finished tasks. You would query it with the Get Task API. The API you’re using is reaching the history tables so it would return the current state as well as all previous steps.
So basically… don’t use the history API if you don’t want to see completed tasks.
I use the Task API as well to get the status of the in progress tasks. However when I combined the two views (after the call of the modification API) to display the status of all tasks I see the Task 1in the Task API as I was expecting but in the history table the other tasks (2 to 4) are still with the status completed even if the current in progress task is Task 1. That is a bit misleading as the status for all tasks are the following:
Task 1 -> In progress
Task 2 -> Completed
Task 3 -> Completed
Task 4 -> Completed
Task 5 -> Deleted
I would like to show that tasks Task 2 -3 -4 has been deleted as well for clarity as the user will have to go through task 2 - 3 - 4 to trigger Task 5.
You might be misunderstanding the use case for the modification API.
It’s not a “rollback” just because you move the token from task 5 to task 1 it doesn’t change the fact the tasks 2->4 have happened.
I don’t want to delete the history it is key to keep an accurate audit log. However I would like to include a new instance of the ‘rolled back’ tasks with a deleteReason: deleted in the history in order to be able to track the fact that these tasks have been ‘rolled back’. Because if I use the current mechanism I will see in the history that the task has been completed twice without been able to see that the second completion is due to a “rollback”.
I think if you used context of the Audit log itself - and order it by the timestamp - it would show the order of events and so would be very clear to see that the task is being executed a second time because the modification had taken place.
But basically i can’t think of any way in which you could achieve what you want without deleting the records from the history table.
Thanks Niall, I will do that but I was wondering if there was an official way to “rollback” a process.
However, just a quick question, how I can find in the history that the modification has been done? At the moment I using the /history/process-instance API and I see only tasks history nothing about the modification that happens.