I am able to manually delete the processInstance from the Camunda cockpit and I failed to delete from the java code by invoking
Above is my bpmn, there is an running activity instance on “Catch event” and I tried to cancel the processInstance which contains this sub-process via Cockpit which works. And I would like to programmatically cancel this running instance and I can confirm that the instanceId I passed in is correct.
May I get more details about what’s the difference and how I can do this correctly? Thanks
What’s the exception plus stacktrace you get when you attempt it manually?
I didn’t see any exception in the log. And, I also put try/catch there which get nothing.
What is the code that you use to delete the instance? In which context is it executed?
“Call SDNC Adapter VF Module …” has a timer inside which includes the flow above and which will map out the processInstanceId in the execution.
“Check if the timers is closed” is going to get the processInstanceId provided by the first block and to check if the processInstance of “CallSDNC Adapter VF Module” is properly closed or not. If not, it will invoke
“runtimeService.deleteProcessInstance(processInstanceId, “The timer in SDNCAdapter cannot be properly shutdown by the Camunda Engine.”, true, true, true)”
I guess there’s a misunderstanding with respect to Camunda’s transactional behavior. If you delete a process instance from within an active Camunda transaction (i.e. the script task here), the effect will only become comitted when that transaction finishes (i.e. when the next wait state is reached). Can you verify this?
Thanks a lot!. And how can I verify that? Do you wanna me put a Timer after “Check if the timers is closed” to verify this?
And another thing puzzles me is that why cockpit send delete request worked immediately?
Well how long do you think the transaction takes? For example, if it takes one minute, then you can verify this by getting the process to that point, waiting for around one minute and then you will see that the process instance has disappeared (if it could be deleted successfully).
In this case you have a transaction that does exactly one thing: deleting the process instance. So when that is done, the transaction is committed and the effects become visible. You don’t have to wait for the rest of the process execution to reach a wait state as in the other case.
Thanks for the guid and actually I get more sense of using Camunda now.
I put a timer B after that and actually this time, the running activity instance is stuck in the timer B. Is that mean something happened after that and engine did the rollback automatically? And I just realized that after the timer, one of the script box is going to create new Java Process which might cause the issue.
So in order to mock what cockpit does, the solution is that somehow I need to create new BPMN flow of shutting down the process instance and use java code to start that processInstance? Am I correct?