Declarative task-based user interfaces

In one embodiment, a method for building wizard-style user interfaces (UIs) for a business task includes identifying a collection of metadata associated with the business task, and processing the collection of metadata to provide a set of wizard-style UIs pertaining to the business task.

FIELD OF THE INVENTION

Embodiments of the present invention relate generally to business process modeling, and more particularly to providing a declarative tool for creating wizard style user interfaces for a business task.

BACKGROUND OF THE INVENTION

Business applications allow end users to perform business tasks via designated user interfaces (UIs) or views. With some business applications, end users cannot effectively interact with the UI views unless they understand the logic behind each UI view and how the UI views relate to each other. As a result, end users typically have to go through extensive training before they can start working with the designated UI views.

An expense associated with training can be minimized through the use of an additional tool known as a UI wizard. The UI wizard guides end users through different views, using step-by-step dialogs. The development of a UI wizard is usually done using a procedural or object-oriented programming language by experienced software developers that have thorough understanding of the underlying business logic. If the business logic changes, the wizard code needs to be modified, and then shipped to the customers with a new product release.

SUMMARY OF THE INVENTION

The present invention relates to various aspects of building wizard-style user interfaces (UIs) for a business task.

According to one aspect of the present invention, an exemplary method includes identifying a collection of metadata associated with a business task, and processing the collection of metadata to provide a set of wizard-style UIs pertaining to the business task.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention relate to various aspects of building wizard-style, guided user interfaces (UIs) for accomplishing business tasks. A business task may support a variety of different processes including, for example, filling out objectives, applying for a loan, conducting a survey, qualifying a lead, approving expense reports, etc. Exemplary problems solved by a task may be as follows:multiple step transactions that require several independent actions to be completed (or rolled back) as a unit (e.g., balance transfers that credit one account and debit another);complex multiple step activities (e.g., setting up new user accounts with roles, security and profile information);multiple step activities dependent on regulatory business logic (e.g., customer authorization steps, acknowledgement of required disclosures, quoting complex products with configuration rules and validation requirements);data creation activities requiring data quality and duplicate checking (e.g., service requests from gold customers requiring a committed resolution time within 24 hours and scheduling of a call back activity);decision processes requiring branching logic to determine the appropriate sequence of activities (e.g., presentation of available upgrade or upsell products to a customer based on geography and current products owned by the customer);guidance or scripting to assist a user during a live interaction when real-time decision making, presentation of supporting information (text and/or graphic) and a consistent message is critical to a successful interaction (e.g., walking a customer through a live portfolio analysis and offer presentation, informing the customer of the sales team that will be handling their inquiry).

The wizard-style task UI is a sequence of task specific UI views that lead an end user to perform process-centric work that may include applying business logic, evaluating conditional fields, external system integration, etc. The result is an improved end-user experience with shorter learning curves and higher task completion rates.

FIG. 1is a block diagram of one embodiment of a system for building wizard-style UIs for business tasks. The system includes a task UI development tool102, a metadata repository106and a runtime engine108.

The task UI development tool102is a declarative tool that allows intermediate users104(e.g., business analysts, software developers, etc.) to design wizard-style UIs for business tasks without writing any code. The tool102enables intermediate users104to specify steps of a business task and the execution flow for the steps. The steps may include, for example, UI view steps, database operation steps, decision steps, service (external and/or internal) invocation steps, etc. The tool102may be a graphical editor that allows an intermediate user104to create a visual representation of a task that reflects the task steps and their execution flow. In one embodiment, the visual representation of the task is in the form of a flowchart that includes a sequence of steps to be performed for the business task. In one embodiment, the tool102enables a intermediate user104to define navigation controls for UI view steps of the task. These navigation controls may include, for example, Next/Previous buttons, Pause button, Cancel button, etc.

