The External tasks concept was introduced in v. 7.4. So far, only two operations existed to deal with external tasks: Fetch & Lock and Complete (read more in our docs).

These operations may be enough in most of the use cases, but can also cause a lot of inconveniences:

  • When an external task represents a long-running operation (like video transcoding, data indexing, etc.)
  • When it’s hard to estimate the time that the worker will need to finish the task

Before v. 7.8, a worker had to choose the lock duration at the very beginning, when fetching the task, and it did not have a margin for error. If the lock duration is not big enough,
so that the worker is not able to complete the task in the given amount of time, the task can be fetched by another worker. As a consequence, two workers will do one and the same job,
which can lead to huge problems like data inconsistency, etc. On the contrary, if the lock duration is too long and the worker can’t complete the task for some reason (system crash or anything),
then another worker is not able to take over the work, unless the timeout has been reached.

To resolve such problems, starting with version 7.8, the new operation Extend Lock was introduced. It allows to sequentially update the lock duration for the external task,
while working on it.

Previously, the process could look like this:

External task scenario before v.7.8

Let’s imagine that we have two servers up and we Fetch & Lock and start a long running process on one of those servers. This long running process could take 8 hours to complete,
so we set the timeout to be 8 hours. Two hours into the process, that server has a problem and is automatically torn down and a new server is brought up
in its place. Previously, Camunda (and the second server) would have continued waiting for another 6 hours before unlocking the task. Only after the timeout has been reached,
the task will be available for Fetch & lock again from another server.

Now, with the new Extend Lock operation, our scenario could look like this:

External task scenario in v.7.8

Every 25 minutes, the first server can report that it is still working on the task and will need at least 30 minutes more. In case it has neither reported “complete” nor extended the lock after another
30 minutes, the task will be unlocked by Camunda and can be fetched for execution by another server.

Also in this pattern, the worker does not need to estimate lock duration at the very beginning. It can just use some “standard” initial value and then extend the lock as much as necessary.

How to use it

In the Java API, the feature can be accessed through the ExternalTaskService:

    ExternalTaskService externalTaskService = processEngine.getExternalTaskService();
    externalTaskService.extendLock("exampleExternalTaskId", "exampleWorkerId", 60000);

In this example, the lock duration is extended by 60000 ms = 1 min.

The REST API call would look like:

POST /external-task/exampleExternalTaskId/extendLock

        "workerId": "exampleWorkerId",
        "newDuration": 60000

For more details, please see the documentation about the
Java API and the

  • Monitoring Camunda Platform 7 with Prometheus

    Monitoring is an essential facet of running applications in a production system. Through this process, organizations collect and analyze data, and determine if a program is performing as expected within set boundaries. When combined with alerting, monitoring allows for detecting unexpected system behavior to mitigate exceptional situations as fast as possible. Furthermore, tracking the performance of a system enables organizations to improve those aspects that have the biggest impact with higher priority. One essential aspect of monitoring is the list of key metrics you want to observe. There are different categories of statistics that can be of interest here. To observe the defined metrics, there are plenty of application monitoring tools on the market today. They differ in many aspects...

    Read more
  • Securing Camunda 8 self-managed cluster and applications...

    Directory services are an effective way to manage an organization’s users, groups, printers, devices, and more. Most organizations accomplish this using Active Directory, Apache Directory, Oracle Internet Directory, or other similar tools. Recently I worked with a customer who wanted to see how he could secure the Camunda 8 Platform and process applications with such a directory. Their requirements consisted of: Allowing Directory users to access Camunda applications (Tasklist, Operate, Optimize) Accessing secured Tasklist & Operate APIs from our custom project Securing the custom project In this article, I’ll briefly explain the 3 easy steps taken to fulfill their requirements which include: Federate users from the Directory service into Keycloak Declare an application in Identity to access Camunda APIs Configure...

    Read more
  • Accelerate Connectivity with Camunda Platform 8.1

    We’re thrilled to announce Camunda Platform 8.1, the latest release of our process orchestration solution. This new version introduces features that accelerate connectivity to the many different systems and technologies that are required for true digital transformation, including: Create custom Connectors with our Integration Framework to accelerate connectivity New out-of-the-box Connectors for popular services Enhancements to Camunda Modeler that improve productivity Hot backups and official support for Amazon EKS and Red Hat OpenShift Plus, several upgrades requested by Camunda Platform 7 customers Organizations across all industries rely on complex technology stacks to adapt and enhance their operations in response to market dynamics, new disruptive companies, and increasing consumer expectations. Your technology stack likely includes everything from cutting-edge technologies to legacy...

    Read more

Ready to get started?

Still have questions?