This chapter describes how to query for specific criticality aspects, how specific activity processing influences the recalculation of activity criticality and how the recalculation behavior can be controlled.
To retrieve the current criticality of an activity instance,
use the method getCriticality of the
ActivityInstance object.
/**
* Returns the current criticality of an activity instance
*
* @return the value if the criticality
*/
double getCriticality();
The ActivityInstanceQuery and the WorklistQuery provide the following query functionality for criticality:
Sorting and filtering for criticality attributes is possible through the filterable
CRITICALITY attribute of the
ActivityInstanceQuery and the
ACTIVITY_INSTANCE_CRITICALITY attribute of the
WorklistQuery. Those can be added to the queries as
in following example:
ActivityInstanceQuery query = ActivityInstanceQuery.findAlive();
query.where(ActivityInstanceQuery.CRITICALITY.greaterOrEqual(limit));
ActivityInstances ais = qrService.getAllActivityInstances(query);
WorklistQuery wQuery = WorklistQuery.findCompleteWorklist();
wQuery.where(WorklistQuery.ACTIVITY_INSTANCE_CRITICALITY.between(0, 1));
Worklist wList = wfService.getWorklist(wQuery);
The following use cases results in recalculation of the activity criticality:
When you create a new activity, the initial activity criticality value is calculated using the javaScript formula for the model containing the current activity and the corresponding algorithm.
Whenever you change the priority for the process instance containing the current activity, the activity criticality is recalculated and stored analogously. The following methods to change process priority result in a reevaluation of the dependent activity criticality:
ProcessInstance setProcessInstancePriority(long oid, int priority) ProcessInstance setProcessInstancePriority(long oid, int priority, boolean propagateToSubProcessesRefer to chapter Changing Process Instance Priorities for details on these methods.
PROCESS_PRIORITY data.
This data contains the priority assigned to the current process.Set Data event actions of the predefined
PROCESS_PRIORITY data.Activity criticality is recalculated whenever any of the following
suspend()-methods of the
WorkflowService is called:
suspend()suspendToDefaultPerformer()suspendToParticipant()suspendToUser()The recalculation behavior can be configured with the following Preferences keys within the Preference store:
Criticality.Recalc.OnSuspend
- determines if recalculation should take place when process data
is modified via a suspend method as described in section
Modifying Process Data via suspend().Criticality.Recalc.OnCreate
- determines if recalculation should take place when a new activity
is created as described in section
Activity creation.Criticality.Recalc.OnPriorityChange
- determines if recalculation should be done on priority change as
described in section Changing Process Priority.These keys can be used to specify whether criticality should be reevaluated for the following use cases or not:
The scope for the preferences is PARTITION, the module id is engine-internals and the preference id is workflow-criticalities. To change the preferences accordingly:
Preferences getPreferences("PARTITION","engine-internals", "workflow-criticalities");void savePreferences(Preferences preferences);
Refer to section Retrieving preferences from a given scope and Saving Preferences of chapter Retrieving and Changing Preferences respectively for details on getting and saving preferences methods of the AdministrationService.
Per default, the log level for criticality evaluation is INFO. If you prefer criticality evaluation
info messages to be displayed with the default warning level configuration, you can change the log configuration to
WARN. Please refer to chapter Logging
for details on how to configure log levels.