In one embodiment, the tool102also allows an intermediate user104to specify properties for the task. These properties may include task-level properties defining characteristics of the task (e.g., the name of the task, transactional behavior, etc.) and step-level properties defining characteristics of individual steps (e.g., fields to be entered by an end user for a UI view step, database fields to be updated for a database operation step, branching conditions for a decision step, the name of a service to be called for a service invocation step, etc.). An exemplary UI illustrating the operation of one embodiment of the tool102will be discussed in more detail below in conjunction withFIG. 1B.

In one embodiment, the tool102converts the visual representation of the task and the task properties into a collection of metadata and stores the resulting collection of metadata in the metadata repository106. In one embodiment, the metadata is represented using an XML document based on an XML schema.

The runtime engine108deploys, at runtime, task metadata stored in the metadata repository106and processes the task metadata to produce a set of wizard-style UIs. The wizard-style UIs are presented to end users112by task UI applications110. The end users112may be connected or disconnected mobile users. In one embodiment, mobile end users launch and run while operating in disconnected mode. When the end user is connected, any data resulting from completed tasks is synchronized back to the server.

In one embodiment, the runtime engine108provides navigation support for walking end users112through UI sequences. In particular, end users can progress through tasks by entering data in the UI view and pressing the Next button to move to the next view. End users can also navigate backward in the task (Previous button), modifying previously entered data if desired, then navigating forward again via the Next button. In one embodiment, at the last step in the task, an end user112can use the Submit button to commit the task data to the main database tables.

In one embodiment, the runtime engine108performs business operations and dynamically controls view sequencing as the task progresses. This allows the execution of the flow to be dynamically modified based on data entered by the end user112during the task. The runtime engine108can support several types of operations, including, for example, database accesses, business service calls, and decision steps. Since these operations are performed automatically by the runtime engine108, rather than by an explicit user actions such as button presses, the end user112no longer needs to know when to press particular buttons or in which order.

In one embodiment, changes to business data made as part of a task are not committed to the main database until the end-user has successfully completed the task. New and modified data is kept separate from the main database data and is visible only while the task is executing and only to the end user running the task. When the end user completes the task, all data is committed to the main database and made visible to other users in the enterprise.

In one embodiment, the runtime engine108allows an end user112to pause a task (e.g., using the Pause button) and resume it at a later time. In one embodiment, paused tasks are displayed in the user's Inbox. The Inbox may support resuming paused tasks and transferring tasks to other users. Once the task is transferred, it appears in the Inbox of the user it was transferred to.

In one embodiment, the runtime engine108allows an end user112to cancel the task (e.g., using the Cancel button) being run by reverting all changes made during the current session and restoring the task to its last paused state. In one embodiment, a task can be deleted entirely from the Inbox, discarding all the work done in the task.

In one embodiment, tasks may operate either as standalone entities, or as an integral part of an overarching business process. For example, a Change Contact Address task is a standalone task because it is a self-contained unit of work initiated by the end user. Another exemplary standalone task initiates a business process upon its completion. For example, a Create Expense Report task may initiate a business process for approving the expense report and paying the expenses. Yet another exemplary standalone task may be embedded in the business process as a Task Step. The Task Step may assign a task to an end user by placing an entry in the user's Inbox where the user can launch it. The business process may wait until the end-user runs and completes the task, at which point the business process would be resumed.

FIG. 1Billustrates an exemplary UI130provided by a task UI development tool according to one embodiment of the present invention.

Referring toFIG. 1B, the UI130contains several areas including a task palette area134, a working area132and a property window136. The area134displays a list of different shapes representing various types of task steps and connectors for connecting the steps. Various task step types may include, for example, a task UI view, a database operation, a business service invocation, a decision point, a commit step, an error step, a start step, an end step, and a subtask step. A subtask step executes a subtask, i.e., a portion of a task that was factored out for reuse in other tasks.

An intermediate user can select shapes for desired task steps, drag them to the working area132, and connect them as needed in the working area132, creating a flowchart. The property window136allows the intermediate user to specify properties for the task and individual steps.

FIG. 1Cillustrates an exemplary UI150from a wizard-style sequence of task UIs, according to one embodiment of the present invention.

