What are you looking for?

Camunda BPM 7.0-alpha5 released

By
  • Blog
  • >
  • Camunda BPM 7.0-alpha5 released
Two weeks after the last alpha release we bring you the freshly baked* alpha5 version of the Camunda BPM platform. The highlights of this crispy new release are:

50 JIRA issues were closed, see the complete release notes.
Note: this release contains database changes. Upgrade scripts can be found in the “sql” folder of the distribution.
 
(* using Robert Gimbel’s special homemade yeast)


Things are happening in the cockpit

Over the last two weeks, process engine hacker Roman Smirnov and JavaScript wizard super magician Nico Rehwaldt have been focusing on Camunda cockpit. They have added a couple of features and refined the cockpit plugin infrastructure.
There is process definition summary plugin which visualizes the state of a process definition using green and red dots (red = failed jobs):

process definition summary plugin

On the process definition details page we now have process instance table:

process instance table on definitions detail page

We now have an increasingly powerful and flexible client side-architecture in place which will now allow us to implement interesting new features and start working on usability and layout of existing features. Read the full client-side plugin story at https://docs.camunda.org/latest/real-life/how-to/#cockpit-how-to-develop-a-cockpit-plugin (section “The client side”). Also check out our client-side test infrastructure using Karma and Node.js: see README.md.

Incident infrastructure in Process Engine (Work In Progress)

We started work on a new Infrastructure for incidents in the process engine. This project has 3 goals:
  1. Provide an abstraction over different “notable” events that can happen during process execution.
  2. Provide an extensible, event-oriented API for handling such incidents.
  3. Provide a default implementation for incident event handlers which writes incidents to the database.
Currently we provide incidents for failed jobs. Failed job incidents are raised when automatic retries for a Job (Timer or Asynchronous continuation) have elapsed. The incident indicates that the corresponding execution is stuck and will not continue automatically. Administrative action is necessary. The incident is resolved, when the job is executed manually or when the retries for the corresponding job are reset to a value > 0. In the future, we plan on providing features for raising additional kinds of incidents. Examples are the fact that a process instance has entered a certain task, that an error boundary has been triggered or that a process instance took to long to complete.
Incident handling is extensible. The default implementation writes incidents to the database such that they can be queried:
runtimeService.createIncidentQuery()
  .processDefinitionId("someDefinition")
  .list();
In cockpit we can now visualize different kinds of incidents in the same way and allow users to define for a given process definition what constitutes an “incident”.

visualize different kinds of incidents

We also support recursively raising incidents for super process instances and correlating them to the call activity which has invoked the process instance in which the incident occurred. This is used by the cockpit tool for visualizing the state of a process definitions (and instances).  The recursive nature of incidents will allow the cockpit tool to provide drill-down features.

recursively raising incidents for super process instances and correlating them to the call activity

There is an extensible API for handling incidents which allows you to replace or enhance the default behavior. For example, you could send an email to an administrator if an incident inside a given process definition is raised.

Additions to the REST Api

Thorben has done some additions to the REST API, checkout
  • Better exception messages.
  • Execution Queries.
  • Process instance /execution variables.
Errors are now also provided in JSON format:
{"type" : "SomeExceptionClass", "message" : "a detailed message"}.
You can modify multiple process variables in a single request:
POST/process-instance/aProcessInstanceId/variables
Request body:
{"modifications": [
    {"name": "aVariable",
     "value": "aValue"},
    {"name": "anotherVariable",
     "value": 42}
    ],
"deletions": [
    "aThirdVariable", "FourthVariable"
]}
Or you can address individual process variables through PUT/ GET / DELETE:
PUT /execution/anExecutionId/localVariables/aVarName
GET /execution/anExecutionId/localVariables/aVarName
DELETE /execution/anExecutionId/localVariables/aVarName

Try All Features of Camunda

Related Content

Improve customer satisfaction while transitioning to an entirely different energy system? Not a problem with Camunda's Self-Managed migrations.
How to avoid pitfalls and make the most of FEEL for a citizen developer.
How to avoid pitfalls and make the most of FEEL for a seasoned software developer.