JavaDelegate created incident with custom IncidentHandler not showing in cockpit

Camunda 7 Topics Discussion & Questions
1

In my class implementing JavaDelegate I’m manually creating an incident when an exception is caught. I’m doing this so I have control on the type of incident. For this service task I also have asynchronous continuation set to before-exclusive

public void execute(DelegateExecution execution) { 
    try {
    }
    catch (MyException e) {
        execution.createIncident("customFailedJob", "config", "message");
    }
}

Then I have this class implementing IncidentHandler

@Component
public class CustomFailedJobIncidentHandler implements IncidentHandler {
    @Override public String getIncidentHandlerType() {
        return "customFailedJob";
    }

    @Override public Incident handleIncident(IncidentContext context, String message) {

        return createIncident(context, message);
    }

    public Incident createIncident(IncidentContext context, String message) {
        IncidentEntity newIncident = IncidentEntity.createAndInsertIncident("customFailedJob", context, message);

        if(context.getExecutionId() != null) {
            newIncident.createRecursiveIncidents();
        }

        return newIncident;
    }
}

The incident seems to be created, if I go to /engine-rest/history/incident I can see the incident created here but open field seems to be set to false compared to if I’m not using custom incidents where the open field is set to true, and this incident does not appear in the cockpit.

2

Creating an incident does not stop the process from executing. So most likely the process just continues and deletes your incident entity as the owning execution is deleted. An incident is a piece of information, not a functional part of the process. What stops the process for the built-in incidents is that either the job or external task is out of retries.

3

I see, what do I need to do then to get something similar to the built-in incident process that I can retry in the cockpit? while still having the option of defining my own incident type.

4

I don’t think that’s easily achievable. You could introduce some kind of wait state (e.g. asynchronous continuation, user task) to the process, in that state raise an incident, and then prevent it from contunuing.

5

Maybe you could also adapt this example: camunda-bpm-examples/servicetask/service-invocation-asynchronous at master · camunda/camunda-bpm-examples · GitHub

In case your code is successful, you call #signal immediately. Otherwise you don’t, raise an incident, and trigger continuation via RuntimeService#signalExecution when the problem is resolved.

6

Thank you, I’ll check this out soon.

Is there any reason why doing this when using JavaDelegate isn’t easy? but when implementing the service tasks using external tasks, raising custom incidents were pretty much straightforward.

7

There just is no way to tell the engine to stop executing the next steps in the process. You need to raise an exception (which you don’t want) or reach a wait state.