Questions about External Task pattern

(I post my questions as new Topic as most of the other topics which similar questions have been “solved”)

So, first question is whether the lock by the task client is per topic or per activity instance. I guess the latter?
I’m asking because I want to use the same topic name in many tasks within the same process model (and even in different process models):


So, would this make sense/work?

Actually, I’m thinking to wrap one external task with the one topic around a Call activity and use this Call activity in many places in a process:

Will I have any issues?

I have a process which has many tasks to be performed by a (physical) robot. I don’t want for each of this tasks to have different topics (e.g. based on the name of the task). I’d like to have one topic (e.g. RobotTask) and based on the name of the task and the variables, the task client will inform the robot accordingly.

Also, in this example here Spring Boot Starter for the External Task Client - Camunda
the call to a service (e.g. DB query) and the task completion is done within the same class. But how is the asynchronous pattern achieved?
In my case, what should be the business logic of the task client/worker?
I see it as two steps:

  • Send the info to the robot.
  • (Robot does its job and after X minutes informs the task client. Actually I want also the task client to subscribe to a service which catches changes on the task)
  • Task client completes the task (if the notification from the subscribed service says that the “task_status= completed”)

I thought that these are separate and couldn’t be in the same class. What do I miss?
Should I split the internal pattern of the call activity into two external tasks/topics? (One to send the task info and one to catch the updates and completes?)

Thank you

You definitely do not want to use the same task topic for different external tasks. If you do that, there will be no way for the external task to know which task it is running Grip Product or Release Product. These (at least in this instance) seem to be 2 totally different tasks being performed, so they should be handled differently. I’d suggest using differentiators on the tasks like robotTask_Grip and robotTask_Release to differentiate them.

This way, when the robotTask_Grip task is completed, and the engine is informed of the completion, the execution token will move to the next step Release Product and that task is initiated.

Best Regards,

1 Like

There many methods to use one topic for whole service. Just add input variable method and params. I have service with 100 different task, all use 1 topic.

Here is example of this approach:


Hi @kontrag,

either you have to use some state inside the worker-application, meaning that the robot can notify the worker as soon as the job is done and the worker again can complete the task,

or you could think of implementing the state as part of the process model using e.g. message-receive-events. This way, you have to provide some kind of callback-interface that manages the message-correlation, since I would not implement this logic as part of the robot.

BR rnschk :slight_smile:

/ps: and I would also agree with @davidgs to not re-use the same topic in different service-tasks.