Create escalation in IncidentHandler

I need to have a configurable exception handling based on the process definition(different subprocesses handle incidents in a different way). One variant should send an escalation event to the parent process. The problem is I don’t know how to send the escalation. Via RuntimeService I can correlate messages or send signals, but I haven’t found anything regarding escalations.

Why do you want to sent escalation grammatically?
You can use the throw escalation event:
https://docs.camunda.org/manual/7.10/reference/bpmn20/events/escalation-events/#throwing-escalation-events

I want to have an escalation as an option of handling incidents. I’ve implemented custom IncidentHandler where I check the remaining number of retries and when I’m out of retries, I want to do different things based on configuration. So this won’t be modeled in a bpmn. Can this be done? I cannot figure out how to create an escalation programatically.

I have a workaround, which is creating a non-interrupting message subprocess in the top-level process. It looks like this:

image

This is working fine, because I can just send a “trigger escalation” message via RuntimeService and the “Workaround” subprocess will pass control to the Escalation handling. But I think that this just clutters my diagrams(the diagram above is simplified) and is unnecessary. If I could trigger the Escalation from the code, I could get rid off this Workaround.

It is not possible to trigger an escalation programmatically.
You can consider switching to an error event. It is possible to trigger BPMN error from delegation code
https://docs.camunda.org/manual/7.10/user-guide/process-engine/delegation-code/#throw-bpmn-errors-from-delegation-code

But I’m not going to throw the BPMN error from the delegation code, but from a custom IncidentHandler. End even then, the error start event can only be interrupting(at least in the Camunda modeller).
Anyway, I figured I will also need this escalation handling to be started via message correlation, so my “workaround” will stay no matter what type of event I’ll be using, so I’ll stick with it. I’ll post an update if I find some issue with it, but so far it seems to be working fine.
Thanks

1 Like