Referring toFIG. 1C, the UI150contains a main area152that presents the task view called “Review Address & Details.” The task view includes one or more applets consisting of UI controls showing the specific presentation for the current step in the task. At the top of the task view is a set of navigational controls160that include the Pause, Previous, Next, and Cancel buttons.

A current task area154displays the current state of the task, including the task name, chapters156in the task, and the names of view steps in the current chapter, including the view step158that is being presented in the main area152. Chapters156provide visible division of tasks into groups of steps. In one embodiment, using chapters frees screen space by hiding view steps visited outside of the current chapter. In one embodiment, end users can expand and collapse chapters to see and hide visited view steps, respectively.

FIG. 2is a block diagram of one embodiment of a runtime engine200. The runtime engine200includes a UI manager202, an Inbox manager206, a task controller204, an object manager205, a temporary storage208and a main database210.

The UI manager202is responsible for rendering and presenting wizard-style task UIs to end users, and communicating the end user input to the object manager205and task controller204.

The Inbox manager206is responsible for controlling new and paused tasks stored in users' Inboxes.

The task controller204is responsible for analyzing the metadata pertaining to the task and the end user input, and executing flow and business logic based on this analysis to guide the end user through the business task.

The temporary storage208stores data associated with the task throughout the lifetime of the task. In one embodiment, this data is only visible while the task is executing and only to the end user running the task. In another embodiment, the temporary storage208may be shared across multiple tasks and their end users. Once an end user successfully completes the task, the data stored in the temporary storage208for this task is committed to the database210and becomes visible to other users in the organization.

In one embodiment, the task controller204includes a task controller interface212, a navigator214, a navigation stack216, a step executor218, an evaluator220and a task state manager222.

In one embodiment, the task controller interface212interacts with the UI manager202, and invokes appropriate internal components of the task controller204. In one embodiment, the task controller interface212includes one or more APIs to communicate with different entities.

The orchestrator224calls the step executor218to execute the step activity, and pushes the step instance into the navigation stack216.

The navigator214is responsible for performing forward and backward navigation. In one embodiment, when at the decision point, the navigator214calls the evaluator220to evaluate branch condition criteria and determine the forward path. On forward navigation for all other step types, the navigator214may call the step executor218to execute the activity represented by the step, and push the stack frame into the navigation stack216. Each stack frame may contain a reference to the current business object state. The business object is a collection of data associated with particular UI, including data currently entered by the end user. The navigator214restores business object states from the navigation stack216for the task views during backward navigation.

The task state manager222is responsible for maintaining the life cycle of task instances and their states. In addition to navigation stack, task state encompasses the values of all task variables for the current task instance. In one embodiment, the task state manager222maintains the life cycle of a task by enforcing its state transition rules as discussed in more detail below in conjunction withFIG. 12.

In one embodiment, the runtime engine200also includes an object manager205that provides data management for the task controller204, Inbox manager206and the UI manager202. In one embodiment, the object manager supports transaction isolation for operations performed within the boundary of a task in a manner transparent to its client components. The object manager stores updates associated with these operations in the temporary storage208until the task controller204calls the object manager to commit the data to the database210. The task controller204may also call the object manager to set data savepoints and rollback the task data to a savepoint when necessary. In one embodiment, the object manager captures the task business object (BO) state, and provides the functionality to store and retrieve BO state from its serialized image and database210.

An exemplary task execution scenario will now be discussed in more detail with reference to the major components of the runtime engine200, according to one embodiment of the present invention. The scenario may begin when an end user selects a new or paused task in the Inbox. In response, the Inbox manager206calls the UI manager202, passing the name of the task. The UI manager202extracts the task context, and calls the task controller204to start a task. Then, the task controller204calls the object manager205to create the temporary storage208for the task. Using the object manager205, the task controller204reads data from the temporary storage208and writes data back to the temporary storage208.

