Typical Module Workflow

This topic discusses the typical workflow found within most Commerce Server Business Desk modules. This is only a statement of typical workflow; some Business Desk modules may not conform to it. It is the responsibility of the designer of a new Business Desk module to determine the best workflow for that module. Nevertheless, the workflow discussed here has emerged as the most typical.

Using a few modules in Business Desk quickly yields the following observations about the typical workflow for Business Desk modules. The initial action page for a given module presents a mechanism for viewing a table containing a few properties (the columns) of a number of records (the rows). The control that implements this table is the ListSheet HTML Component (HTC) It can be configured in number of different ways.

Frequently, there are too many records to view at one time. Paging through different screens of records is one answer to this problem. It is also typical for there to be mechanisms for limiting the set of records displayed, such as the ability to search for and display only those records matching specified criteria. The ability to sort the records is also typical, and is accomplished in the ListSheet HTC by clicking the column heading of the property on which to sort.

The next step in the workflow involves choosing a task to perform and initiating that task by pressing a task button. Any task that involves existing data requires that the data be identified by being selected. The task buttons associated with such tasks are usually not enabled unless an appropriate selection has been made. Other tasks, such as the New task, generally do not require existing data to be selected.

In any event, the choice of a task often leads to a different action. This new action is generally an action page, known as an edit page, which allows the editing of properties associated with the new or selected record (or records). Once the editing is complete and the Save task is chosen, the user can click a Back taskbar button to display the original ListSheet HTC and continue to the next task.

Sometimes the act of choosing a task results in the display of a dialog box, rather than immediately displaying a new action. A typical example is a dialog box used to confirm a Delete task.

Other tasks might display a short menu to determine the action to be taken. For example, when the New task is clicked, a menu might be displayed to allow the user to select which of several types of objects they wish to add.

The following diagram illustrates one possible Business Desk session, outlined here using the numbered boxes near the arrows.

  • In step 1, the user chooses Module 1.

  • In steps 2 and 3, the user "drills down" two levels to examine and perhaps modify some detailed data, returning to the list page for Module 1 in steps 4 and 5.

  • The steps shown for Module 2 illustrate how a task might loop back to the same action page. An example is the Save and Create New task where the workflow is optimized for a situation in which a number of new items need to be created, one after the other.

  • The steps for Module 3 illustrate how a task might lead back to the same action page, but with a dialog box intervening. An example is the Delete task, where it is typical to present a confirmation dialog box, especially when the data is particularly important or difficult to recover.

    Ee784425.th_bd_workflow_bd2(en-US,CS.20).gif

A typical new module is likely to have a single list page that is displayed when the module is chosen in the navigation pane. The list page will probably have a small number of tasks it can perform, perhaps five or six tasks. Of these, a few might lead to different edit pages, or perhaps to the same edit page, initialized with different data (the New task versus the Edit task). Some tasks might lead directly to confirmation dialog boxes, and then back to the list page, having carried out or aborted the task.

Copyright © 2005 Microsoft Corporation.
All rights reserved.