Hello, I’m not sure if this is possible in Camunda. My question is, can you configure Camunda in a way that allows canceling certain tasks, and when canceled, prevent the use of other activities, essentially stopping the process? Can cancellation regions be implemented in Camunda without programming? Thank you very much.
Do you want to explain better what you need or what you imagine so that we can try to help you find the best solution?
If you want to exemplify through a process modeling, even better.
William Robert Alves
What I want to do is somehow set it up so that when this activity called ‘cancel’ is triggered, the other tasks are not completed. Imagine that the other nodes and tasks disappear. I have not found something similar in BPMN books or in the Camunda documentation, which might not be supported or perhaps not found in another workflow management system.
I want to convey that, in essence, you have an “and split” where, in one path, all the process activities are located, and in the other path, there’s the “cancel” task. The issue with the “and split” is that all tokens should go down one path, and in another workflow management system, you can configure it so that when you’ve completed the upper path, the “cancel” task essentially disappears, indicating that only one token, instead of two tokens, enters the “and merge.”
I don’t know if I understand correctly, but from what I understand, you could create your process and wrap it in an expanded subprocess, and put a “message boundary event” that will receive a message correlation when cancellation is requested for this instance.
Then, upon receiving this correlation, your instance will leave its expanded subprocess, and will go to a task that will actually do the cancellation, calling some API that does the deletion in the database or something similar.
Something like this on below:
William Robert Alves
1 Like
I understand that when you have a message event, you need to write program code. Is there an alternative way to do it without writing any code?
I’m not sure if “conditional event” is already supported in Camunda 8, but if so, you can use it.
Wrap your entire process in an expanded subprocess, and put a “Conditional boundary event” evaluating some variable that you determine will be your “cancellation trigger”, when this variable is set to “true”, your conditional event will remove the your instance of this expanded subprocess, and will guide you to another path as you define.
But in all cases it will involve some code, at least FEEL expressions or something like that.
William Robert Alves
I looked it up and it said, that “conditional event” is not supported in Camunda 8.2.
So the best way I believe is using message events. But with a quick look at Camunda’s documentation you should be able to use it without any problems. And from the moment you understand and manage to do it, a world of possibilities opens up before you hehehehe.
William Robert Alves
The message event is powerful… I suggest you take a look at Camunda’s official doc about this element, and try to start with using some simple codes, this will allow you to get the most out of Camunda’s power!
William Robert Alves
Thank you, unfortunately, my English skills are not that good, and as a beginner using Camunda, I have trouble understanding it. When I read the documentation back then, I didn’t understand how to implement it. My alternative solution is that the user can decide with the help of a checkbox whether they want to cancel or not. If yes, the XOR checks whether the user wants to cancel or not.
I understand u bro!
Anyway, since you want to avoid coding and would like to use a user task to validate this…
I have an “ugly” but functional alternative for this.
At the beginning of your process put a parallel gateway and in path A, all the tasks of your default process.
In path B, place the user task with the form to mark the cancellation.
After this user task, put the XOR Gateway to check if the answer is “Cancel”, if so, the instance must proceed to a TERMINATE EVENT that will kill the instance of that scope of your process.
Remembering that this is an ugly alternative to use, but it works.
William Robert Alves
Can you show me a little process modell so that i can understand it better?
Of course, I can show it!
I only ask that you wait a little, as I am currently answering on my cell phone, due to the lack of electricity at my house due to the strong storm that occurred last night.
As soon as the electrical energy (power) returns, I would be modeling the process and sending you here through the topic.
William Robert Alves
1 Like
Thank you. Oh, hopefully everything will get better for you.
1 Like
Hello my bro!
Finally the power has returned!
As I explained earlier, this modeling I did here is pretty ugly, but it would work to stop the process immediately without the need for code.
When the FORM is marked with “Cancel”, the XOR gateway will validate that it is to cancel and will take the cancellation token to the TERMINATE EVENT path, which will kill the main instance of your process as well.
Do something like this:
The “continue” in this case is only for when the main instance finishes the process, you can also finish the instance of the parallel path correctly.
I hope this helps!
William Robert Alves
1 Like
Thank you. I understand the process. Let’s say I am task 5. My idea is that the process stops immediately, but there is an “and split,” and the cancel task form is still available even though we have completed task 5. I wanted to ask if it’s possible to configure it so that the cancel task is no longer available after task 5 is finished. Thank you for your help. You’re helping me a lot.
This is really poor design, but would do what you’re talking about.
But really… I would suggest that you allow yourself to be open to using workers, as that will allow you do a LOT more.
On each form, you would need to have a Checkbox or Yes/No drop-down to allow the setting of “Cancel” as a process variable.
I had also done it like with the checkbox. I found the upper part with the ‘and Split’ very nice. However, I wanted a method where if you go to task 5, the process should be terminated, and you can no longer perform the ‘cancel task.’
In the flow above, when you reach Task 5, you don’t put the “Cancel Process” on the form… it isn’t evaluated anyway, so it’s not possible to cancel after Task 4.
This is a bad design, and I would not recommend that it actually be used… but it also removes the task “Cancel Process” which could be completed even while someone is in the middle of doing Task 4 (at which point they would get an error message)