If the next step is a task view step, the task controller204exits and returns control to the UI manager202, passing the name of the next task view. The UI manager202renders the task view and stores the user data through the object manager205in the temporary storage208. If the end user activates a navigation control (e.g., by pressing the Next, Previous or Cancel button) in a task UI view, the UI manager202calls the task controller204passing a navigation operand (e.g., Next, Previous or Cancel). The task controller204performs all relevant non-UI related task activities and returns control back to the UI manager202, providing the name of the subsequent task UI view.

If the user pauses the task, the task controller204saves the current task state via the object manager205to the database210, bypassing the temporary storage208. The UI data remains in the temporary storage. If the user finishes the task, the task controller204issues a commit to the object manager205, which saves the UI data permanently from temporary storage208to database210. Depending on whether the task is paused or completed, the task controller204may update or remove the task from the Inbox.

FIG. 3is a flow diagram of one embodiment of a method300for building wizard-style UIs pertaining to a business task. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in the system100ofFIG. 1A.

Referring toFIG. 3, method300begins with processing logic receiving a visual representation of a business task (block302). The visual representation of the business task is created by an intermediate user in a design environment (e.g., a business analyst, or a software developer). In one embodiment, the design environment allows the intermediate user to create the task visual representation declaratively, without writing any code. In one embodiment, the task visual representation is in the form of a flowchart containing a sequence of steps to be performed for the task. These steps may include, for example, UI view steps, service invocation steps, database operation steps, decision steps, etc.

In one embodiment, the design environment allows the intermediate user to provide properties for the task (e.g., the name of the task, transactional behavior, etc.) and individual steps of the task (e.g., fields to be entered by an end user for a UI view step, database fields to be updated for a database operation step, branching conditions for a decision step, the name of a service to be called for a service invocation step, etc.). In one embodiment, one of the step-level properties for non-UI steps is the repeatable property that specifies whether the step should be re-executed upon re-visit during forward navigation. In one embodiment, the design environment also allows the intermediate user to define labels for navigation controls for the task UI views (e.g., Previous, Next, Pause, Cancel, etc.). In addition, the design environment may allow the intermediate user to specify metrics (e.g., task performance parameters during runtime, timestamps, etc.) within a task flow that can be used for various task analyses.

At block304, processing logic converts the visual representation of the task into a collection of metadata (e.g., XML representation of metadata). This metadata defines the steps, the execution flow, the branching logic, UI-related instructions, and other information pertaining to the task. The collection of metadata may also include properties of the task and properties of individual steps of the task.

At runtime, processing logic processes the collection of metadata pertaining to the task to provide a set of task wizard-style UIs for an end user (block306). In one embodiment, processing logic also provides navigation support to allow the end user to use the navigation controls when navigating through the task UIs, as will be discussed in more detail below. In one embodiment, processing logic captures analytics data during the execution of the task.

FIG. 4is a flow diagram of one embodiment of a method400for executing a business task associated with wizard-style UIs. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in the runtime engine200ofFIG. 2.

Referring toFIG. 4, method400begins with processing logic receiving the Start Task action (block402). The Start Task action may be received when an end user selects a new or paused task (e.g., stored in the Inbox). Alternatively, the Start Task action may be run when an end-user starts a new instance of a standalone task.

At block404, processing logic initiates the task selected by the end user and determines the next UI view. In one embodiment, as part of task initiation, processing logic loads the definition of the task into a task definition cache maintained by the runtime engine200. The definition of the task contains the collection of metadata discussed above. One embodiment of a task initiation process will be discussed in more detail below in conjunction withFIG. 5.

At block406, processing logic evaluates, based on the task definition, the flow logic of the task to identify the next step to be performed. This may involve evaluation of all branching conditions if the current step is a decision step.

At block408, processing logic decides whether the next step is the UI view determined previously (e.g., during task initiation). If not, processing logic performs the non-UI step (block416) and checks for errors (block418). If an error occurred, processing logic presents an error message (block420) and proceeds to block422. If no error occurred, processing logic proceeds directly to block422.

