Working with Waveset Wizards

Sometimes automating a process requires a wizard. A wizard is a multi-step GUI operation where each step presents the user with a page used to capture or display data. Waveset provides two techniques for building a wizard:

• Form-Based wizards. These wizards use form processing to change what the user sees, allowing sets of fields to be visible or invisible based on data held in the view.

• Workflow-Based wizards. These wizards require task execution and suspension to provide page transitions.

A Form-Based wizard is four-times more efficient than the best Workflow-Based wizard. Workflow-Based wizards can vary by up to 10x in performance, depending on how they are constructed. Wizard efficiency is typically not noticeable until many wizards are run concurrently.

Because view processing does not necessarily require object repository access, a single Waveset server can process many Form-Based wizards concurrently without contention. However, Form-Based wizards are limited in what they can do between steps. The only processing these wizards can perform between steps is done by normal form or view processing. Form derivation and expansion, which are done when the view is being refreshed, is more limiting than the processing that is possible in a workflow. If a Form-Based wizard's processing limits preclude its use, you must use a Workflow-Based wizard. However, you should consider using a Form-Based wizard first.

Because Workflow-Based wizards require task execution and suspension to provide page transitions, and because each page in a Workflow-Based wizard corresponds to a workflow ManualAction object, these wizards are less efficient than Form-Based wizards. A problem occurs when the wizard has hundreds of concurrent invocations because all of the task start, suspend, and resume operations must contend for the object repository task table.

The object repository is being accessed synchronously with each HTTP request; consequently, a Workflow-Based wizard does not scale to large numbers of concurrent executions due to repository contention. Each start, suspend, and resume operation involves several reads and writes to the task table in the repository, and under a large concurrent load results in the page-to-page response of the GUI slowing down. Unlike a Form-Based wizard that scales by adding more Waveset servers and balancing the HTTP load between them, Workflow-Based wizards slow down due to repository contention. Adding more Waveset servers actually makes the problem worse because the repository is shared between all servers.

If you must use a Workflow-Based wizard because you need processing between page transitions, consider using transient ManualAction. A ManualAction in a Workflow-Based wizard is the mechanism used to display pages to the user. A five-step wizard typically has at least five ManualActions.

If you construct the wizard so that the user must either complete or abort the entire flow, then you can mark the ManualActions with the transient='true' attribute. Adding this attribute allows Waveset to bypass the repository instead of keeping the task in memory and sequencing it without accessing the object repository. This construction decreases the load the wizard puts on the repository, allowing it to scale to higher concurrency loads. However, using this attribute has some drawbacks. If you set transient to true (it is false by default), you cannot restart the workflow after the task enters the transient section because the in-memory state of the workflow does not match the repository state. Also, each HTTP request for the wizard must use the same server because the true state of the wizard is now only kept in memory on the initiating server. As soon as Waveset encounters a ManualAction with transient=false, Waveset writes the workflow to the repository normally, and normal workflow behavior resumes.

Consider using a Workflow-Based wizard with the following structure:

Begin Activity 1 
ManualAction 1 (transient = true) 
Activity 2 
ManualAction 2 (transient = true) 
ManualAction 3 (transient = true) 
ManualAction 4 (transient = true) 
ManualAction 5 (transient = false) 
Activity 3 
... 

When launched, this wizard creates a task that is initially stored in the object repository. All processing between ManualAction 1 and ManualAction 5 is done without any further repository work (the transient section). When Waveset executes ManualAction 5, the task is again stored in the repository (normal behavior), which is a significant performance savings because each normal suspend/resume for a ManualAction does the following:

1. Creates and stores a WorkItem

2. Saves the task state

3. Reads/writes the WorkItem

4. Locks the task

5. Resumes the task

6. Deletes the WorkItem

Each suspend/resume pair (when in wizard mode) results in more than 20 repository read/writes, all on the task table. The state of the task in the repository is running, so if the server crashes or shuts down during the execution of the wizard, the task will be deleted from the repository within a few minutes by another server or when the crashed server restarts, whichever comes first.

If you use a transient ManualAction, you can observe the effects by looking at the JMX TaskInstanceCache and WorkItemCache MBeans. These MBeans show the number of Store (repository write) operations compared to Cache (memory only) operations occurring. Each Cache operation means a Store was avoided, thus reducing object repository contention.