Lesson 3: Workflow for Exchange 2000 Server | MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration

Workflow applications are very specialized types of collaboration solutions. They automate business processes and are therefore organization specific. Every process that requires a series of actions to accomplish a particular business objective is a good candidate for workflow. At the simplest level, you may add a routing slip to a Microsoft Office document to send it to other users for reviews and resumes (from the File menu, point to Send To, then select Routing Recipient). A moderated public folder, illustrated in Exercise 3 of Chapter 1, "Introduction to Microsoft Exchange 2000 Server," may also be seen as a first workflow approach. However, complex business processes require more than document routing capabilities. The workflow infrastructure must support tracking and audit facilities to measure the process efficiency and resolve exception situations. Central roles are necessary to identify task performers, and advanced business logic should be supported by means of custom script code. CDO for Workflow in Exchange 2000 Server provides a high-end workflow infrastructure based on the Web Storage System.

This lesson introduces typical workflow features of Exchange 2000 Server. It explains the important elements of every Exchange 2000 Server workflow process and illustrates how to quickly get started with a small workflow example.

At the end of this lesson, you will be able to:

Use the Workflow Designer to install and execute workflow processes.
Describe important CDO objects for workflow and their purposes.

Estimated time to complete this lesson: 60 minutes

Workflow Basics

Exchange 2000 Server workflow is based on the concept of a central repository that holds the documents to be processed and provides an interface to design workflow solutions in terms of rules, roles, routes, forms, and views. The central repository could be a folder in a mailbox or a public folder (see Figure 24.5). In fact, public folders are ideal workflow repositories because they can be accessed by virtually anybody using any popular messaging client. Forms and views may be implemented in Outlook 2000 and Outlook Web Access (OWA). Public folders can be replicated between Exchange 2000 servers. This increases the fault tolerance and can help to optimize system performance through load balancing. The administration of public folders is the topic of Chapter 17, "Public Folder Management."

click to view at full size

Figure 24.5 Exchange 2000 Server workflow based on public folders

Web Storage System Event Sink and Workflow Engine

Workflow is an event-driven process. During the installation of Exchange 2000 Server, an event sink (CDOWFEVT.DLL) is registered that intercepts the synchronous OnSyncSave and OnSyncDelete Web Storage System events, and the OnTimer system event for workflow-enabled folders. OnSyncSave, for instance, is fired before changes are committed to the store, which enables the workflow system to reliably react to any item or a change to an item. OnSyncDelete gives the system the ability to prevent invalid actions, such as the deletion of documents in the middle of a workflow process. OnTimer allows the detection of expired items that are in a particular state for too long.

To perform the actual workflow after the reception of an OnSyncSave event from the Web Storage System, the workflow event sink calls the IProcessInstance.Advance method for the affected document in the workflow-enabled folder. IProcessInstance represents an interface to the item or document in process. In other words, the item that the user saved in the folder is handled as a ProcessInstance object (see Figure 24.6). The IProcessInstance.Advance invokes the actual workflow engine, implemented in CDOWF.DLL, which evaluates an action table and executes appropriate actions for the item. CDOWF.DLL is in the \Program Files\Exchsrvr\Bin directory. You can implement custom workflow engines if you are an advanced programmer.

click to view at full size

Figure 24.6 The CDO for workflow architecture

NOTE
The workflow event sink is automatically registered as a COM+ application package. To view and manage this component, launch the Component Services utility from the Administrative Tools program group. Navigate through the following containers to find the workflow event sink COM+ package: Console Root\Component Services\Computers\My Computer\COM+ Applications\Workflow Event Sink.

Workflow Process Definitions

One of the most important parameters that the event sink passes to the workflow engine is the event type. Five different event types are known: document created (cdowfOnCreate), document modified (cdowfOnChange), document deleted (cdowfOnDelete), document in the current state for too long (cdowfOnExpiry), and e-mail response received that correlates to the document (cdowfOnReceive). Based on these five events, you can design your workflow process. To outline a workflow process, you need to create a ProcessDefinition object. Similar to forms registration items for custom Web Storage System forms (see Chapter 23, "Microsoft Exchange 2000 Web Storage System"), workflow process definitions are stored as items in a public folder.

