I use Camunda Platform 7. I have a camunda sub process which can terminate normally (approved) or not (refused). A user task determines if the approval task is approved or refused. I tried to use a signal to leave the sub process in case the user task is refused but this triggers ALL active processes. If I have two active tasks waiting at the approval task, ALL are cancelled, which I don’t want.
So I tried to use an Error end event to handle the refused gateway with a boundary event but I think there is a problem with camunda itself ? I get a NullPointerException on the subprocess as soon as I use Error event event instead of the signal :
public FlowElement getBpmnModelElementInstance() {
BpmnModelInstance bpmnModelInstance = getBpmnModelInstance();
if (bpmnModelInstance != null) {
ModelElementInstance modelElementInstance = null;
if (ExecutionListener.EVENTNAME_TAKE.equals(eventName)) {
modelElementInstance = bpmnModelInstance.getModelElementById(transition.getId());
} else {
//activityId on next line is wrongly "subProcess#multiInstanceBody" instead of "subProcess" so it returns null
modelElementInstance = bpmnModelInstance.getModelElementById(activityId);
}
So is there something I missed ? Should I not use Error end event but something other instead ? What solution do I have to exit my subprocess in case of refusal which is another exit of the subprocess than the approval one.
Hi @Jonas_Kistler and welcome to the forum,
the BPMN [p. 440] standard states:
For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled)
If you use a signal, all subprocess instances of process instances will be cancelled. If you use an error event, all subprocess instances of one process instance are cancelled.
You have different options:
- Using a non-interruptive boundary event (i.e., escalation)
- Using an event-subprocess
- Including the handling of refused requests within your
Approaval subprocess
Hello and thanks for your answer.
My subprocess is a multi-instance sequential one so stopping all the instances when the refused is triggered is exactly what I want. If I understand your answer correctly, I should be able to achieve this with an error event, which stops all instances of my subprocess for the CURRENT workflow instance.
The problem is that when I change my signal to an error event, I get the NullPointerException I wrote in my original post. How can I fix this ? When I breakpoint at this line for a signal for example, the activityId is the name of my subprocess, but when I do this with an error event, the activityId is "subProcess#multiInstanceBody" and so the getModelElementById returns null because the name of the subProcess does not have "#multiInstanceBody"
Can you provide the stack trace of the null-pointer exception and the BPMN file of your model?
Yes I attach my bpmn file which is a bit large (the approval subprocess part is the one I tried to change to an error end event)
This is the stacktrace :
java.lang.NullPointerException: null
at org.camunda.bpm.extension.reactor.bus.SelectorBuilder.extractTypeName(SelectorBuilder.java:189) ~[camunda-bpm-reactor-core-2.1.2.jar:2.1.2]
at org.camunda.bpm.extension.reactor.bus.SelectorBuilder.selector(SelectorBuilder.java:51) ~[camunda-bpm-reactor-core-2.1.2.jar:2.1.2]
at org.camunda.bpm.extension.reactor.bus.CamundaEventBus.notify(CamundaEventBus.java:61) ~[camunda-bpm-reactor-core-2.1.2.jar:2.1.2]
at org.camunda.bpm.extension.reactor.bus.CamundaEventBus.lambda$getExecutionListener$1(CamundaEventBus.java:86) ~[camunda-bpm-reactor-core-2.1.2.jar:2.1.2]
at org.camunda.bpm.engine.impl.core.instance.CoreExecution.invokeListener(CoreExecution.java:101) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:55) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:99) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:131) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:111) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:86) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:76) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:632) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:607) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:62) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:99) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.invokeNext(CommandInvocationContext.java:131) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performNext(CommandInvocationContext.java:111) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:86) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.CommandInvocationContext.performOperation(CommandInvocationContext.java:76) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:632) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.performOperationSync(ExecutionEntity.java:607) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.core.operation.AbstractEventAtomicOperation.execute(AbstractEventAtomicOperation.java:62) ~[camunda-engine-7.17.0.jar:7.17.0]
at org.camunda.bpm.engine.impl.interceptor.AtomicOperationInvocation.execute(AtomicOperationInvocation.java:99) ~[camunda-engine-7.17.0.jar:7.17.0]
When I use signals, the activityId is the correct subprocess name at this line, without the “multiInstanceBody” part which creates the NPE
Which version of Camunda are you running?
I build a minimal example and could not reproduce the error:
minimal_example.bpmn (7.0 KB)
I am using camunda 7.17. I tried to upgrade to 7.18 but got the same error
The error arises from the reactor, which is deprecated. Do you need it? How are you using it? Maybe, there is a workaround.
Yes I just saw that there is my exact problem in the reactor issues : java.lang.NullPointerException: null at org.camunda.bpm.extension.reactor.bus.SelectorBuilder.extractTypeName(SelectorBuilder.java:223) · Issue #57 · camunda-community-hub/camunda-platform-7-reactor · GitHub
So I assume I’ll have to migrate to an alternative which is not deprecated. I’ll try to find a migration tutorial which might help to use spring boot.
Thanks !
1 Like