System Design
The requirements describe a system in which a single company (the ad agency) needs to route documents through different users for approval in a predefined sequence. The system must be available to both internal company users and external users on the public Internet. The system will need to represent the following types of objects:
Clients
Projects
Project files
Workflows
Roles
Users
One important requirement of the system is that files belonging to one client or project be safe from unauthorized viewing. The company's existing system uses Windows NT security and access control lists (ACLs) to limit access to sensitive files. The solution we provide should leverage the processes that they already have in place for tracking files and projects using file-system directories.
Clients and Projects
An example of the existing NT file-system structure used by the company to track client files is shown in Figure 13.1. Each client is given a subdirectory. Each client project with the client subdirectory is given a single subdirectory, which is where all the documents and files related to the project are stored.
Figure 13.1. A sample of the existing file-server directory structure.
Because the resulting workflow system must be accessible from the Internet, the most straightforward way to extend the company's existing system is to run a Web server on its file server. With the existing directory structure used as the framework, internal users can continue to work and save files normally while external users can access the workflow system and view their changes using a Web browser.
Because the system will be running on a Windows NT server, Microsoft IIS is a natural choice for the Web server. The application will be written in VBScript for the ASP platform. For parsing and working with XML files, the COM-based MSXML parser will be used.
Modeling Workflows
Now that the basic platform issue has been resolved, it is necessary to determine how the workflow itself will be represented by the system.
A workflow involves moving a file or group of files through a predetermined sequence of steps. At each step, a single user of the system is designated as the owner. Upon receiving ownership, the user will perform some actions (make changes, make comments, reject changes, and so on) and pass the files on to another owner.
As a concrete example, Figure 13.2 shows a simple workflow that would be used in the development of a new magazine ad.
Figure 13.2. The basic workflow for creating a new magazine ad.
The circles represent the abstract users who need to modify or review the document at each point in the process. The arrows represent the various paths a document can take from one user to another. The system must be able to model these interconnections, then track the progress of documents as they move through the system. A single abstract workflow might be used by half a dozen projects at the same time, using different users for each role. The system must allow for this workflow reuse.
Besides modeling the abstract workflow, the system must be able to assign concrete users to the various roles in the process. The same basic workflow might be used by three different clients, with different ad-agency personnel fulfilling the duties of writer, proofreader, account executive, and so forth.
A single large client company may also have multiple projects running simultaneously. The system will need to support the concept of a project. A project will consist of a single workflow, the users who will participate in the workflow, and all the documents that make up that project.
To support this functionality, the system will use a single XML document for each project that will contain the following elements:
Basic project information (for example, the name of the project)
Status information about the project, such as the current workflow step
The workflow instructions to be used for the project
A list of concrete users who will be participating in this project
A mapping from abstract workflow roles to the concrete users
A project history log that captures the sequence of steps the project has gone through, along with any user comments that were submitted along the way
Managing Roles and Users
The application will be relying on Windows NT to perform authentication and limit access to project directories. This means that each project document will need to provide a simple lookup table that maps NT usernames to workflow-specific roles.
Also, the agency currently has a simple Access database of users that contains additional information (such as email addresses). To simplify ongoing maintenance and management, it would be optimal if the workflow system could extract this additional information from the database instead of referencing a static document. Next, in the “Implementation Notes” section of this chapter, we will explore how to exploit the features of IIS and ASP to integrate dynamic content like this with static XML documents.