We’re excited to announce the release of Camunda Platform 8.1.0-alpha3.
If you’d like to get started with Camunda Platform 8.1.0-alpha3 right away, you can sign up for a free trial now.
Create Process Instance Starting at User-Defined Elements
An often requested feature is now available as a preview with Camunda Platform 8.1.0-alpha3: create a process instance starting at user-defined elements. When creating a process instance through the CreateProcessInstance RPC, the process instance is started at the default none start event. For testing purposes, you may want to start at one (or multiple) of the other elements. This feature is now available through both the CreateProcessInstance RPC and the CreateProcessInstanceWithResult RPC. It is available for use in the Zeebe Java client and the Zeebe Go client.
Because this is an advanced feature, we recommend only using this functionality for testing purposes. The none start event is the defined beginning of your process. Most likely the process is modeled with the intent to start all instances from the beginning.
To start the process instance at a user-defined element, you need to provide start instructions along with the command. Each instruction describes how and where to start a single element. By default, the instruction starts before the given element. This means input mappings of that element are applied as usual.
Multiple instructions can be provided to start the process instance at more than one element. You can activate the same element multiple times inside the created process instance by referring to the same element id in more than one instruction.
Start instructions are supported for both CreateProcessInstance commands.
The following is a code example of how to create a process instance starting before the ‘ship_parcel’ element using the Java client:
client.newCreateInstanceCommand() .bpmnProcessId("order-process") .latestVersion() .variables(Map.of("orderId", "1234")) .startBeforeElement("ship_parcel") .send() .join();
Multi-instance Properties in Completion Condition Expression
A CompletionCondition defines whether the multi-instance body can be completed immediately when the condition is satisfied. It is a boolean expression that will be evaluated each time the instance of the multi-instance body completes. Any instances that are still active are terminated, and the multi-instance body is completed when the expression evaluates to true.
Special multi-instance properties are now available for use in the completion condition expression. From now on, you can use numberOfInstances, numberOfActiveInstances, numberOfCompletedInstances, and numberOfTerminatedInstances in this expression. Although they are available for use in that expression, they do not exist as process variables. These properties take precedence over process variables with the same name.
This feature is a community contribution by 李 銍.
Clients Can Set an Optional Backoff Time to the Failed Jobs
When a client activates a job to work on, but fails to complete the task, the client sends back a command to the broker to mark the job as failed. The default behavior is that the job is immediately available again for activation. There might be scenarios where this is not desired, for example in case there is a service outage, where immediate retries will not lead to a resolution of the problem or a rate-limiting where immediate retries might even worsen the change to complete the job successfully. With this new feature, it is now possible to set a backoff time for the retry in the fail job command, instructing the broker not to make the job activatable again until the timeout passes.
This feature is a community contribution by Alexey Vinogradov.
Support ISO8601 for Start Events with a Timer Cycle
Some use cases require that processes start on a specific date, which are unrelated to when the process was deployed to the system. An example is regular reporting or clean-up jobs which should run at a specific time during the day or week.
With this new feature, it is now possible to specify the exact time of a timer start event cycle using the ISO8601 format.
The following is a complete example of the timer definition, which starts the process on October 2th at 08:09:40 Berlin Time and repeats every day.
<bpmn:timerEventDefinition> <bpmn:timeCycle>R/2022-10-02T08:09:40+02:00[Europe/Berlin]/P1D</bpmn:timeCycle> </bpmn:timerEventDefinition>
This feature is a community contribution by 李 銍.
Token-based Authentication for Operate and Tasklist API
With the latest Identity 8.1.0-alpha3 release, it is possible to generate m2m tokens for the Operate and Tasklist API in a self-managed installation. This allows users to use the general OAuth2 client credentials flow by using a client id and secret generated in the Identity UI to generate a bearer token, which is then used to authenticate against the APIs.
Technical Concept for Hot Backups in Zeebe
As part of the 8.1.0 release, we plan to provide a procedure to enable hot backups of a Camunda Platform 8 installation. This is an important feature towards rolling updates of the system and lower downtimes. As Camunda Platform 8 includes multiple independent systems which all have their own data set representing the current state of the system, it is important to ensure the backup is captured in a way that keeps the data consistent. The core workflow engine Zeebe is already a distributed system with replication which adds additional challenges to creating a consistent backup. As part of the preparation for delivering the hot backups feature, a technical concept was created to describe the solution of hot backups in Zeebe, which can be found here.
How to Get it
You can access Zeebe, Operate, and Tasklist 8.1.0-alpha3 directly in Camunda Platform by selecting the alpha channel when creating a new cluster. Visit Camunda Platform docs for more information.
The releases for Zeebe Engine, Operate, and Tasklist are also now available on GitHub for your access. As this is an alpha release, we don’t offer updates from later software versions.