Error Handling in Service Task

Camunda 8 Topics Discussion & Questions
1

Hi Team,

We are in the process of moving from C7 to C8, in C7 whenever there’s is exception in service tasks and it is not handled, execution of the process will be moved to previous user task which was successfully completed, please help how we can achieve this behaviour, in C8 I see if there are errors in service task, it’ll create the incident and execution will be in same state.

2

Hi,

Camunda 8 does not have the transactions known from Camunda 7. So, there is no way of moving back to the last successful user task.
In my opinion, if your process relies on this logic, the model should include it. You can

  1. Add a boundary error event to your service task
  2. Route the sequence flow from the error event to the previous user task
  3. Add a generic try-catch (maybe as a subclass?) to your service class. If an exception is caught, the error from step 1 is thrown, and the process loops back to the user task.

I hope this helps.

1 Like
3

Sure, let me try this.
Thanks!

4

Hi @Naveen_KS,

could you please describe what the users are doing when they get the tasks back in their Tasklist?

In case they just complete the user task again to continue, you can replace the behavior with retries in the worker. The number of retries is defined in the process: Service tasks | Camunda Platform 8 Docs.

They have to be decremented in the worker. In case the worker sends a deadline, the job handling will be postponed until the deadline is reached.

Hope this helps, Ingo

1 Like
5

Hi @Ingo_Richtsmeier,
We have exposed a API which will complete the user task using tasklist API, we are not using Tasklist UI for completing task.
We have retry mechanism added to invoke the same service task until the retry count is exhausted.
If execution is at the service task and it is failed, it’ll create an incident, but to recover or restart the process instance execution might be difficult for us through API call, that is why we are expecting this behaviour, so that we can restart from previously completed user tasks.

6

Hi @Ingo_Richtsmeier , @StephanHaarmann
As per your suggestion, using boundary error event for service task is not feasible right, if this is the case we need to have it for all the service task.

Is there any option available to handle service task exception in generic way?

7

Hi,

Camunda 8 has its inbuild retry mechansim. When a service task is invoked and an exception is thrown, catch the exception, decrement the retry count, and fail the task. Camunda will retry it until the task completed, or the retry count reaches 0. If the retry count is 0 an incident is invoked.
Depeneding on the client you use (i.e., Zeebe Spring Boot Client), you can include this exception handling logic in an (abstract) class which is the template or all service tasks implementation.

8

Thanks @StephanHaarmann , let me check on that.
We are facing one more issue, we are creating process instance as part of API call, when we receive the call, we start the process instance and as part of response, we’ll send the next user task as part of that workflow.

So before sending the response all the service tasks will be executed and execution will be moved to user task.
But intermittently, zeebe broker is not activating the user task handler after completing the service tasks. Execution is moving forward and response is sent back without User task details. We have created zeebeClient with default configurations

Could you please help here. Let me know if you need any additional details.

Have created different post for this - User Task worker not activated intermittently

9

You can create a wrapper for the service task handler - you can detect when there are no more retries and trigger custom logic in the handler wrapper - however, moving the process execution token back to the previous user task would be a feat.

There is a ModifyProcessInstance API that you could call. However, you need the specific ElementId of the previous user task - which would require introspecting the process model.

OK, so this is possible. You need to use the process model id to get the process model XML from the Operate API, then you need to introspect the model and reason about it to find the previous user task. It’s possible, but not trivial.

You could also roll a solution by using an exporter and managing a sliding state window in an external system.

@Naveen_KS, I get the sense that you are using the User Task list to manually retry service tasks, and perhaps remediating incorrect data entry in the user task - kind of using it like an incident remediation in Operate, but without giving the users another interface. Is that your use case?

Josh

1 Like
10

Hi @jwulf , There are alternatives available but that requires more processing to be done or to keep the data about previous user task details for each process model. Will do some analysis to see which fits better.

you are right we are using user task for remediating the incident and retry the execution without another interface.

11