Tuning WorkItems (ManualActions)

The number and size of WorkItems (indicated by ManualActions in a workflow) can affect memory and system performance significantly. By default, Waveset copies an entire workflow context into a WorkItem, then writes the workflow context back out after submission.

To improve performance for WorkItems and ManualActions do the following:

• Reduce the size of WorkItems.

  By default, ManualAction creates a WorkItem, then copies each variable in the task context into WorkItem.variables. Limiting task context variables prevents overwrites from parallel approvals.

  • Use ExposedVariables to limit which variables are copied back into WorkItem. For example:

    <ExposedVariables><List><String>user ...

  • Use EditableVariables to limit the variables assimilated back into the executing task from WorkItem. For example:

    <EditableVariables><List><String>user ...

    Remember to include an approval flag, a form button value, and the actual approver’s name.

• Change the confirmation page and background processing to improve user interface response time.

  • Create a confirmation ManualAction or background ManualAction, owned by another user such as Configurator.

  • Set timeout=’-5’ (5 seconds) and ignoreTimeout=’true’ to prevent an error message if a user submits an action after the task is executed and the WorkItems are deleted.

• Optimize memory use by setting large attribute values, such as value maps and lists, to null on submission or instantiate them as Activity-scoped variables that quickly pass out of scope.

• Shorten the lifetime of finished tasks.

  • Prevent dead-end tasks by ensuring that each WorkItem specifies a Timeout and that the workflow anticipates a Timeout for each WorkItem.

  • Consider using the resultLimit and resultOption options in the TaskDefinition to determine how the Scheduler handles a task after the task completes.

    • Use resultLimit to control how many seconds a task is allowed to live after the task has completed. The default is zero (0), which means that the task instance will be deleted immediately after task completion.

    • Use resultOption to specify what action to take when repeated instances of a task are started (such as wait, delete, rename, or terminate). The default is delete.

      If you want to immediately delete tasks that complete successfully, but you also want to keep tasks containing errors long enough to debug, you can conditionally delete finished tasks.

      Set a resultLimit in the TaskDefinition to a sufficient time period to debug issues. You can set resultLimit to zero (or a small value) if no errors are reported at runtime (such as WF_ACTION_ERROR is <null/>) after a WorkflowServices call.

• Evaluate and fix poorly scoped variables. Scope variables according to where they are declared, as follows:

  • Global variables are values that must be used across many activities (such as the case owner, view) and as approval flags in subprocesses.

    If a variable is declared as an element of <TaskDefinition>, scope the variable globally. If a variable is declared external, its value is resolved up the call stack.

  • Activity variables of expensive values (such as those variables that require a resource fetch or that store a large list or map of values) can be referenced in a WorkItem.

    If a variable is declared as an element of <Activity>, ensure that the variable is visible to actions and transition elements in Activity.

    ---

    Note –

    Beginning with Waveset Version 2005Q3M1 SP1, use <Activity> variable values in Forms, rather than in workflows, to avoid copying values on WorkItem creates.

    ---

  • Activity variables are values used in transition logic.

    If a variable is declared as an element of <Action>, the variable should pass out of scope on completion of the action. Action variables are typically used in WorkflowApplication invocations to “change” the names of variables set by the application (such as View -> User).

• Do not specify synchronous execution (syncExec='true') for the last page in a wizard workflow.

  If set to true, the task will run to completion when the user executes the task. The interface will hang until the task completes or encounters another stopping point (such as another ManualAction).

• Remove unnecessary approval checks.

  ---

  Note –

  For Active Sync, use a streamlined provisioning task in place of the system-specified provisioning task specified by viewOptions.Process.

  ---

• Do not modify the provisioning tasks provided with Waveset.

  You must create a new task, then identify that task in the form and in the process mappings configuration (unless the task is not listed).