The ProcessDefinition object implements the IProcessDefinition interface. The two most important properties of this interface are ActionTable and CommonScriptURL. The action table is the central part of any CDO-based workflow application. This table defines the rules that govern the workflow process. You need to define the various item states, such as Document Created, Document Overdue, TOC Checked, and so on, and the actions that cause transitions between states. The ActionTable property stores this information as an ADO Recordset.

According to the action table, the workflow engine must determine one or multiple defined actions to execute. Otherwise, an error is returned, thus preventing changes to the affected item. To give an example, let's say you have defined a workflow process according to Figure 24.5. If an item is in the Document Created state, users cannot delete this object from the folder even though they might have full access permissions. Actions have only been implemented for the cdowfOnChange and cdowfOnExpiry events. However, deleting the object causes the event sink to pass a cdowfOnDelete event to the CDO workflow engine. The engine checks the action table, does not find an appropriate action for the item in this state, and, because no action was defined, an error is returned to the user and the item is not deleted.

You can implement actions in the form of VBScript code or COM components. When working with VBScript, actions correspond to procedures implemented in a single script file, which is known as the shared script. The CommonScriptURL property of the ProcessDefinition object points to this file. For detailed information about the programming interfaces and their usage, refer to the SDK documentation.

Action Tables

The series of actions that you create to move documents from state to state form an action table, which encapsulates the workflow logic; the action table defines the workflow rules. Each row in the table has 14 columns. The entire action table is stored as an ADO recordset in the ActionTable property of the ProcessDefinition object.

A row in the action table has the following columns:

ID. An identifier for the action table row
Caption. Display name for the action
State. The state of the process instance to which the action belongs
NewState. The state to which the process instance changes upon successful completion of the action
EventType. Event type for which the action is executed
Condition. A conditional expression that allows the workflow engine to execute the action when the result is true
EvaluationOrder. Position of the row in the order of all matching rows for an event
Action. The definition of the call to a procedure in the common script or COM object
ExpiryInterval. Duration that the item can remain in the new state before a cdowfOnExpiry event is triggered
RowACL. Reserved for future use
TransitionACL. Defines an access control list (ACL) for the transition
DesignToolFields. Used internally by the Workflow Designer for Exchange 2000 Server and similar tools
CompensatingAction. Call of a procedure in the common script or COM object if the workflow transaction is aborted
Flags. Indicates whether the columns in the action table will contain COM objects or scripts

Preparing the CDO Workflow System Account

CDO for Workflow is installed on your Exchange 2000 server automatically, but this does not imply that you have the required permissions to register workflow processes right away. The preparation of CDO for Workflow involves the creation of a system account, the configuration of its mailbox settings and permissions, and the assignment of workflow authors.

IMPORTANT
The workflow system account must be mailbox-enabled if you want to send messages via SendWorkflowMessage in restricted workflows (workflows that prohibit the usage of CreateObject in their actions).

System Account Creation

To create the workflow system account, use Active Directory Users and Computers, mailbox-enable the system account, and add it to the Exchange Domain Servers group. Through membership in this group, the workflow system account inherits full Exchange 2000 Server permissions. Permissions management is explained in Chapter 19, "Implementing Advanced Security."

User Rights for the System Account

The workflow system account also requires the Act As Part Of The Operating System user right to support impersonation of actions when running workflow in restricted mode. Launch the Domain Controller Security Policy tool from the Administrative Tools program group, expand Security Settings, then Local Policies, select User Rights Assignment, and, in the details pane, double-click Act As Part Of The Operating System to add the system account.

Configuring the Event Sink Identity

At this point, you can configure the CDO workflow event sink to run under the identity of the system account. Launch the Component Services utility from the Administrative Tools program group. The Workflow Event Sink COM+ package can be found under Console Root\Component Services\Computers\My Computer\COM+ Applications. Right-click Workflow Event Sink, select Properties, and click on the Identity tab. Select This User, click Browse, select your system account, and then, under Password and Confirm Password, provide the correct security information. Click OK.

