BPMN error modelling and catching error

Camunda 7 Topics Discussion & Questions
1

In service task, we are making Rest API call to external systems. Suppose if the external system throws some exception or some System exception, its best practice to handle those technical exceptions/error in BPMN error model?

Is BPMN error model is used to catch only business validation errors?

1 Like
2

Catch the situations you want to handle differently from a functional perspective in your BPMN model - typically, these are the functional exceptions. For the other cases, rely on Camunda’s default behaviour to retry and if it keeps failing, give up and create an incident.

3

you meant, not to model those function errors as part of BPMN error events?

Already i have configured retry option for service tasks, even if fails how can we model those exceptions/error into incident. did camunda modeler supports modelling incidents?

4

No, I mean, if you have functional exceptions you want to deal with in some way in the process, model them in the BPMN using for instance error events.

Incidents are created automatically when e.g. a job’s retry count reaches 0. You don’t have to model them, it’s default behaviour provided by Camunda. They show up in Cockpit automatically.

1 Like
5

To summarise:

  • Functional exceptions: model them - we want to deal with them somehow in the process
  • Technical exceptions: don’t model them - rely on default retry and failure behaviour
2 Likes
6

I agree, with one more suggestion…

We started with exactly these principles. However we were caught out by business exceptions coded as HTTP response codes in REST APIs (consider 404 for object not found as a business error, as opposed to 404 service not found as a technical error). Hence we matured our principles a little…

Its how you react to the exception, not the type of exception which matters. Hence if the treatment of the exception is visible as part of the process (eg business exceptions) then yes model it. If the treatment is via the operations console, then don’t model it and treat as an incident…

regards

Rob

1 Like
7

Lets say after retry count reaches to count=0, still the external rest API not yet responded, it will create incident, is that possible to resume the execution from the incident once the external system Rest API is back to serve the requests?

8

Hi,

In this case, once you have determined that the external API is back, operators can via the cockpit resume the process. Thus the behaviour is after retry strategy is exhausted, throw incident and ‘pause’ process instance. Pause is effected by having no more retries. In cockpit, retries can be increased and thus the process will resume to try again… Note this is the behaviour with asynchronous executions, synchronous is different.

Heres a somewhat advanced, possibly a solution in search of a problem pattern which I call fail fast, auto resume. Rather than throw an incidednt, it goes into a wait state to auto resume. During the wait state, it can be woken up with an explicit signal. It works by interrogating the retry count…to see the detail, you need to expand the collapsed inline subprocess.

Its effectively rolled its own retry strategy…

The model is classless and can be deployed direct from modeller…

regards

Rob
FailFastSafeAutoResume.bpmn (24.3 KB)

1 Like
9