Tuning Configurable XML Objects

Configurable XML objects offer a broad spectrum of user interface specifications that enable you to define how data is presented to users for different tasks and to automate complex business processes. However, this same flexibility can affect efficiency, performance, and reliability.

This section describes some guidelines for tuning Waveset’s configurable XML objects, which consist of forms, rules, and workflows. The information is organized into the following sections:

• Tuning Forms

• Tuning Rules

• Tuning Workflows

Tuning Forms

You can use Waveset forms to define interfaces to interact with views or variable contexts in an executing task. Forms also provide an execution context for business and transformation logic on a set of data elements. Although you can create very powerful, dynamic forms that perform a variety of tasks, reducing the complexity of forms increases efficiency.

The following sections describe some methods for improving the performance of your customized forms:

• Optimizing New Forms

• Optimizing Administrator Forms

• Optimizing End-User Forms

• Optimizing Expressions in Form Fields

Optimizing New Forms

When designing new Waveset forms, system integrators can optimize a form’s performance by doing the following:

• Performing “expensive” queries only one time, wherever possible. To minimize these queries,

  • Use <Field> <Default> elements to execute and store query results.

  • Use field names to reference values in later fields.

  • For custom tasks

    • Calculate the value in the task before a ManualAction, then store that value in a task variable.

    • Use variables.tmpVar to reference variables in the form.

    • Use <setvar name=’tempVar’/> to clear the variable after a ManualAction.

• Using <defvar> for calculations that are performed for the initial display and with each refresh.

Optimizing Administrator Forms

To improve the performance of administrator forms, do the following:

• Specify TargetResources that only fetch specific resources for editing. (See Tuning Workflows for more information.)

• Use cacheList and cacheTimeout caching parameters for objects that change infrequently if you are working with FormUtil.getResourceObjects or FormUtil.listResourceObjects.

• Store the results of time-consuming calculations and fetches in <Field> elements and evaluate in the <Default> expression to help ensure that an operation occurs only one time.

• Use update.constraints to limit which resources are fetched at runtime (see Dynamic Tabbed User Form in Oracle Waveset 8.1.1 Deployment Reference).

• Use background approval (ManualAction with different owners and one-second timeouts) for faster page submissions.

• Be aware that Waveset refreshes all fields defined on all panels of a Tab Panel Form when the page reloads, regardless of which panel is selected.

Optimizing End-User Forms

To improve the performance of end-user forms, do the following:

• Use TargetResources to limit view checkouts to just those resource accounts of interest, which reduces fetch time for view and the memory consumed by TaskInstance and WorkItems.

• Consider using Session.getObject(Type, name) to return a WSUser if just the view properties and attributes of the Waveset user object are of interest (useful for managing multiple deferred task triggers).

• Be aware that end-user tasks typically have more WorkItems than Provisioning tasks, so end user tasks are especially susceptible to WorkItem size.

• Consider using temporary generic objects for “view” editing that is constructed on view check-out then merged back into a full view for check-in.

• Consider using scalable forms instead of the default Create and Edit User interfaces.

  When you use the default User forms to edit a user, Waveset fetches the resources owned by that user the moment you start editing the user’s account. In deployment environments where users have accounts on many resources, this potentially time-intensive operation can result in performance degradation.

Optimizing Expressions in Form Fields

Some activities performed in forms call resources that are external to Waveset. Accessing these resources can affect Waveset performance, especially if the results contain long lists of values, such as compiling a list of groups or email distribution lists.

To improve performance during these calls, follow the guidelines in “Using a Java Class to Obtain Field Data” in Oracle Waveset 8.1.1 Deployment Reference.

Also, avoid using JavaScript in performance-critical expressions such as <Disable> expressions. Short XPRESS expressions are easier to debug if you use the built-in tracing facilities. Use JavaScript for complex logic in workflow actions.

If a form is slow to display, you can use the debug/Show_Timings.jsp page to determine the problem. Look for calls to Formconvert.convertField(). This method shows how long each field took to compute its value.

You can use the FormConverter JMX MBean to identify specific fields in a form that are slow to compute or render to HTML.

Tuning Rules

You use Waveset rules to encapsulate constants and XPRESS logic that can be reused in forms, workflows, and other configurable components in the product.

When writing rules, use the following guidelines (as applicable) to obtain optimal performance:

• Use static declarations to return a constant value.

• Use defvar methods to implement algorithms with temporary values for incremented values or for values that are referenced only one time.

• Use putmap, setlist, or setvar methods for complex or expensive calculations whose value must be returned multiple times. Be sure to eventually set the value to <null>.

You can use the Rule JMX MBean to identify rules that are executing slowly.

Tuning Workflows

You customize Waveset workflows to facilitate and automate complex business processes with various human and electronic touchpoints.

You can use the following methods to improve custom workflow performance:

• Simplify default workflows to improve processing time (especially for bulk processing actions such as Active Sync, bulk actions, and reconciliation) by removing the callout to the Approval subprocess.

• Ensure that no infinite loops exist in your workflows. In particular, be sure that break flags are updated and properly checked in the loops that exist in approval subprocesses.

• Put fetched objects into a variable for use later if you must contact the repository for the same object multiple times.

  Using a variable is necessary because Waveset does not cache all objects.

• Specify TargetResources options in WorkflowServers checkoutView to restrict the number of resources that are queried for account information.

  The following example shows how to restrict the number of resources being queried for account information.

  <Argument name=’TargetResources’> <list> <string>resource name[| #]</string> </list> </Argument>

  ---

  Note –

  In the preceding example, [| #] is an optional parameter that you can use when more than one account exists on a particular resource. In most cases, the resource name is sufficient.

  ---

• Clear unnecessary view variables left by forms, especially large maps and lists. For example:

  <setvar name=’myLargeList’></null></setvar>

  The view is copied multiple times in a TaskInstance object, so large views greatly increase the size of each TaskInstance and corresponding TaskResult.

• Use resultLimit (in seconds) in the TaskDefinition, or set this option during task execution to quickly dispose of completed tasks. Large numbers of TaskInstances impact the following:

  • How taskResults.jsp in footers and some JSP tasks in the Administrator interface are displayed

  • How JSP tasks are displayed

  • Querying each TaskInstance for task renaming

  • Database size

  Set the following options as needed:

  • (Preferred selection) delete — Causes an older TaskInstance of the same name to be deleted before the new task begins execution.

  • wait — Suspends the current TaskInstance until the older TaskInstance is deleted or expired due to reaching its resultLimit.

  • rename — Inserts a time stamp into the TaskInstance name to avoid naming collisions.

  • terminate — Deletes an older TaskInstance of the same name. Each currently executing TaskInstance of the same name is terminated.

  ---

  Note –

  Using the SaveOnlyOnError attribute (see the following description) with the resultLimit attribute can significantly improve performance.

  ---

• Use the SaveOnlyOnError attribute in TaskDefinitions and TaskInstances to configure a task that is persisted only when errors or warnings occur.

  • If you set SaveOnlyOnError to true, and the resultLimit value is non-zero, Waveset persists the task if there is an error or a warning. If the resultLimit value is 0, Waveset will not persist the task, even if an error or warning occurs.

  • If you set SaveOnlyOnError to false, Waveset just considers the resultLimit value. (The default value is false.)

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).