Batch operations
The following operations can be executed asynchronously
- Process Instance Migration
- Cancellation of running Process Instances
- Deletion of Historic Process Instances
- Update suspend state of process instances
- Setting retries and due dates of jobs using the builder pattern
- Setting retries of jobs associated with Process Instances
- Process Instance Modification
- Process Instance Restart
- Setting retries of external tasks
- Set Variables to Process Instances
- Correlate Messages to Process Instances
- Set a Removal Time to Historic Process Instances
- Set a Removal Time to Historic Decision Instances
- Set a Removal Time to Historic Batches
All batch operations rely on corresponding methods that provide the possibility to operate on a list of entities synchronously. Please refer to the general Batch documentation to understand the creation process better.
Asynchronous operations can be performed based on a list of specific instances as well as on the result of a query providing a resulting list of instances. If both a list of instances and a query are provided, the resulting set of affected instances will consist of the union of those two subsets.
All listed batch operations, except Set a Removal Time to Historic Batches, are deployment-aware.
In particular, this means that the seed job and execution jobs will receive a deploymentId
so
deployment-aware job executors
can pick up those jobs of a batch that need to be executed on their nodes.
The deployment id of the seed job is chosen from the list of involved deployments.
This list is derived from the resulting set of affected instances.
Execution jobs only contain elements of the same deployment and are bound to that deployment’s id.
Cancellation Of Running Process Instances
Cancellation of running process instances can be performed asynchronously using the following Java API method invocation:
List<String> processInstanceIds = ...;
runtimeService.deleteProcessInstancesAsync(
processInstanceIds, null, REASON);
Deletion Of Historic Process Instances
Deletion of historic process instances can be performed asynchronously using the following Java API method invocation:
List<String> historicProcessInstanceIds = ...;
historyService.deleteHistoricProcessInstancesAsync(
historicProcessInstanceIds, TEST_REASON);
Update Suspend State Of Process Instances
Update the suspension state of multiple process instances asynchronously using the following Java API method invocation:
List<String> processInstanceIds = ...;
runtimeService.updateProcessInstanceSuspensionState().byProcessInstanceIds(
processInstanceIds).suspendAsync();
Setting retries and due dates of jobs using the builder pattern
Setting retries of jobs can be performed asynchronously using a builder. There are two general ways to reference jobs: by job ids/job queries or by process. Here are demonstrations of how to use both APIs:
managementService.setJobRetriesByJobsAsync(retries)
.jobIds(myJobIdList)
.jobQuery(myJobQuery)
.dueDate(myDueDate)
.executeAsync();
managementService.setJobRetriesByProcessAsync(retries)
.processInstanceIds(myProcessInstanceIdsList)
.processInstanceQuery(myProcessInstanceQuery)
.historicProcessInstanceQuery(myHistoricProcessInstanceQuery)
.dueDate(myDueDate)
.executeAsync();
Setting Retries Of Jobs Associated With Process Instances
Setting retries of jobs associated with process instances can be performed asynchronously using the following Java API method invocation:
List<String> processInstanceIds = ...;
int retries = ...;
managementService.setJobRetriesAsync(
processInstanceIds, null, retries);
Setting Retries Of External Tasks
Setting retries of external tasks can be performed asynchronously using the following Java API method invocation:
List<String> externalTaskIds = ...;
externalTaskService.setRetriesAsync(
externalTaskIds, TEST_REASON);
Set Variables to Process Instances
Sometimes it is necessary to add or update data of an already running process instance. For example, when a user entered incorrect data at the beginning of a process, the data needs to be corrected on-the-fly.
This batch operation helps you to set variables to the root scope of process instances asynchronously.
You can either (1) filter for process instances using a HistoricProcessInstanceQuery
or a ProcessInstanceQuery
or (2) pass a set of process instance ids directly.
Please see below how to call the Java API:
List<String> processInstanceIds = ...;
Map<String, Object> variables = Variables.putValue("my-variable", "my-value");
runtimeService.setVariablesAsync(processInstanceIds, variables);
Known limitations
Currently, it is not possible to set transient variables via batch operation. However, you can set transient variables synchronously.
The execution jobs of this batch can be scheduled by the job executor as exclusive jobs. As a result, the execution of some of this batch’s jobs may be delayed by other exclusive jobs that are related to the same process instance that the variables should be set to. However, exclusive scheduling only happens when the jobs of this batch relate to exactly one process instance. This can be controlled by configuring the invocationsPerBatchJob property.
Correlate Messages to Process Instances
This batch operation helps you to correlate messages to multiple process instances asynchronously. Furthermore, you can set variables to the root scope of those process instances as well.
You can either (1) filter for process instances using a HistoricProcessInstanceQuery
or a ProcessInstanceQuery
or (2) pass a set of process instance ids directly.
Please see below how to call the Java API:
List<String> processInstanceIds = ...;
Map<String, Object> variables = Variables.putValue("my-variable", "my-value");
Batch batch = runtimeService.createMessageCorrelationAsync("myMessage")
.setVariables(variables)
.processInstanceIds(processInstanceIds)
.correlateAllAsync();
Known limitations
It is not possible to correlate to process definition-level start message events via this batch operation. However, you can correlate to start messages synchronously.
The execution jobs of this batch can be scheduled by the job executor as exclusive jobs. As a result, the execution of some of this batch’s jobs may be delayed by other exclusive jobs that are related to the same process instance that the message should be correlated to. However, exclusive scheduling only happens when the jobs of this batch relate to exactly one process instance. This can be controlled by configuring the invocationsPerBatchJob property.
Set a Removal Time
Sometimes it is necessary to postpone or even prevent the deletion of certain historic instances. A removal time can be set asynchronously to historic processes, decisions and batches.
The following modes can be chosen:
- Absolute: Sets the removal time to an arbitrary date
.absoluteRemovalTime(Date removalTime)
- Cleared: Resets the removal time (represented as
null
-value); Instances without a removal time are not cleaned-up.clearedRemovalTime()
- Calculated: Recalculates the removal time based on the Workflow Engine’s settings (base time + TTL)
.calculatedRemovalTime()
Historic process and decision instances can be part of a hierarchy. To set the same removal time for all instances within
a hierarchy, the method .hierarchical()
needs to be called.
Setting removal time to running process instances would delete data from historic database tables (i.e. tables starting with ACT_HI_*
), but not from runtime database tables (i.e. tables starting with ACT_RU_*
).
Historic Process Instances
HistoricProcessInstanceQuery query =
historyService.createHistoricProcessInstanceQuery();
Batch batch = historyService.setRemovalTimeToHistoricProcessInstances()
.absoluteRemovalTime(new Date()) // sets an absolute removal time
// .clearedRemovalTime() // resets the removal time to null
// .calculatedRemovalTime() // calculation based on the engine's configuration
.byQuery(query)
.byIds("693206dd-11e9-b7cb-be5e0f7575b7", "...")
// .hierarchical() // sets a removal time across the hierarchy
.executeAsync();
Historic Decision Instances
HistoricDecisionInstanceQuery query =
historyService.createHistoricDecisionInstanceQuery();
Batch batch = historyService.setRemovalTimeToHistoricDecisionInstances()
.absoluteRemovalTime(new Date()) // sets an absolute removal time
// .clearedRemovalTime() // resets the removal time to null
// .calculatedRemovalTime() // calculation based on the engine's configuration
.byQuery(query)
.byIds("693206dd-11e9-b7cb-be5e0f7575b7", "...")
// .hierarchical() // sets a removal time across the hierarchy
.executeAsync();
Known limitation
The .hierarchical()
flag for the decision instances batch operation only sets the removal time within the decision
hierarchy. If a decision was called by a Business Rule Task, the calling process instances (including other process
instances that are present in the hierarchy) are not updated.
To update all child instances along the hierarchy of a root process instance (all process as well as decision instances),
please use the batch operation for process instances with the .hierarchical()
flag enabled.
Historic Batches
HistoricBatchQuery query = historyService.createHistoricBatchQuery();
Batch batch = historyService.setRemovalTimeToHistoricBatches()
.absoluteRemovalTime(new Date()) // sets an absolute removal time
// .clearedRemovalTime() // resets the removal time to null
// .calculatedRemovalTime() // calculation based on the engine's configuration
.byQuery(query)
.byIds("693206dd-11e9-b7cb-be5e0f7575b7", "...")
.executeAsync();