At block422, processing logic determines if the current step is the last step of the task. If not, processing logic returns to block406. If so, processing logic saves the task data in the database (block426).

If processing logic decides at block408that the next step is the UI step, processing logic presents the UI view to the end user (block410) and waits for a navigation action (e.g., Next, Previous, Pause or Cancel). Upon receiving a navigation action (e.g., when an end user presses a navigation button) (block412), processing logic performs the corresponding task navigation operations (block414), which may include determining the next UI view, and proceeds to block424, where processing logic checks whether the task has been completed. If the task has been completed, data in task transaction is saved into the database (block426), otherwise, the next UI view is presented (block410), and the loop continues until the task is completed.

The navigation operations may allow the end-user to move to prior UI views (e.g., by activating the Previous button) and then retrace the steps (e.g., by activating the Next button). In one embodiment, the end user can optionally modify data entered and change execution basis. In one embodiment, the steps performed in the execution flow can be conditionally re-executed (e.g., if allowed by the settings provided by the intermediate user) when reached multiple times via the previous/next actions. In one embodiment, the UI view state is maintained across the end-user's previous/next actions. The UI view may be reconstituted in the state where it was left.

In one embodiment, processing logic allows for partial record editing. In particular, a record can be in an incomplete/invalid state when the Previous action is used. Then, partially entered data will be displayed to the end user when the view is returned to via a subsequent Next action. In one embodiment, a user can go iteratively through a sequence of views, and processing logic will maintain the history of step instances through each loop.

In one embodiment, processing logic supports alternate paths when re-executing steps. That is, if an end user uses the Previous button to go backward, he or she may change previously entered data values. Then, when the end user uses the Next button to move forward, the data entry changes can cause a different sequence of task steps to be followed. If so, processing logic follows this different sequence of steps.

In one embodiment, processing logic ensures that partially edited records, which have not been validated only show up in the execution branch and UI view that originally created them. If the task is completed, processing logic ensures that records that have not been validated do not get committed to the database.

One embodiment of the navigation process will be discussed in more detail below in conjunction withFIG. 6.

FIG. 5is a flow diagram of one embodiment of a task initiation method500. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in a task controller204ofFIG. 2.

Referring toFIG. 5, method500begins with processing logic loading a definition of the task (block502). In one embodiment, processing logic loads the task definition containing a relevant collection of metadata into a task definition cache.

At block504, processing logic creates a task instance.

At block506, processing logic starts the task transaction. In one embodiment, processing logic invokes the object manager to start the task transaction.

At block508, processing logic adds the Start step instance to the navigation stack and sets the current step to the Start step.

At block510, processing logic sets the navigation action to Next.

FIG. 6is a flow diagram of one embodiment of a navigation method600. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in a task controller204ofFIG. 2.

Referring toFIG. 6, method600begins with processing logic determining whether the current navigation action is the Next action (block602). If so, processing logic performs the Next action operations (block604). One embodiment of a process for performing the Next action operations will be discussed in more detail below in conjunction withFIG. 7.

If the current navigation action is the Previous action (block606), processing logic performs the Previous action operations (block608). One embodiment of a process for performing the Previous action operations will be discussed in more detail below in conjunction withFIG. 8.

If the current navigation action is the Pause action (block612), processing logic performs the Pause action operations (block614). One embodiment of a process for performing the Pause action operations will be discussed in more detail below in conjunction withFIG. 9.

If the current navigation action is the Resume action (block616), processing logic performs the Resume action operations (block620). One embodiment of a process for performing the Resume action operations will be discussed in more detail below in conjunction withFIG. 10.

If the current navigation action is none of the above, then processing logic decides that it is the Cancel action and performs the Cancel action operations (block618). One embodiment of a process for performing the Cancel action operations will be discussed in more detail below in conjunction withFIG. 11.

The navigation operations utilize a history stack referred to as the Navigation stack. In particular, when a task step is first completed, the step instance information is stored in a frame of the Navigation stack. If the current task step is a view step, a snapshot of the current UI state is recorded in a frame of the Navigation stack. The task controller uses the Navigation stack to navigate between previously completed steps, and to restore UI states for the task views during backward navigation.

