Exchange 2000 Workflow Applications

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.

   Previous  [1]  2  Next