Exchange is an excellent messaging engine, but its leading rival, Lotus Notes, has traditionally offered superior groupware capabilities. Now, Microsoft has set its sights on Notes' groupware. Exchange Server 5.5's introduction of Event Service lets developers associate code with Exchange folders. You can link Visual Basic Script (VBScript) code to scheduled events and to additions, changes, or deletions to items in certain folders. Event Service monitors folders and executes specified code when events occur.
Service Pack 1 (SP1) includes Routing Objects, which let developers tell Event Service how to route an item after a user adds the item to a folder. Microsoft describes Routing Objects as a set of tools that simplify the development of email-based routing and approval applications. For example, you can set up a system in which every time a user posts a new travel request to the company's Travel Requests public folder, Exchange routes the item to a manager for approval, then to the travel department for flight and hotel bookings, then to the accounting department to authorize payment for the travel arrangements. Exchange delivers items to recipients in email format, and recipients can use standard Outlook voting buttons to approve or disapprove the items' contents. (Users of messaging clients that don't recognize Outlook voting buttons will have compatibility problems with Exchange routing applications.) You can tell Exchange to take one routing step when recipients approve an item and a separate routing step when recipients disapprove the item. Routing Objects enable Exchange to support simple workflow, and SP1 includes a Routing Wizard component that makes Exchange workflow easy to implement. I based the information in this article on my experience with a trial kit of the Collaboration Data Object (CDO) Routing Objects.
Routing Components
Microsoft based Routing Objects and Event Service on its component object model (COM). Three major server-side Routing Objects components make Exchange workflow possible.
First, SP1 includes Routing Engine, a simple state engine that communicates with Event Service. It processes routing items in folders that you specify. Each item in the folders has a state (e.g., initiated, rejected, approved), and Routing Engine tracks each item's state and executes the VBScript code appropriate to that state. Routing Engine contains all the code it needs to route an item via email and call custom-built VBScript functions for bespoke processing.
Second, SP1 provides a set of CDOs you can use to control routing behavior. Developers use CDOs for many purposes, including programming the active pages that Outlook Web Access (OWA) uses to let Web browsers log on to Exchange servers. OWA's CDO manipulates objects such as mailboxes, folders, and calendars. SP1's CDO Routing Objects enable programmers to create and control process maps, which define the steps items pass through in a routing cycle and the activities Exchange needs to perform at each step.
Third, SP1 contains a set of VBScript functions (which are part of the CDO Routing Objects) for building steps that are common to many routing applications. The common steps that SP1 offers functions for include sending and receiving items for approval, consolidating items (e.g., gathering in one place information about multiple recipients' approval or disapproval of an item), and performing evaluations such as timing out items that sit in recipients' mailboxes for a certain period of time. Developers can use the VBScript functions that SP1 provides or build custom functions for their routing applications.
Workflow Wizardry
Microsoft uses the term process designer to describe a person who analyzes an item's route and determines the actions that a routing application must take at each stage of the route. Process designers combine knowledge about a business process, such as how a company handles a travel request, with programming expertise that lets them transform business processes into code that manipulates CDO Routing Objects. I've used workflow technology since 1989, and I've found that transforming business procedure into code can be difficult. I remember how a major institution proudly described at a conference in 1992 the automation of a business form: The company reported that creating the electronic version of the form had taken only 1 year.
I'm thankful that SP1 provides Routing Wizard, a process designer program that helps developers design simple routing applications. To use Routing Wizard, you must first decide which folder you want to use for your routing application. Each routing application requires a separate folder. Because these folders must be available to multiple users, administrators usually select public folders for workflow applications.
Routing Wizard logs on to the Exchange server that hosts the folder that will hold your routing items and selects the folder. Then, it lets you choose between serial (sequential) and parallel routing. Screen 1 shows Routing Wizard's Choose Route Type window. If you select Sequential Route, items will travel from recipient to recipient in the order that you specify until the last recipient approves the item. If you se-lect Parallel Route, the application will deliver items to a group of recipients at once. Recipients in both types of route can open and alter routed items' attachments before approving or disapproving the item and sending it on to the next stage in its life cycle.
After you choose the type of routing you want your application to use, Routing Wizard prompts you to select the item's recipients. Next, the process designer creates content for the routing slip, the item's cover note. Most workflow applications' routing slips contain instructions for item recipients such as, As the approving manager, you must verify that the contents of this request comply with regulations.
Finally, Routing Wizard lets you se-lect the item's final destination. Screen 2 shows the Final Destination window. An item's final recipient can receive the item and a summary that describes the actions recipients took at each stage in the item's life cycle, or only the summary. Screen 3 illustrates a routing summary for an item that Exchange sent to two serial recipients, both of whom approved the item.
After you select a final destination for your item, Routing Wizard generates and installs the code necessary for each step of the routing process into the folder you selected as the routing item repository. The installed code is the event handler (also called an agent) that processes events that arise as users add items to or manipulate items in the folder. When Routing Wizard adds code in this way, it binds the agent to the folder. This process creates a hidden binding message, a folder property that describes the agent, the events that the agent acts on, and any agent-specific properties (such as an application-specific routing action). Screen 4 shows the properties of an agent that Routing Wizard installed.
Workflow designers must have appropriate access to target folders before they can install code. The designer must have owner permission on the target folder and the special events system folder on the server on which Exchange will execute the code. Routing Wizard doesn't generate VBScript code (unlike agents you write); instead, it installs a COM-compliant event handler.
Routing Wizard doesn't provide archiving functionality, so you must make arrangements to manually move old workflow items out of your active routing application folder to prevent the folder from accumulating hundreds or thousands of items. Currently, no data is available to establish whether folders containing hundreds of items slow system performance.
You can distribute routing applications to multiple servers and use Exchange's standard replication mechanism to replicate items among the servers, but you must install the routing code separately for each replica. If you replicate routing application items across a large Exchange organization, be careful to minimize the possibility of update conflicts.
The Wizard's Limitations
Routing Wizard is obviously useful, and it generates all the code necessary to build simple workflow applications. However, Routing Wizard has the following notable limitations that force you to develop code or purchase a full-featured workflow application if you need these features.
First, the current version of the wizard requires you to hard-code all recipient names; it can't generate code to route an item to the person who holds a particular organizational title in the Exchange Directory. If you want to route items according to a structure rather than hard-coding individuals' names into the application, you must set up mailboxes for each step in the routing process and route items to the mailboxes. For example, you can set up a Travel Manager mailbox and route all travel requests to that mailbox. Your company's travel manager can log on to the mailbox periodically to process incoming requests.
Second, you can't combine parallel and serial routing steps into one workflow life cycle. Some applications require serial and parallel routing, but Routing Wizard can't create applications with both types of steps. The wizard generates code for either a single-step parallel route or a multistep serial route.
Third, you can set items in a parallel routing structure to time out after they have been in a recipient's mailbox for a specified period of time, as Screen 5 shows, but the wizard doesn't let you program an application to bypass a serial step after a set period. Serial items might wait for approval for several weeks while a manager is on vacation.
Fourth, you can route items to many parallel recipients and give each recipient the opportunity to approve or disapprove the item, but every recipient in a parallel route of an application that Routing Wizard creates must approve an item for Exchange to consider the item approved. You can't set a voting quorum or assign a weight to different recipients' responses to decide the item's final status. For example, you can't set up a system in which, if three managers receive an item and only two approve it, Exchange compares the managers' seniority before deciding whether to reject the item.
Fifth, the wizard doesn't let the originator of an item automatically receive a copy of the final summary of the item. You must hard-code the name of the final recipient for each application's items.
Sixth, recipients can see the input from previous recipients in the routing slip, but they can't see the routing cycle's future recipients. I like to know who else is in a routing cycle so I know how many approvals an item must receive before it is complete.
Seventh, systems administrators can't easily monitor the progress of workflow items. Routing Wizard doesn't offer tracking or logging functionality. You can open the folder that holds the items for a particular application and examine each item, but examining each item individually gets tiresome when a folder holds more than a handful of items.
Eighth, you can't add fill-in items such as Excel templates to Routing Wizard items. Many workflow applications include items such as expense reports, which use spreadsheets to hold structured data. Routing Wizard doesn't provide for such functionality.
Finally, Routing Wizard doesn't provide e-forms capability. If you want to use a form that looks like an electronic version of a paper document, you must build the e-form yourself.
These limitations are shortcomings of Routing Wizard, not Routing Objects. Routing Wizard is a baited hook Microsoft created to attract Exchange administrators into the world of workflow. Routing Wizard provides easy-to-create, working demonstrations of how you can use Exchange folders to deploy workflow applications. But, you need to understand that Routing Wizard can currently generate only very simple workflow applications. The Routing Objects interface offers much greater capabilities than the wizard.
Generating Your Own Wizardry
Workflow is a complex business, so Microsoft made extensive changes to CDO to accommodate workflow operations. Workflow items are a special form of standard email messages. Microsoft refers to a workflow item as a Process Instance Message. PIMs appear similar to ordinary Messaging API (MAPI) messages, but they have extra properties that you can manipulate during a workflow life cycle. These properties include a workflow status property, a unique routing identifier, and a workflow map property that tells Routing Engine how to process the item. The workflow map controls how an item moves among recipients. An item inherits its map from a default map that Exchange holds in a workflow folder, or the item's workflow application creates a special map and attributes that map to the item on the item's creation.
A workflow map consists of a set of rows; it looks much like a table in a word processing document. Each row consists of an activity identifier, an action, and one or more parameters for the action. Table 1, page 188, shows a simplified workflow map that describes the following item life cycle. First, a user posts a new item to the folder. The application creates a new instance of a PIM from the item, and Routing Engine sends the PIM to the email address for the approving manager.
Routing Engine waits for 2 days. A scheduled event periodically checks whether any PIMs have exceeded their timeout limits. If a PIM's timeout interval expires, Routing Engine looks for the handler for timeout events. The timeout handler executes the specified code, which might route the PIM to the next recipient with a suitable comment or return the PIM to its originator.
If Routing Engine receives a response from the approving manager, it examines the content of the PIM. It stores approvals and rejections as properties of the PIM. If the manager approves the item, Routing Engine calls code to complete the item's processing. A simple application might send a copy of the completed PIM to the item's originator. A more complete workflow application might generate electronic transactions at this point in the mapfor example, generating an electronic funds transfer to pay approved expenses. If the manager disapproves an item, Routing Engine calls a different set of code.
Microsoft incorporates some actions that many application maps require into Routing Engine. Every new instance automatically inherits these actions, which are primarily flow-control directives such as GoTo, Wait, OrSplit (an IF statement), and AndSplit (which processes parallel branching). SP1 provides a routing.vbs file, which contains code for a set of common actions you can incorporate into routing applications. Routing Wizard uses much of the routing.vbs code. You can use Routing Wizard to create an application, then study that application to understand what happens when Routing Engine processes an item. The processing is straightforward, and you can easily follow it. You'll quickly understand what to expect as Exchange workflow items pass through different stages of their life cycle. You can apply this understanding to applications you develop because routing items in your applications and in Routing Wizard applications will behave similarly if your code works properly.
If your application needs an action that SP1 doesn't provide, you can build a new action. Programmers can use CDO to create and manipulate workflow items in the same way that OWA processes messages and calendar items. You can use compiled languages, such as Visual C++ or VB, or you can use VBScript. You can develop workflow applications that have access to databases or that perform processing outside Exchange. By default, agents run under the security context of the Exchange service account. However, if you develop a workflow application that needs to interface with external data sources, you'll probably want to direct that code to run under Microsoft Transaction Server (MTS) to provide more secure access to data.
A Routing Alternative
Routing Objects are part of a new CDO library. You can retrofit Routing Objects to any Exchange 5.5 server. You can download the CDO Routing Objects trial kit from http://backoffice.microsoft.com/downtrial/moreinfo/exchrouting.asp. However, SP1 contains many other interesting developments; I recommend applying SP1 to your production servers as soon as it passes your company's software validation procedure.
Routing Objects don't currently provide a platform for heavy-duty or mission-critical document routing, but they certainly provide enough functionality to handle most offices' workflow applications. Microsoft's goal is to make Routing Objects capable of supporting 90 percent to 95 percent of simple workflow applications so the company can claim that Exchange and Notes offer equivalent routing functionality. Routing Wizard is interesting, but it won't prove its usefulness until developers begin adding workflow features to forms that they create with the Outlook Forms Designer. If adding routing functionality to Outlook forms is as easy as Microsoft promises it will be, Exchange-based workflow will truly compete with Notes workflow.
Notes has included workflow functionality for more than 3 years, so many third-party developers have exploited Notes routing to build off-the-shelf applications. A comparable array of applications for Exchange won't appear over- night. However, because of the large community that uses Microsoft development tools and the growing Exchange user base, third-party tools that provide advanced workflow development are certain to begin appearing soon.
