Approaches to disable a particular External Tasks

Is there a standard or recommended way to disable the execution of a particular External Task? We have a variety of external tasks which are used to call other microservices. As happens, occasionally one of those services will be having an operational issue, and we want to let tasks “back up” rather than executing calls to their service which we know will fail. I’ve looked around and seen mentions of using Timer Boundary Events for this purpose, but none I’ve found have explained how that approach would actually work. I’m admittedly not an expert on them, but I don’t understand how they could fill that purpose.

What I’m looking for is essentially a switch which would prevent certain external tasks from running in any process instances, even ones that were created before flipping the switch, but would still allow the process instance to be started.

Hi @Megan_Lovett,

you can suspend the process instance: https://docs.camunda.org/manual/7.12/webapps/cockpit/bpmn/suspension/#process-instance-suspension.

Hope this helps, Ingo

That doesn’t really address the problem I’m trying to solve. I’m looking for the ability to prevent a single stage from being executed across all process instances, even doing so proactively on process instances that haven’t been created yet. If we know dependency X will be down for 12 hours, or is currently down with no resolution in sight, we can’t manually and reactively pause the hundreds or thousands of instances that might come in over the course of that outage. I was hoping there might be some native functionality in Camunda itself to facilitate this, but if not then we’ll have to build something into the service that executes the external tasks.

I actually think what Ingo suggested solves the problem perfectly.
It would let you programmatically “pause” any number of specific process definitions, processes instances or even specific activities for as long as you need to and then you can programmatically “un-pause” them again.

Pausing a process definition prevents new instances from being created. We initiate instances programmatically, so we’d either lose data, or require some external buffer for data to “back up” in, and that buffer could instead just be in front of the external task in question.
And pausing existing instances can only be done after they’re created. That helps part of the problem, but not the problem of the instances being created programmatically 5 minutes after we step away.

:point_up_2::slight_smile:

From that documentation, the complete list of things I can suspend is: process definitions, process instances, and job definitions. I’ve explained why suspending process instances or process definitions doesn’t solve my problem. From the rest api, (/engine-rest/job-definition) none of the job-definitions seem to have any correlation with the tasks defined in any of our process definitions. If there’s a way I could be defining my process definitions that would make external tasks within them qualify as “jobs” eligible for suspension then that would absolutely solve my problem, but as-is I really don’t understand how what Ingo suggested is helpful.
I may be missing something though. I don’t see how that would allow me to programmatically pause “specific activities” that aren’t included in one of definitions/instances/jobs.
Am I possibly explaining my desire unclearly? Ideally I want the process engine to return no results when our task clients poll for external tasks to handle, despite those tasks existing in the process engine. And I want the ability to toggle that on a per-task basis.

There is! :slight_smile: if tick the asynchronous before tickbox that will create a job before you task which you can suspend.

Ah fantastic. That would indeed accomplish what I’m looking for. Thank you very much for bearing with me.