Restricted and Privileged Workflow Authors

Before you can develop a workflow scenario, you need to grant your Windows 2000 account appropriate permissions for the workflow event sink. In the Component Services utility, expand Workflow Event Sink, expand Roles, then expand Can Register Workflow, and then select Users. Right-click on Users, point to New, and select the User command to add your account to this role. You may also want to check whether this role is activated for the event sink. Under Workflow Event Sink, expand Components, select CdoWfEvt.EventSink.1, and right-click on it. Select Properties, click on the Security tab, and select the Can Register Workflow check box. Make sure the Privileged Workflow Authors check box is selected as well.

To deploy workflow applications, you need to be the owner of the folder that you want to work with, and you need to have the permissions to register workflow process definitions with the Workflow Event Sink COM+ package. The Can Register Workflow role grants your account restricted workflow author rights. If you want to design powerful workflow applications without any restrictions, you need to add your account to the built-in Privileged Workflow Authors role.

The following restrictions apply to the Can Register Workflow role:

The workflow logic must be written in VBScript (in contrast, privileged mode allows scripts or COM actions).
The shared VBScript code cannot call CreateObject to instantiate COM classes, such as CDO.Message (for sample code, see Lesson 1).
Restricted workflow scripts run with guest privileges by default. The VBScript procedures will run in the context of a special account called EUSER_EXSTOREEVENT, which is created automatically in your Windows 2000 domain during the installation of Exchange 2000 Server (in contrast, in privileged mode, scripts run in the context of the system account).
The workflow system account requires the Windows 2000 Act As Part Of The Operating System permission to allow impersonation of EUSER_EXSTOREEVENT.

NOTE
When replicating public folders between Exchange 2000 servers, keep in mind that permissions for the workflow event sinks are granted on a per-machine basis. You need to configure the Workflow Event Sink COM+ package on all Exchange 2000 servers where you want to deploy the workflow application.

Exchange 2000 Server Workflow Preparation

It is a good idea to use Microsoft Workflow Designer for Exchange 2000 Server to map out your workflow processes and build a first skeleton of your business solution. This tool has the same user interface and architecture as the Microsoft Workflow Designer for Access and SQL Server. It enables you to create and register action tables and shared scripts quickly and efficiently (see Figure 24.6). The Workflow Designer for Exchange 2000 Server is part of the Platform SDK for Exchange 2000 Server. The Workflow Designer is not provided with this book.

Designing a Basic Workflow

If you have the Exchange 2000 Server Platform SDK CD at hand, you can install the Workflow Designer on your Windows 2000 Professional workstation by double-clicking the EXCHWFD.MSI file found in the \Workflow directory. The installation is straightforward and, with the exception of the licensing agreement and installation directory, it doesn't require much user input. If you have prepared your CDO workflow environment as outlined earlier, you will find the Workflow Designer very convenient to use.

NOTE
Before launching the Workflow Designer, start Outlook 2000 and create a public folder where you want to implement your workflow solution. If you want to use an existing folder, make sure you have the rights of a folder owner.

Selecting a Public Folder

To begin your workflow project, launch Exchange Workflow Designer from the Microsoft Exchange Workflow program group. An Open Folder dialog box will appear, asking you for server name and public folder. Accordingly, the folder URL will be created for you. For instance, if your server is called BLUESKY-SRV1, type bluesky-srv1 under Server. If you want to work with a folder called Workflow, type public/workflow under Folder, and then click OK.

The Workflow Designer will check whether you have the required permissions; if you do, it will connect to the specified folder. In the General property sheet that is displayed automatically, under Folder Is Enabled For Workflow, select Activated. After that, open the File menu, and then select New Workflow Process. In the New Workflow Process dialog box, type a descriptive name, such as Workflow Notifications, and then click OK. The Workflow Designer will open a new process definition for you automatically and ask you for the name of the first item state. Document Created might be a good name. You are free to choose whatever name best suits your purposes. Click OK.

Item States and Actions

