Any issues with using/accessing Error Events through JavaScript?

Looking to put together a simple post about using Error Events to capture business errors.

The example in this case could be something like a “problem” with a signature (aka the signature is not valid).

Here is a simple example prepped for use with demo user in Camunda:

errorTest1.bpmn (6.8 KB)

The script task has the following JavaScript inline:
var sigValidity = execution.getVariable("SignatureValidity"); if ( sigValidity == true ) { execution.setVariable("SignatureAcceptedTF", true); } else if ( sigValidity == false) { throw new org.camunda.bpm.engine.delegate.BpmnError("SignatureError"); }

Wanted to check to see if anyone sees issues with calling error events this way rather than calling them through delegated java code.
I built this example from one of the tests in Camunda: camunda-bpm-platform/ErrorEventSubProcessTest.testCatchErrorThrownByScriptTaskInTopLevelProcess.bpmn20.xml at master · camunda/camunda-bpm-platform · GitHub


Anyone from camunda?

Anyone know how to access the Error Message of a BPMN error?,%20java.lang.String)

The BPMN Error docs show that you can pass a second variable “message”, but the Error Event’s Error Code Variable does not return the error’s message value.

Any ideas?

Hi @StephenOTT,

in 7.6, we implemented that you can pass the error message to a given variable. See the issue CAM-5953.

Beside that, your script task looks good :wink:

Best regards,

@Philipp_Ossler Thanks!

If anyone is interested:

1 Like

@Philipp_Ossler could you provide some context to this behaviour:

If a BPMN Error is uncaught by a Error Event, (the Error Event is looking for a different error code than the one that was throw by the BPMN Error), the process instance seems to disappear from cockpit and task list. It does not appear to rollback.

Is this behaviour described somewhere?

Hi @StephenOTT,

if the error is not caught, the process instance just ends. You can find the instance still in history (or in enterprise cockpit ;)). This behavior is described in the reference guide.

Best regards,

@Philipp_Ossler :slight_smile: let me rephrase my question: When the BPMN Error is uncaught, what is the design thinking around it being a termination/end to the process rather than a rollback occurring?

Hi @StephenOTT,

this is a proposal from the spec (P. 247).

If the engine would do a rollback then the throwing process instance may be stuck since the error cannot be caught anywhere. IMO, it make sence to end this process instance.

Best regards,

@Philipp_Ossler, so was the thinking different for non-BPMNError errors? Example if a HTTP-Connector throws an error, it rolls back. If a form throws a error, it rolls back. But for BpmnErrors it immediately ends the instance. Just trying to get clear on the design thinking so i can explain it to others.

Hi Stephen,

a BPMNError is (or should be) business related. So it should be handled by the engine in the process instance. Every other Error is just technical and should be handled by the runtime environment (JVM or application Server)

This helps me to sort my mind. Maybe yours too?

Cheers, Ingo

1 Like