FIG. 7is a flow diagram of one embodiment of a method700for performing Next action operations. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in a task controller204ofFIG. 2.

Referring toFIG. 7, method700begins when a signal for a next action is received. Processing logic starts with evaluating the flow logic to determine the next step (block701). This may include evaluation of all branching conditions if the current step is a decision step. This functionality is similar to that performed by block406inFIG. 4.

Once the next step has been identified, processing logic checks the navigation stack to see if the current step is the last step on the navigation stack (block702). If false, the processing logic checks if the identified step is the same as the next step on the navigation stack (block703). If this is also false, it means that the task execution sequence has been altered. As a result, the forward step history on the navigation step becomes invalid, and needs to be erased (block722). Processing logic continues by setting the identified step as the current step (block705). If the identified step is a task view step (block706), processing logic returns it as the next task view (block707), and adds the identified step to the navigation stack (block708).

If the identified step is an end step (block709), processing logic commits task data from temporary storage to the database (block710) and deletes the current task instance (block711).

If the identified step is an error step (block712), processing logic raises the user-defined error (block713), and restores the state to the last shown view (block716).

If the identified step is a commit step (block714), processing logic commits task data from temporary storage to the database (block715). If successful, the commit step is added to the navigation stack (block721).

If the identified step is a decision step (block718), processing logic proceeds to add the decision step to the navigation stack (block721). The branching logic is then evaluated in block701.

If the type of the identified step is none of the above, it is either a database operation step or a service invocation step. In either case, processing logic executes the identified step (block720) and, if successful, the executed step is added to the navigation stack (block721). After that, processing logic returns to block701, at which point the above sequence is repeated until the view or end step is reached.

FIG. 8is a flow diagram of one embodiment of a method800for performing Previous action operations. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in a task controller204ofFIG. 2.

Referring toFIG. 8, method800begins with processing logic saving the state of the current view step on the Navigation stack (block802).

Next, processing logic sets the current step to the previous step from the Navigation step (block804) and determines whether this task step is a view step (block806). If so, processing logic restores the state of this view step (block808) and returns this task view (block810). If no, processing logic determines whether this view step is the first step on the navigation stack (block812).

If this view step is the first view step on the navigation stack, processing logic returns an error (block816). Otherwise, processing logic moves to the previous view step on the Navigation stack (block814), restores its state (block808), and returns its name as the name of the view to be presented to the end user (block810).

FIG. 9is a flow diagram of one embodiment of a method900for performing Pause action operations. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in a task controller204ofFIG. 2.

Referring toFIG. 9, method900begins with processing logic saving the state of the current view step on the Navigation stack (block902).

At block904, processing logic saves the task instance to the database.

At block906, processing logic adds or updates the task instance in the Inbox in a paused state.

At block908, processing logic creates a new checkpoint and suspends the task transaction (task UI data in temporary storage).

At block910, processing logic returns the last task view presented to the user before the task had started.

FIG. 10is a flow diagram of one embodiment of a method1000for resuming a paused task. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in a task controller204ofFIG. 2.

Referring toFIG. 10, method1000begins with processing logic identifying a paused task selected by the end user in the Inbox (block1002).

At block1004, processing logic loads the definition of the paused task. In one embodiment, task definitions may be cached in memory, to minimize latency.

At block1006, processing logic loads the task instance (including its state) from the database.

At block1008, processing logic resumes the task transaction.

At block1010, processing logic stores the name of the currently displayed view. This view may be shown upon task completion, or when the task is next paused, or canceled.

At block1012, processing logic reads the name of the view at which the task was last paused from the restored task state.

At block1014, processing logic returns the next task view, or an error in case it had been encountered during any of the steps in this process.

FIG. 11is a flow diagram of one embodiment of a method1100for performing the Cancel action operations. The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. Processing logic may reside in a task controller204ofFIG. 2.

