Backup Action For ServiceTask To Use ErrorBoundaryEvent

There is a scenario where all ServiceTasks may throw BpmnError exception. I don’t want all my ServiceTasks to explicitly declare an ErrorBoundaryEvent to catch errors, because that makes my BPMN look particularly bloated. Does it exist a more elegant way to handle BpmnError?

Thank you very much.

Since the ServiceTask activity does not actively reference attach to its own error events, I can only get all the relevant ‘bpmn: boundaryEvent’ event nodes by foreach all the child nodes under ‘bpmn: process’, and for the The ‘ServiceTask#id’ associated with the ‘attachedToRef’ property matches the current ‘ServiceTask#id’.

Which seems to solve my problem:

For activities that explicitly declare ‘Error Boundary Event’, throw if an error occurs BpmnError exception for other actions, but unfortunately I found that using the ‘DelegateExecution#getBpmnModelElementInstance()’ method took time more than 200ms!

Is there any other good way, or the model I originally built has problems?

Best Wishes.

This is a question I’ve come across a few time before - so i decided to create a code example to show a nice/hacky way to implement it.

The basic idea is to have an event subprocess to catch any error that might happen.

you can start the process and each service will throw an error randomly. The error is thrown and the current activity id is added as a message to the error event.

throw new BpmnError("GenericError", delegateExecution.getCurrentActivityId());

This is then stored in a variable that is accessed in order make the return. Which puts the token back the end of the symbol that threw the error

delegateExecution.getProcessEngineServices().getRuntimeService()
                   .createProcessInstanceModification(delegateExecution.getProcessInstanceId())
                   .startAfterActivity(errorTaskId)
                   .execute();  
2 Likes

Yes this is the answer I want!

I thought about handling it through the event sub-process, but because of the special nature of the ErrorBoundaryEvent (interrupt event), even if I catch the error in the sub-process and recover, the trunk process will still end.

I have tried to understand Modification service support and it is obvious that I have not clearly realized its power!

Thanks again for your, very clear answer!

Bless you!

1 Like

First of all, your previous answer did open a new door for me, but when I integrated the parallel gateway into the before process, I found that I encountered new problems.

As shown in the figure below, this is my flowchart. As before, every ServiceTask may throw a BpmnError. Now I actively throw a BpmnError in S2, and then the problem comes.

The process will follow step:
S1-> S2-> ErrorHandler-> S3

The path I actually expected was this:
S1-> S2-> ErrorHandler → S3 → S4 → S5 → Over
OR:
S1-> S2-> ErrorHandler → S5 → Over

It does not jump out of the parent sub-process to which S2 belongs, and of course it will not enter the process’s END listener.

This brings me to the ‘dead lock with parallel gateway’ you mentioned earlier, actually S4 did not execute successfully.

I think it is the error of S2 that is passed to the sub-process and eventually breaks the sub-process and continues to execute, and the resulting behavior is that the sub-process is destroyed! My ErrorHandler in a sense just delays the timing of the error. I’m not sure if I understand correctly.

I try to get the relevant information from the Modification API documentation, only Nested Instantiation and Ancestor Selection for Instantiation mention sub-processes, unfortunately i did not find a solution.

In fact, if I pass the activity id of the sub-process that catches BpmnError to #startAfterActivity api the result is what I expected. Its effect is equivalent to the results of the following two processes:

FLOW1:

FLOW2:

I don’t want my flowchart to look more and more complicated, so is there a better way to deal with such a scenario?

Best wishes!