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:
- Failed jobs plugin in cockpit,
- Process Instance table in cockpit,
- Refined client-side plugin infrastructure,
- New incident infrastructure in process engine,
- Additions to the REST API,
- Complete support for websphere application server 8.5 (enterprise customers only)
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.
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):
On the process definition details page we now have process instance table:
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:
- Provide an abstraction over different “notable” events that can happen during process execution.
- Provide an extensible, event-oriented API for handling such incidents.
- 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”.
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.
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.
Read the doc on incidents: https://docs.camunda.org/latest/guides/user-guide/index.html#process-engine-incidents
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/variablesRequest 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/aVarNameGET
/execution/anExecutionId/localVariables/aVarNameDELETE
/execution/anExecutionId/localVariables/aVarName