Camunda BPM 7.12.0-alpha4 Released

By
  • Blog
  • >
  • Camunda BPM 7.12.0-alpha4 Released
TOPICS

30 Day Free Trial

Bring together legacy systems, RPA bots, microservices and more with Camunda

Sign Up for Camunda Content

Get the latest on Camunda features, events, top trends, and more.

TRENDING CONTENT

Camunda BPM 7.12.0-alpha4 is here and the highlights are:

  • Handling Bpmn Error and Escalation in User Tasks
  • Cascading Changes to Due Dates of Recurring Timers
  • Add Time Triggered Task Listeners in User Tasks
  • Java 13 Support
  • 7 Bug Fixes

You can Download Camunda for free (click on Preview Release) or Run it with Docker.

If you are interested, you can see the complete release notes.

If you want to dig in deeper, you can find the source code on GitHub.

Handling Bpmn Error and Escalation in User Tasks

In case a business error occurs during the execution of an External Task, it is possible to raise a Bpmn Error.
But have you ever wanted to escalate a User Task, or indicate a business error for a User Task? As of this alpha, you can report a Bpmn Error or an Escalation for a User Task.
Whenever a business error occurs, the user can invoke, via Java API or REST API, a Bpmn Error to be thrown:

POST /task/aTaskId/bpmnError
{
  "errorCode": "invalid-report-543",
  "errorMessage": "An error occurred during report review.",
  "variables": {
      "reportId" : {
        "value" : "PLR-233",
        "type": "String"
      }
  }
}

If, in a Process, an Error Catch Event is implemented with the respective errorCode, the Bpmn Error will be caught and propagated accordingly. The same goes for reporting an Escalation, the respective documentation can be found for the Java API and the REST API.

sample process with Error Catch Event

Cascading Changes to Due Dates of Recurring Timers

Within a BPMN model, a user can specify a recurring timer with an ISO-8601 interval string. (e.g. “R3/PT30M”)
The timer stores a due date to indicate when it is ready for execution. For recurring timer, the engine calculates the due date based on the cycle (e.g. “PT30M”) and creates a subsequent timer whenever a recurring timer is executed until the number of repeats (“R3” = repeated three times) is reached.

Given a “R3/PT30M” recurring, every timer instance is due 30 minutes after the previous one.

three 30-minute intervals indicating the three timer due dates

Via the ManagementService it is possible to update the due date of a timer instance. If the due date of Timer 1 is altered by 15 minutes via managementService.setJobDuedate(String jobId, Date newDuedate) the three timers are executed differently.

timer 1 is due after 45min, timer 2 after 60min and timer 3 after 90min

The due date of Timer 1 was altered by +15 minutes, so it is due after 45 minutes. However, Timer 2 and Timer 3 are not affected by this and their due date is still based on the original due date of Timer 1.

However, what if you want a due date change to cascade to subsequent timer instances?

one 45-minute interval then two 30-minute intervals indicating the three timer due dates

With this release you can use the cascade flag (via REST API) or managementService.setJobDuedate(String jobId, Date newDuedate, boolean cascade) to achieve this.

Add Time Triggered Task Listeners in User Tasks

Sometimes it is useful to trigger a task listener of a user task after a certain time has elapsed, e.g. check daily whether the task needs to be reassigned or whether emails need to be sent.
Up until now, all of this can be done with a boundary event but that has a number of drawbacks when it comes to the cancellation and recreation of the task.

With this alpha, we support a task listener that is triggered after a task has been active for a certain period of time. The listener must be of type timeout and can then control
how to proceed with the task, including completing and reassigning it.

In order to attach such a listener to a user task, you can configure the following in your BPMN:

...
<bpmn:userTask id="myTask">
  <bpmn:extensionElements>
    <camunda:taskListener delegateExpression="${setBusinessKeyListener}" event="timeout" id="timeout-friendly" >
      <bpmn:timerEventDefinition>
        <bpmn:timeDuration xsi:type="bpmn:tFormalExpression">PT1H</bpmn:timeDuration>
      </bpmn:timerEventDefinition>
    </camunda:taskListener>
  </bpmn:extensionElements>
</bpmn:userTask>
...

Adding the timerEventDefinition child element to the task listener of type timeout will execute the referenced delegate after the specified amount of time after the task was created.

Read more about task listeners in general in the documentation, about their configuration in the reference, and about their migration in the guide.

Java 13 Support

This alpha also brings support for the latest Java 13.

What’s Next?

The next alpha version is scheduled for the end of October and our team is already working on it.

The minor release of Camunda BPM 7.12 is coming this fall (November 30, 2019).

Your Feedback Matters!

With every release we constantly strive to improve Camunda BPM. To make this possible, we are reliant on your feedback. Feel free to share your ideas and suggestions with us.

You can contact us by writing a post in the forum.

Try All Features of Camunda

Related Content

We're streamlining Camunda product APIs, working towards a single REST API for many components, simplifying the learning curve and making installation easier.
Learn about our approach to migration from Camunda 7 to Camunda 8, and how we can help you achieve it as quickly and effectively as possible.
We've been working hard to reduce the job activation latency in Zeebe. Read on to take a peek under the hood at how we went about it and then verified success.