Overcome the Biggest Barriers to Digital Transformation

Discover 3 factors you can’t ignore that drive change in businesses
Icon Close DOWNLOAD EBOOK

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 wizzard 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 and sources.

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”.

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.

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
  • Drafting Your Camunda Cloud Architecture – Part...

    When automating processes you typically integrate systems and services, or in other words you orchestrate various APIs. In order to achieve this you not only have different technical possibilities, but also can choose between various modeling possibilities in BPMN. This post will give you an overview and advice on how to decide between alternatives.

    Read more
  • What You Should Know About Using Camunda...

    Camunda Platform Run, or Camunda Run for short, is a lightweight distribution of Camunda Platform that works straight out-of-the-box and comes pre-configured for production environments. Camunda Run is an excellent option if you’re just getting started with Camunda, or if you’re ready to use Camunda Platform in production. You can download the open-source Community Edition for free, and easily upgrade to the Enterprise Edition to access more features and support options. After you download and extract Camunda Run, you’ll find a configuration folder that contains a file called production.yml. The properties defined in this file are important for production environments and are derived from our guide to securing your Camunda Platform installation. To start Camunda Run with the production.yml configuration,...

    Read more
  • Drafting Your Camunda Cloud Architecture – Part...

    Have you started your first project using process automation as a service with Camunda Cloud? One of your first tasks would be to sketch the basic architecture of your solution, and this blog post will guide you through some important early questions such as how to connect the workflow engine with your application or with remote systems? Or what’s a job worker, what should it do, and how many do you need? This post is the first piece of a series of upcoming blog posts: Part 1: Connecting Camunda Cloud With Your World (this post) Part 2: Service Interaction Patterns with BPMN and Camunda Cloud (coming soon) Part 3: Writing Good Job Worker Code For Camunda Cloud (coming soon) Connecting...

    Read more