nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Proposal: RuntimeService.terminateProcessInstance(String id)

falko_menge

We at camunda would like to provide a method, which terminates a given process instance, in the runtime service.
The method will essentially call ExecutionEntity.end().

Do you have any concerns with that or can we just provide an implementation for you to review?

Find more posts tagged with

Comments

trademak

Hi Falko,

I think it would be nice to see that the process instance has ended with a terminate.
Do you plan to support that as well?

Best regards,

falko_menge

Hi Tijs,

I think it would be nice to see that the process instance has ended with a terminate.
Do you plan to support that as well?

It's not yet planned, but I like the idea. I'll have a look at it and see how much effort it is.

Cheers,
Falko

tombaeyens

Go ahead. Looks like a good addition.
The deleteReason property should be used to indicate why the execution has been ended.
I think that should be a mandatory parameter in the method that we expose to users. Maybe we could offer some constants or convenience methods

void endProcessInstance(String processInstanceId, String deleteReason);
void endProcessInstanceTerminate(String processInstanceId); // uses TERMINATED constant as the delete reason
void endProcessInstanceCancel(String processInstanceId); // uses CANCELLED constant as the delete reason

The trick is to test and document the implications properly. What happens if you end a sub process that is bound to a super process etc. It should also be clearly documented. If we add it to the API, people will start trying and using it. Will users have to be carefull with it? Or is it robust and will there not be any forseeable surprises. All that needs to be explicitely indicated in the javadoc.

Also indicate the purpose of the delete reason: namely refer to the history logs. The delete reason was added to exclude certain types of abnormally ended processes from the business intelligence analysis queries.

meyerd

First I had a look at runtimeService.deleteProcessInstance(…). Is there a reason for not having a DELETE_REASON_ column in the history process instances table. Or was it simply forgotten?

On the broader topic:
I think that ending a process Instance through ExecutionEntity.end() is not a good idea:
a) I am pretty sure it fails if the process instance has sub processes instances (foreign key constraints not met). Or do you want to end those too, with the same semantics? Will get very messy and very hacky.
b) will continue the execution in the super process which is pretty unrealistic because in most cases, if I terminate a sub process abnormally the super process will not be able to continue normally.

So I am more in favor of using delete is such situations because there the semantics are clear.
In addition, the atomic operation AtomicOperationDeleteCascadeFireActivityEnd which is not used at the moment could be interesting as it would set an end_act_id_ (if I am not mistaken).

meyerd

The point is: this is not the termination end event.

If I put the termination end event in a process, I decide at modelling time that I am OK with the semantics and that my process (hierarchy) can handle it. (I.e super process instance continues, even if the sub process instance is terminated "abnormally")

If we offer the semantics of the termination end event as an api-level method for ALL processes i.e. even those that cannot handle it properly, it will be a great source of "WTF", as most of the time calling the method will throw an exception.