The actiontable property on the process-definition item stores a complete record set encoded in Extensible Markup Language (XML). This record set contains records that define the rules of the workflow process, and each record contains 14 fields. The main fields in the action table are State, NewState, Condition, and Action. The engine attempts to match the state of a record in the action table with the current state of the item that caused the event. If the engine finds a match, it will process the VBScript or program identifier that's in the Condition field of the item and execute the Action.
In addition to programming the engine to execute VBScript, you can use CDO Workflow objects to access details about the workflow process. For example, you can maintain custom properties on an item, retrieve information about the user who caused the action, and write auditing information to the System log. You can write a script that the engine runs after it executes the Action. This script encompasses the business logic of your workflow process. What you program within this script depends on the complexity of your workflow process and the client applications that are using the workflow-enabled folder. Without this script, your workflow processes would be able to do nothing more than change the current state of an item. The engine's process translates into "If an item is in a particular State and the Condition statement is true, then execute the Action. If the Action is a transition action, then change the State to the NewState."
Workflow-Enabled Folders
A typical workflow-enabled folder initially contains three hidden items—two event-registration items and one process-definition item. For every item that a user creates in a workflow-enabled folder, the event sink creates a process-definition property for the item that contains the URL of the process-definition item. The Workflow Engine maintains workflow-specific properties, such as currentstate, for the item. Figure 2 shows a typical workflow-enabled folder through a Microsoft Windows Explorer interface. Figure 3 shows the properties of the folder's Incoming Call item through the Web Storage System Explorer interface.
Because Exchange 2000 stores workflow items in folders and you can replicate public folders' contents across multiple servers, what prevents instances of multiple workflow items? The workflow engine will process items only on the server on which the items were initially created. In addition, you must workflow-enable all servers that will hold a replica of a workflow-enabled folder.
Exchange Server 5.5 Routing Objects
You might be wondering how the Exchange Server 5.5 routing objects fit into an Exchange 2000 workflow process. Microsoft designed these routing objects to work with Exchange Server 5.5's Event Service. However, Microsoft designed the objects for only Messaging API (MAPI)-based email-routing applications, so they don't use any of the previously mentioned Web Storage System's features. Exchange 2000's CDO Workflow objects don't run on Exchange Server 5.5 systems, and you can't use them with Exchange Server 5.5 routing objects. Thus, you can't involve Exchange Server 5.5 mailboxes in an Exchange 2000-based workflow process. Therefore, although Exchange 2000 is compatible with Exchange Server 5.5's routing objects, consider rewriting existing applications that use the objects to use CDO Workflow objects.
Ready for Action
To enable workflow on a folder, you create an item in the Web Storage System and give it the necessary properties and values. Some of the properties' configurations are complex. So how do you create and manage process-definition items and the action table that the items contain?
You can use ADO or WWW Distributed Authoring and Versioning (WebDAV) to manually build process-definition items, but why go to all that trouble when the Exchange Workflow Designer can do it for you? The designer is a graphical tool that manages event-registration and process-definition items. The designer ships with Microsoft Office 2000 Developer 1.5, runs on a client computer, and uses Office 2000's Internet Publishing Provider, which uses WebDAV to manipulate store items.
When you invoke the Exchange Workflow Designer, you specify a URL to a folder in the Web Storage System. The designer then reads any existing process-definition items in that folder and presents you with an interface similar to the one that Figure 4 shows. From this interface, you can easily define properties, such as the default process-definition item for the folder, whether Exchange 2000 audits all processing, and whether the process definition runs in restricted or privileged mode. In restricted mode, the workflow engine can access only the item that's in transition, and you can't create any instance of a COM object. In privileged mode, you can instantiate COM objects to achieve additional functionality. For example, if you want Exchange 2000 to automatically create a new user object in Active Directory (AD), you must instantiate CDO or Active Directory Service Interfaces (ADSI) objects.
To build your workflow process, you define one or more states and associate one or more actions that can occur when an item is in a particular state. You then define conditions under which the actions apply and define any script that Exchange 2000 should run. When defining an action, you can specify whether the action causes a transition to a new state. (Letting items remain in the same state is useful for implementing parallel-routing scenarios.)
For example, imagine a simple call-handling system in which users report problems to support staff by entering calls into the workflow process. The calls enter the process into an initial Call Received state. From this state, the call can enter a Call Closed or Call Escalated state. (Figure 4 shows the Exchange Workflow Designer interface for this scenario.) For Exchange 2000 to transition a call from the Call Received state to Call Escalated, more than two members of the support staff must specify that the call should be escalated; otherwise, Exchange 2000 will automatically escalate the call if the support staff takes no action on an urgent call for 1 hour.
To enable this configuration, I assigned two change-type actions. The first action has a condition that checks whether the custom property urn:linlithgow:com:count is greater than 2. (The call-handling application uses urn: linlithgow:com as its namespace.) If this condition becomes true, Exchange 2000 moves the call to the Call Escalated state. To set up the second action—Flag for escalation—I created an action script that incrementally adds 1 to the urn:linlithgow: com:count property but doesn't change the Call Received state.
To learn how the designer affects items and properties, use it to build a workflow process, apply this process to a folder, and create items in the folder. Use the Web Storage System Explorer to look at the items and their properties.
Client Applications
To use Exchange 2000's workflow functionality from a client application, a client must be able to update items in the folder to trigger the workflow engine. Office applications such as Word and Outlook can access folders directly. For example, if you define a workflow process that forwards a document through the members of a distribution list (DL), clients can invoke the workflow process by saving the document to the workflow-enabled folder. One strong point of Exchange 2000's workflow functionality is that users can easily employ it to workflow-enable existing processes.
You'll discover the real benefit of Exchange 2000's workflow functionality if you combine it with business-specific client applications that you build on the Web Storage System. Using Web Storage System Forms, you can build powerful Web-based applications that persist their data as items and properties in the store. When a client changes a field on the form, the application updates a custom property on the item, which, in turn, invokes the back-end workflow engine. The back-end script actions can then retrieve the custom property and process accordingly.
The Final State
Exchange 2000's architectural features easily support a workflow process and make workflow-enabling business procedures quick and simple. If you set your sights higher than a simple workflow application, a sophisticated business process will require you to at least have your VBScript programmer's guide on hand.
End of Article