In this simple workflow example, you already have two actions. They are Create, which brings the item into Document Created State, and Delete, which deletes the item. You may define additional states using the Insert State button on the toolbar (or open the Edit menu, point to Insert, and then select State). States must be connected through Actions, which you can insert via the Insert Action button on the toolbar or the Action command from the Edit menu under Insert. According to the events supported by the CDO workflow engine, you can define Create, Delete, Change, Receive, and Expiry actions. There are two additional action types that you can select: Enter and Exit. These allow you to invoke workflow logic when an item advances from one state to another. For instance, the Enter action is used to set an expiry timer for items that enter the state. If an item expires, an Expiry action may be triggered.

Shared VBScript Elements

For now, let's work through a very simple example of Create -> Document Created -> Delete. That gives you two actions to work with. You could inform the Administrator, for instance, whenever new items are posted to the workflow public folder, and you may inform the Administrator again if an item is deleted. Only a few lines of VBScript code are necessary to implement this functionality.

In the Workflow Designer, click on the Shared Script tab, and type in the following script code (SCRIPT9CH24.VBS):

 Sub SendNotification (strRecipient, strSubject, strMsgText, bAddURL)    Set oMsg = WorkflowSession.GetNewWorkflowMessage    oMsg.To = strRecipient    oMsg.Subject = strSubject     If bAddURL = True Then       oMsg.TextBody = strMsgText & " " _           & "<Outlook://Public Folders/All Public Folders/Workflow/" _           & WorkflowSession.Fields("DAV:displayname") & ">"     Else       oMsg.TextBody = strMsgText     End If        oMsg.SendWorkflowMessage 0 End Sub

Click on the Design tab again, select the Create action, and, under Action Script Procedure, type the following lines to inform the Administrator about new items (SCRIPT10CH24.VBS):

 SendNotification "Administrator@Bluesky-inc-10.com",  _     "Workflow document Posted",  _     "The following document was posted to the workflow folder", _     True

Select Delete, and then, under Action Script Procedure, type in a slightly different version of the procedure call to inform the owner of the document about its deletion (SCRIPT11CH24.VBS):

 SendNotification "Administrator@Bluesky-inc-10.com", _     "Workflow Document Deletion", _     "The document was deleted from the workflow folder", _     False

Click on the General tab, and then select the Default Workflow Process For This Folder check box. Do not select the Run As Privileged check box unless you have granted yourself unlimited workflow permissions, as explained earlier in this lesson. Open the File menu, and select Save All Changes. To test the workflow, switch to Outlook 2000. When you post a new item, the Administrator will receive a notification, which includes an Outlook URL to the document in the workflow folder (see Figure 24.7). When an item is deleted, a slightly different notification is generated.

click to view at full size

Figure 24.7 Creating a simple workflow example

CDO for Workflow Interfaces

As demonstrated, the Workflow Designer and CDO for Workflow enable you to design workflow solutions without the need for fundamental programming to access the Web Storage System. However, to implement sophisticated workflow logic, advanced script code is required. CDO for Workflow provides you with one important intrinsic object that was already used in the previous example the WorkflowSession object. This object provides access to the process instance (the workflow item) and to the workflow message object (IWorkflowMessage) without requiring you to use CreateObject for messaging—Set oMsg = CreateObject("CDO.Message") would only be possible in privileged mode.

CDO for Workflow provides the following programmatic interfaces:

IAuditTrail. To write error entries during a state transition in an audit trail.
IProcessDefinition. To manage ProcessDefinition objects stored as items in public folders.
IProcessInstance. To access the workflow items in a workflow-enabled folder. For every new item that is sent or posted to a workflow folder, a ProcessInstance object is created.
IWorkflowSession. The intrinsic workflow object passed to conditions and actions in a workflow process to communicate with the workflow engine at run time.
IWorkflowMessage. To support e-mail notifications in restricted workflow and to track responses to a ProcessInstance object. The workflow system account must be mailbox-enabled to support workflow messages.

You can find detailed information about the CDOWF programming interfaces and their purposes along with sample code that demonstrates their usage in the Exchange 2000 Server Platform SDK.