Job Execution with Managed Server Resources

For supported environments, Camunda BPM provides server modules that integrate the Job Execution with the application server’s managed threadpools. If you are using one of those environments, it is recommended to use the integration provided with it.

Integration into other JEE7+ compliant application servers is now offered by a new type of job executor: the ManagedJobExecutor. The purpose of this job executor is to ensure that job execution within the process engine is correctly controlled by the application server, by using managed resources (primarily: managed threads).

In order to facilitate the ManagedJobExecutor, the engine must be configured to use it. When bootstrapping the engine from Java code, you would create the new job executor like this:

This feature was initiated by the community, particularly by Tiese Barrell.
Thanks for your great contribution on that topic!

Query Jobs and Incidents by Failed Activity Ids

With the first alpha of 7.13, we included the id of the failed activity in jobs and incidents for quicker root causing of failures (see the related blog post).
Adding to that, jobs and incidents can now also be queried by the failedActivityId in the REST API and the Java API.

Please note that the failed activity id has changed from lastFailingActivityId to failedActivityId in several APIs with this alpha.

Hostnames in Historic Job Log

If you have multiple servers executing your Jobs, it is not clear if only a specific server is having trouble. With this alpha, the node which executed the Job is now displayed in the Job log to make debugging your process more comfortable.

The Job Log is located in the history view of the Process Definition and Process Instance. We also added a Job Log for failed Batch Jobs. You can find it when inspecting a failed Batch. Keep in mind that history has to be enabled for this feature to work!

Please bear in mind that this feature is only available in the Enterprise Edition of the Camunda BPM platform.
To try it out anyway, please request a Free Trial or Quote

Full Coverage of DMN FEEL 1.2

Starting with this second alpha, we added full coverage of DMN FEEL 1.2. We achieved it by
adding the former Community Extension FEEL Scala Engine to the Camunda Stack.

We will be releasing a more detailed blog post with a comprehensible example soon.
In the meantime, you can read more about the feature here:

OpenAPI Documentation of REST API

Another new addition within this alpha are the first steps of OpenAPI Documentation for the REST API.
We started small by documenting the Process Instance REST endpoints according to the OpenAPI Specification, so this is still work in progress.
Our goal is a single openapi.json file that contains our OpenAPI documentation.
If you are interested in our progress or if you want to check out the documentation, please feel free to download the JAR file containing it here.

Camunda BPM Run

Last but not least, we are proud to announce Camunda BPM Run, a new distribution of Camunda BPM that provides the Camunda web applications (Cockpit, Tasklist, Admin) and the REST API.
Camunda BPM Run is highly configurable and can be operated without any Java knowledge.
This alpha version ships the first increment of Run.

Follow these simple steps to start Run:

Download the distro from here (the Enterprise version can be found here).