External Task: Waiting for callback best practice

I have a service task that needs to make a rest call and wait for a callback.

There are two options available for me:

  1. Split the service task in two.
    A service task making the rest call and a receive task to be notified when I receive the callback.
  2. Keep it as a single unit of work.
    The rest call is made inside the execute method of the handler, but the complete method is not called.
    Since I don’t have the instances of the ExternalTask and ExternalTaskService, I have to save the id to DB and when the callback is received I retrieve the id and use the REST API call “complete” to finish the activity.

I’ve been told that this should be a single unit of work and this split is too low level to be included into the BPMN.

Do you know what would be considered best practice in this case?
Also, if you have a better approach please let me know.

Help is highly appreciated :slight_smile:

Is this what you are looking for? https://github.com/camunda/camunda-bpm-examples/tree/master/servicetask/service-invocation-asynchronous

You could for example use a process variable as the identifier for matching the callback to the correct process instance.

Hello Thorben,

Thank you for the reply.
In my case the Camunda engine runs on a separate service and the communication is done trough external tasks.
So I don’t think I can use the provided scenario.

I’m restricted to using the camunda external task client or REST calls.

Best regards,

Hm, thanks for the clarification. Then the second approach you describe in your first post sounds perfectly reasonable to me.

Both approaches from the first post work.
I just didn’t know which option would be the better one.

I have a hard time figuring out the granularity in the workflow.

For example in the first approach I have a higher granularity, but it simplifies the the code logic.
In the second approach I have less activities in the flow but I have to add extra logic in the code.

@Cosmin Hi

I am in the same situation as you. Have a workflow that in one task sends out an external call with a javadelegate to a kafka queue. The next task in the workflow should start when we recieve a message back from the queue. This could take several days.

Did you find a optimal solution for this problem?

Thanks for any answer.




Why not just use the send task/receive task pair? From my perspective, if the interaction can take days, why not make it explicit in the model…



1 Like

Hi @FrankReneSorensen

I kept the callback as implementation detail.
The worker id and external task id are returned on the callback response and used to make the complete.

Best regards,

@Cosmin Ok, so you made the call and the response in the delegate class? Async?

@FrankReneSorensen I have two parts.

The first part will lock the task indefinitely.
Here I make the processing for the request and put the message on the queue.
You can use the java delegate (from the external client library), but you can also fetch and lock your tasks trough your own implementation of the rest calls.

The second part will listen for the response message, process it and then complete the task.
The complete is done trough direct call of the rest API.


Ok. So in the first task you send out a message to a kafka topic, and locks the process instance?

In the next task in the flow, you listen to a kafka topic. When the message with the correct id arrives you start up the process instance again?

So, one delegate for sending out hte external task, and one listener to start it again when external task is done?

Thanks for your response! :slight_smile:




Hi, do you have any examples of the send task/receive task pair with java delegate?

Thanks for you response.



we used case 2 in my project , I store the external task in redis, while received call back data , I select mapping external task to compete by rest api

Thank you for your answer, however I have problem with the Send something call.
I have two process definitions which run at difference time in day. The “Send something to API” task is a API in external/third party system. Could you help me how I can trigger message event to “Receive task” which belong to process instance called to the API.

Have you experienced problems like this: the “Send something to API” terminate and a callback is sent for the “receive task”, but this is not initialized (or whatever) and the callback fails — that is, after the ACK the called API (Send something API) is already ready to send a callback for “Receive task”, but Camunda has not reached that point yet.