BPMN Errors - Githubissues

m0lentum commented 2 years ago

We have a use case at JYU where we would like to use BPMN errors for control flow. Is this currently possible? It seems any raised exception results in an incident in Camunda, which we don't want. If not, any ideas on how to implement these? I can work on a PR if needed.

The use case in question is letting users handle situations where a digital signature request in Sarake Sign is rejected or fails to be signed before its due date.

datakurre commented 2 years ago

@MoleTrooper Unfortunately, I've not implemented support for BPMN errors in :carrot:, because BPMN errors could be modeled on top of otherwise successful execution on Camunda Platform >= 7.15. I was looking for update to 7.15 and did not want to invent my own convention.

Checkout, how errors are defined at "Consumer" task at https://github.com/datakurre/robotlive/blob/main/BPMN/traffic-data-loader.bpmn

bpmn-errors

So, only after a external task has been technically successfully completed, Camuna checks if any BPMN error condition evaluates to true. If so, it raises suitable BPMN error, which is hopefully caught by a BPMN error event listener.

This did sound weird for me too at first, but then again, it allows clear separation between unexpected technical errors (incidents) and expected business errors (BPMN errors handled in flow). Also found out later, that it fit really well how Robocorp did handle similar errors in their examples. https://github.com/datakurre/robotlive/blob/main/robots/TrafficDataLoader/consumer.robot#L37 (the example is adapted to carrot from Robocorp example code).

If you are still on 7.14, and upgrading is considered too risky, you probably have to branch a temporary fork with a custom solution. camunda-external-task-client-js does have support for errors, so it is only about inventing out a custom convention https://github.com/camunda/camunda-external-task-client-js#handle-bpmn-error E.g. checking for a specific variable from otherwise successful execution.

datakurre commented 2 years ago

Also, it is actually nice that you don't need to be so aware of BPMN error naming (name, code, message) outside BPMN anymore.

datakurre commented 2 years ago

@MoleTrooper Afterthought! It might be possible to simulate 7.15 behavior with modeling an execution listener! I'll check this out and come back.

Resolution: BPMNErrors cannot be thrown from "expressions" OOTB. So, as you wrote below, exclusive gateway is the available temporary solution, and it could be refactored to BPMN error on >= 7.15.

m0lentum commented 2 years ago

Thanks for the info, this helps a lot! We're on 7.14 for now, but we could return a status variable to the process like you explained, and simply use it with a regular branch instead of making it throw an error like this.

jussilattu commented 2 years ago

Its fairly simple to model handling of status and raising BPMN errors with exclusive gateways, like this:

datakurre commented 2 years ago

@MoleTrooper For the sake of learning, let's remember that BPMN error is not only sugar for gateways, but also allows to catch those "exceptions" flexibly on higher scope.

bpmn-errors