Referring toFIG. 11, method1100begins with processing logic deleting the task instance from memory (block1102).

At block1104, processing logic rolls back the task transaction to the previous checkpoint (created during pause).

At block1106, processing logic returns the last view, or an error if it had been encountered during the operation of this method.

FIG. 12is a block diagram illustrating how a task instance transitions between internal states during run-time execution.

Referring toFIG. 12, a task can enter in-progress state1202if it is a new task1204or a restored task1206. The in-progress state1202indicates that the owner is working on the task. The new task1204may enter the in-progress state upon task initialization. The restored task1206may enter the in-progress state from paused state1208upon task resumption.

Tasks can change their state from in-progress1202to deleted1214as a result of an unhandled exception during navigation, when deleted from the Inbox, or upon a cancel task event (latter transition may only be applicable to new tasks). Deleted state1214indicates that the user has deleted the task. When a task is deleted, the task state is removed from the system.

Tasks can change their state from in-progress1202to completed1216when the task successfully ended during navigation, with or without reflecting the completed state in the Inbox. Completed status indicates that the task has successfully run to completion. When a task is completed, the task state is removed from the system. The task controller assigns a task with Completed status when the owner clicks the Submit button and the task has successfully arrived at the End step without any error. If an error has occurred before the End step, the task will continue to be in In-Progress status. In one embodiment, a task-level property called inbox disposition may control whether completed tasks are transitioned to completed1216, or directly to deleted1214state. This gives the flexibility to save history for tasks that require it, while avoiding inbox clutter for tasks that do not require explicit trace.

Tasks can change their state from in-progress1202to paused1208when the owner has paused the task explicitly or implicitly. Tasks are explicitly paused by the owner clicking on the Pause button. Tasks are implicitly paused when the owner has navigated out of the task view. New tasks1210can also directly enter the paused state1208if they were created by a business process through the create task event.

Transferred state1212is a sub-status of the paused state1208. Tasks in transferred state1212have the same runtime behavior as any other tasks in paused state, except for a different status label in inbox UI, which indicates to the end user that the task has been reassigned to him or her.

FIG. 13is a block diagram illustrating how data objects change state during run-time execution.

Referring toFIG. 13, a record may have never been validated1302or validated at least once1304. A never validated record may be a new record1306, or a record saved to a temporary storage1308. This kind of record may be invisible1310in all cases, except if it is explicitly positioned on by the caller, when it becomes a visible record1312. It will be appreciated that this mechanism is used to show partially entered records only in the branch and UI view that created them.

Records validated at least once1304include records1320saved only to the temporary storage. These records are only visible within the task that created them. In addition, validated at least once records1304include records1322saved to the base tables (in the database). These records are visible to the whole organization.

FIG. 14is a block diagram of an exemplary computer system1400(e.g., a computer system hosting task controller204and/or UI manager202ofFIG. 2and/or task UI development tool102ofFIG. 1) that may be used to perform one or more of the operations described herein. In alternative embodiments, the machine may comprise a network router, a network switch, a network bridge, Personal Digital Assistant (PDA), a cellular telephone, a web appliance or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine.

The computer system1400includes a processor1402, a main memory1404and a static memory1406, which communicate with each other via a bus1408. The computer system1400may further include a video display unit1410(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system1400also includes an alpha-numeric input device1412(e.g., a keyboard), a cursor control device1414(e.g., a mouse), a disk drive unit1416, a signal generation device1420(e.g., a speaker) and a network interface device1422.

The disk drive unit1416includes a computer-readable medium1424on which is stored a set of instructions (i.e., software)1426embodying any one, or all, of the methodologies described above. The software1426is also shown to reside, completely or at least partially, within the main memory1404and/or within the processor1402. The software1426may further be transmitted or received via the network interface device1422. For the purposes of this specification, the term “computer-readable medium” shall be taken to include any medium that is capable of storing or encoding a sequence of instructions for execution by the computer and that cause the computer to perform any one of the methodologies of the present invention. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.