Data Element Claims

The claiming mechanism is used to make it easier for engines to work in parallel. The workflow engine can claim an instance of a data element so that other engines cannot work on the same instance.

If configured with the useClaims option, an engine will try to find unclaimed instances when starting a batch. Retrieving the instances will also automatically add a claim for each instance in an atomic way. This way, no instance can be claimed by two engines at the same time.

Claim dataElement

These claims are stored in a separate ‘Claim’-dataElement. It is possible to define a ‘Claim’-dataElement for each dataElement or to use one ‘Claim’-dataElement per component or even application.

An extra button has been added to the dataElements tab on the component page to create a new ‘Claim’-dataElement. This creates a dataElement with option isClaimElement and the correct fields.

Claimable dataElements

To define that a dataElement can be claimed, add the option isClaimable.

Claim id

Claims are marked by a ClaimId, to link it to the owner of the claim. Claims can be based on a runId:

ClaimId claimId = ClaimId.fromRunId(runId);

or on a userContext:

ClaimId claimId = ClaimId.fromUserContext(userContext);

Known problems

Context loss from using agents

Note that the Cruds class will prevent all modifications on claimed instances by processes that do not provide the correct runId or userContext (if claimed with that runId or userContext). Previous implementations of the agent classes did not pass the enough context information for runId’s to be passed to the data layer.

This means that tasks that use agents to modify their target instances will fail. To solve this, create the agents by using the Context class:

Context context = targetParameter.getContext();
// ...
InvoiceLocalAgent invoiceAgent = InvoiceLocalAgent.getInvoiceAgent(context);

This way, the agent will pass the TaskProcessingContext of the workflow that contains the runId of the workflow.

This problem does not occur with tasks executed by a user on instances claimed by that user, since the userContext was passed correctly.

Implementation for DB2 z/OS

The standard expanded implementation might not work on a DB2 z/OS database. To avoid issues, set the target database to DB2_ZOS in the Business Logic Settings.

This will generate a lightly different query, which explicitly casts the parameters in the query to their specific types.


Release Expander version Change
201712 3.2.0 Introduced claims
201812 Implemented different implementation for DB2 z/OS