Optimization of workflows (with no manual tasks)

[ernesto.d...@gmail.com]

We would like to execute as many camunda instances as possible (with no manual tasks inside). Then we introduced multi-threading to execute several of them in parallel, independently from Camunda and they are running pretty fast, so it was ok. Then, it looks it might happen that (at least) one of our automated tasks
can take quite long, very long (i.e. JMS, WS calls that can take several minutes). Unfortunately, this task will almost determine the whole execution time :((
Our idea is, if possible, to free the Camunda thread that is executing the workflow of the task (that will take long) and allow Camunda to start a new workflow in the freed Camunda thread (something similar to SignallableActivityBehavior interface – if we understood it correctly). For that purpose, in some ways, we outside Camunda should get a callback, notification, etc... to put this execution in a quere and start a new one, etc.
Our question is: can we start processes asynchronously (now we are using startProcessInstanceByKey(), which blocks) and if so, can we get these callback notifications (if Camunda frees a thread, in which the process is still alive, under execution) from the runtime service and then resume it later by id?
Should we solve it with the sender and receiver tasks (in assync calls)?
Of course we will appreciate any best practices.

Thanks in advance!
Ernesto

[Philipp Ossler]

Hi Ernesto,

you can use asynchronous continuations in your process. If a task can take a while then you can mark it as async. The current execution ends when it arrives an activity which is marked as async. The async activity will be executed by the job executor. See the docs [1] for details.

Additionally, you can also start a process instance asynchronous - see [2].

Greetings,

Philipp

[1] https://docs.camunda.org/manual/latest/user-guide/process-engine/transactions-in-processes/#asynchronous-continuations

[2] https://docs.camunda.org/manual/latest/reference/bpmn20/events/start-events/#asynchronous-instantiation