Runtime Considerations for Votable Tasks
Regardless of the user interfaces that a task developer creates for a votable task type, task assignees are presented with certain voting options, each corresponding to one of the following task statuses:
For tasks in status Active, possible transitions are to statuses Suspended, Cancelled, Completed, and Error
For tasks in statuses Expired and Suspended, possible transitions are to statuses Active and Error.
Depending on the voting strategy that a task developer configures and the number of runtime assignees for a task, some task instances might never meet the requirements for transitioning to one of the available statuses. In such situations, task type developers can modify the strategy and redeploy the task type, or Task Engine administrators can manually change the status of the task at runtime.
For example, a task instance from a type which is configured with a voting threshold of 60% and provides two voting options, gets assigned to a group of ten individual users. If five users select one of the voting options, and the other five select the other, the voting threshold is never reached and the task instance cannot transition to any of the configured statuses. Such tasks require manual intervention by an administrator, or a modification in the voting strategy. Runtime users with the appropriate permissions can monitor task voting statistics, and take actions when a task instance cannot reach a final status through voting.
The following considerations apply when modifying the voting strategy for a task type:
The modified voting strategy for the task type applies to instances, queued after redeployment.
Existing task instances can be updated to the modified strategy by manually triggering vote recalculation.
When recalculating task vote according to the new voting strategy,
Task Engine also recalculates the number of users in groups and roles.
Some task instances might transition to a new status as a result from the recalculation.
When updating the status of a task as a result from vote recalculation,
Task Engine places the task in the first status that reaches the percentage threshold by timestamp.
Task type developers can enable voting in existing task types, created with the current (or later) version of Designer. By default, all task instances queued after the redeployment of the modified task type will be enabled for voting with the configured strategy. Instances of the type that were available in the runtime before redeployment cannot be enabled for voting. The same consideration applies to task types, that were initially enabled for voting. If you modify the task type, voting will remain enabled for each instance, queued before you make the change and redeploy the task type, until the instance gets completed or reaches another terminal state. All new instances, queued after you redeploy the task type will be enabled for voting.
Software AG recommends that redeployment of task types with voting modifications and vote recalculation are executed during scheduled maintenance windows.
For more information about recalculating task votes and handling voting issues at runtime, see webMethods Task Engine User’s Guide.
For more information about task statuses, see
About Task Status.