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.
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.
To define that a dataElement can be claimed, add the option isClaimable.
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);
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.
|201812||188.8.131.52||Implemented different implementation for DB2 z/OS|