Ask people to give you an example of a workflow application's use, and you'll get many responses—vacation requests, document approvals, and bug tracking, to name a few. What's common among all workflow applications is that they check an item's state when a particular event takes place, and then conditionally transition the item into a new state. This state verification and transition is the workflow process. To support and enable this process, workflow applications have basic requirements for the platform on which they run.
Microsoft Exchange 2000 Server's core architectural features make it an ideal platform for supporting a workflow process. To develop rich workflow applications, you must understand how the Workflow Engine uses Exchange 2000's architecture and how you can use Collaboration Data Objects (CDO) Workflow objects and the Exchange Workflow Designer to easily enable workflow processes on items within the Web Storage System.
The Web Storage System
Exchange 2000 is more than just a messaging system. Microsoft has combined messaging, collaboration, and database and Web services into one product, resulting in an extensible application platform for developing Web-based solutions. At the heart of Exchange 2000 is the Web Storage System, which not only stores any type of data but allows access to that data from many different clients that are using many different protocols.
Because you can place any type of data into the Web Storage System, an extensible mechanism must exist to describe and complement the data. In traditional database terminology, an item in a Web Storage System folder is akin to a row in a table, and the properties of that item are the columns. The beauty of the Web Storage System is that it doesn't restrict you to a defined set of columns—different rows in the table can contain different columns. In Exchange parlance, this flexibility means that you can add custom properties to any item and use these properties in any way you see fit. Metadata, attributes, and fields commonly refer to the properties of an item.
End users usually envision email messages, appointments, and documents when they consider the types of items they might find in the Web Storage System. Details such as author, send date, recipient, and cc list are properties that describe these types of items.
In contrast, application developers envision in the Web Storage System all sorts of placeholder items whose only purpose is to persist information about the application; these items are typically hidden from users. Exchange 2000's Workflow Engine persists information through properties and relies heavily on properties of hidden items to define the workflow process. Developers can define custom properties for use within their workflow applications.
In addition to Exchange Server 5.5's Event Service, which Exchange 2000 includes for backward compatibility, the Web Storage System provides a new event architecture. This new architecture supports synchronous, asynchronous, and system-based events. These events fire whenever a user saves or deletes an item in the store or when a system event occurs.
You can write a sink (i.e., custom code) that Exchange 2000 executes when a particular event fires in a specified folder. You can write sinks in Microsoft VBScript, Visual Basic (VB), or C++. The store process (i.e., store.exe) passes parameters to your sink that let you determine why Exchange 2000 is firing the event. Synchronous events occur in the path of transactions; thus, they can stop Exchange 2000 from committing a transaction. For example, a custom synchronous delete- event sink could abort a delete, thereby retaining the item in the store.
You can register your sink so that Exchange 2000 calls it for events that fire within one folder, a folder tree, or a complete store. This registration process creates a hidden item in the store at the root of the folder. The store process uses the properties on this item to define the characteristics of the registration, such as the sink's program identifier, whether Exchange 2000 should call the sink for all subfolders, and whether the sink is enabled.
You can use the Exchange 2000 software development kit's (SDK's) Web System Storage Explorer utility (wssexplorer.exe) to view an event registration item and its properties, as Figure 1 shows. I used http://laptop/public/MEC2000/day 3/eventregistration to access the item in Figure 1. I set the value of the property called http://schemas.microsoft.com/exchange/events/SinkClass to card.sink and the value of the property http://schemas.microsoft.com/exchange/events/EventMethod to OnSyncSave. Based on these settings, whenever a user attempts to save an item in the Day 3 folder, Exchange 2000 fires the program registered as card.sink before the transaction completes.
Don't be alarmed by the property names that begin with http://. This naming convention is simply a method to uniquely name properties. For convenience, and good programming practice, you define each property with a namespace that identifies the application that owns it. Exchange 2000 uses many different namespaces, and you can find the properties associated with each namespace in the Exchange 2000 SDK. Exchange 2000's workflow application uses the namespace http://schemas.microsoft.com/cdo/workflow. (For clarity, throughout the rest of the article, I omit the namespace and refer to properties by their name.) When you develop applications, a good practice is to use a namespace that contains your domain name. This practice ensures that your property names are unique.
The Web Storage System is a powerful Exchange 2000 component. Combine this component with Exchange 2000's other key architectural features and you have a great place to store data and an ideal platform for building extended services such as a workflow application.
The Workflow Engine
When a Web Storage System folder is workflow-enabled, Exchange 2000 creates two event-registration items that both have the property SinkClass set to CdoWfEvt.EventSink.1, which is the program identifier for the Workflow Event Sink (i.e., cdowfevt.dll). Exchange 2000 calls the sink when a user attempts to save or delete any item or a timer event fires in a folder. The sink passes the event notifications to the Workflow Engine (i.e., cdowf.dll). Exchange 2000 automatically installs both the Workflow Event Sink and Workflow Engine .dll files. Although Exchange 2000 installs the sink and engine by default, they're inactive until you take the necessary steps to workflow-enable a folder. (For more information about workflow-enabling a folder, see the Exchange 2000 SDK.)
The engine is the core of the workflow process, but what does it do when Exchange 2000 calls it? The engine determines what action to take based on the reason Exchange 2000 called the event sink, the current state of the item that caused the event to fire, and the workflow process associated with that item. A workflow process defines the business logic of the process in terms of states, conditions, actions, and transitions. Exchange 2000 implements the workflow process as a hidden process-definition item in the store and associates many properties with the process-definition item.
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.
