The term workflow is used to describe applications that are developed as business processes. Workflow applications include forms routing and approval, document review and publishing, and issue tracking.
To develop a workflow application
Always plan your application before starting. A workflow application consists of forms and documents that a user manipulates and tools on the server that manage those documents according to a set of rules. The application architecture is comprised of a presentation layer and a business logic layer.
Presentation Layer
A workflow application includes forms or documents with which the user interacts directly. This layer is also called the front-end layer of the application and it could be a Microsoft® Word document, a Microsoft® Outlook® form, or some other presentation that you design. These all work, because workflows are triggered by any save or post in the workflow folder, and the Microsoft® Exchange 2000 Server Web Store provides heterogeneous document storage. Whatever you use as your front-end layer is up to you and has no relation to the functionality addressed by CDO Workflow objects. This layer is independent of CDO Workflow objects and usually runs on a client computer.
Business Logic Layer
You use CDO Workflow Objects to design and run workflow applications. These applications contain the business rules that govern your document approval and routing processes. While the presentation layer usually runs on a separate client computer, the business rules run on the server with the Web Store, where the target documents are stored. Your business logic or also known as a workflow layer operates in a separate process from the Web Store process. You can create the workflow process using any language and create event sinks; you can use the Workflow Designer for Exchange 2000 Server in the Microsoft development environment.
Workflow Applications
Workflow processes are used to enforce business rules, such as who sees an item, the sequence of events an item goes through, the routing of an item, or even when an item can be created or deleted. The Workflow Designer for Exchange 2000 Server creates workflow processes specifically for Exchange folders. When workflow is applied to a folder, all items in that folder must conform to the information flow created by the workflow process.
A workflow process is made up of a series of tasks and events, the order in which they must occur, and the script that is executed for each event or transition. Simply said, a workflow process automates and enforces the order of tasks.
The Workflow Designer for Exchange Server uses a graphical user interface (GUI) to represent the workflow process as a diagram that can be edited. The conceptual model for a workflow process in the Workflow Designer for Exchange Server includes states, events, and transitions.
|
Workflow component |
Description |
| State | A state defines the current status of an item in the workflow process, such as Resolved. |
| Event | An event defines the operations that can be performed on an item, such as Create. In addition, workflow events can be used to trigger scripts. |
| Transition | A transition moves an item from one state to another. Change is an example of an event that can be used to cause a transition. When creating a transition, in addition to selecting the event, you also must specify the next state. |
The developer must name the empty process, when a new workflow process is created. Create and Delete events are added to this empty workflow process automatically. The Create event appears in the workflow process diagram as the starting block and the Delete event appears as the ending block. States, events, and transitions can be added to enhance the workflow process.
Workflow Process
In the diagram above of a workflow process, the rectangles represent states, the arrows represent transitions, and the squares represent the starting block (create) and the ending block (delete). The lines with bends in them (transition within), labeled Edit, represent events that do not cause state changes.
Workflow Diagram
The above diagram is an example of how the diagram looks as an actual workflow process in the Development Environment. Notice that the events, labeled Edit earlier, have transitions within the same state. These special transitions signify that an event does occur, but there is no advance in the workflow state.
Exchange Server and Public Folders
Workflow Designer for Microsoft® Exchange 2000 Server makes it possible for developers to create and to modify workflow processes for Exchange folders. Behind the scenes, the Workflow Designer uses Collaboration Data Objects (CDO) Workflow Objects for Microsoft Exchange. CDO is a set of COM components that integrates seamlessly with the Microsoft® ActiveX® Data Objects (ADO) 2.5 component.
When you create a workflow process, the Workflow Designer creates a set of rules for the selected folder and its association with an event sink. The set of rules is called a process definition, the association is called an event registration, and the event sink is the CDO Workflow Event Sink.
The CDO Workflow Event Sink is the interface between the Exchange 2000 Web Store process and the workflow engine. It is registered automatically as a COM+ application package when you install Exchange.
The association between your folder and the event sink makes it possible for the Exchange Web store to notify the event sink when an event occurs in your folder. The event sink in turn calls the workflow engine to handle the work item’s transition.
The workflow engine controls the state changes to documents in your workflow folder. It runs in response to certain system and Web store events and encapsulates the logic for advancing the state of your workflow documents. This makes it possible for you to control the status of documents you are tracking or guiding.
The engine relies on a table of events, called the action table, to evaluate and execute transitions for documents saved in the workflow-enabled folder. The Workflow Designer for Exchange Server creates the action table for you based on the states and events which you create in the workflow diagram.
When you define a workflow process using the Workflow Designer, the events you create determine how the system will respond. Adding script to these events, you customize the response further.
The Workflow Designer for Exchange Server makes it possible to create a workflow process, such as creating the action table and adding events and scripts based on values you enter in the designer. However, creating a full-blown application requires you to understand CDO Workflow Objects and how to use the ADO 2.5 component for Exchange.
Applications User Interface
An important task in developing any application is designing the user interface. An advantage of a well-designed user interface can make the application intuitive and increase user efficiency.
Your user interface could be a Microsoft® Word document, a Microsoft® Outlook® form, or another “front-end” or presentation layer you design. Whatever you use as your user interface is up to you and has no relation to the functionality addressed by CDO Workflow objects. Typically, the user interface is independent of CDO Workflow objects and runs on a client computer or in the browser.
Workflow Scripting
The built-in functionality of workflow events can be enhanced using Microsoft® Visual Basic® Scripting Edition (VBScript). Scripts associated with a workflow events are entered on the Script Editor.
A single transition, such as moving from one state to another, can trigger several different events that must occur in a particular sequence. You can control the flow of your script with conditional statements and looping statements. Using conditional statements, you can write Microsoft® Visual Basic® Scripting Edition (VBScript) code that makes decisions and repeats actions.
For each event in your workflow process, you can specify a conditional statement to evaluate whether a condition is True or False and, depending on the result, to specify one or more statements to run. The condition is an expression that uses a comparison operator to compare one value or variable with another.
Sales Tracking Scenario – Example
You have a sales tracking workflow process, and you want to notify the stock room when an order is marked as completed. You can use script on the Change event to evaluate the contents of the completed field. When this field is set to Yes to indicate the order is completed, an event script procedure that sends a message to the stock room is triggered. If the condition returns False, the event is stopped, and the event script is not executed.
Change Event
The above illustration shows a state called “Active” that has a Change event used to create a transition to a state called Resolved. When an item in the folder is changed, the condition is evaluated. If the condition is set to False or if a function called by the statement returns False, the transition does not occur, and the event script associated with Change — in this case, a call to a procedure called SendMail — is not executed.
In many applications, particularly document-approval applications, you might want to make it possible for editing updates that do not advance the workflow state. In such a case, you can add a Transition-Within Change event.
Multiple Change Events
For example, the above illustration shows a portion of an order entry workflow process. As an order is updated, the Change event is triggered many times before the order is filled. A Change event called UpdateItem has been added to the OrderCompleted state. There is another Change event on this state called CompleteOrder.
The CompleteOrder event calls a function that evaluates a field called OrderCompleted. Each time the order is updated, both change events are triggered. However, the CompleteOrder transition does not occur until the OrderCompleted field is set to True by the user.
Planning a Workflow Process for Exchange Server
The Workflow Designer for Exchange 2000 Server automates many of the activities required to create a workflow process for Exchange 2000 Server
When the workflow process is created, issues, such as how the application will look (the user interface) and how the users will interact with objects, must be considered. These elements must be created outside of the Workflow Designer.
In addition, because a workflow application depends on security and permissions from Exchange 2000 Server and from the operating system, these permissions and privileges must be reviewed carefully before beginning development.
Development Steps
The following guidelines are designed to help you design a workflow process using the Workflow Designer in the Microsoft Development Environment.
To design a workflow process
1. Identify the business processes associated with the information you are tracking in your folder. For example, you might have a folder that contains information about employee issues and resolutions. The business process to track this information might be defined as a system for initiating, commenting, and resolving employee issues.
2. Identify the steps in your business process, and determine the events and conditions, such as routing and mail services, you want to associate with each step. For example, when an issue is entered and set to Active, a message can be sent to the manager indicating there is a new, Active issue. When the issue is resolved, the employee who entered the issue could receive e-mail indicating the issue resolution.
3. Create a new workflow process in the Workflow Designer, and add states and events. The steps you identified in Step 2 become the states when you determine the events and conditions required for your business process — for example, Active, Resolved, and Closed.
4. Add script as required to the workflow events associated with an event. For example, you can write a script that directs the Close event to trigger the sending of e-mail to the employee who entered the issue.
Permissions Checklist
Before beginning development of a workflow process, you must set both developer and user permissions.
For the Developer
The first sets of permissions requirements for a workflow are those enforced when you are using the Workflow Designer. They determine who can write and save workflow processes on a given server. These development issues are managed through the Microsoft® Exchange 2000 Server Active Directory Users and Computers and Components Services consoles.
The permissions settings include:
- Workflow Event Sink Identity. By default, the Workflow Event Sink is set to run under the account of the interactive user, the user currently logged onto the Exchange Server. As long as the Administrator is logged onto the server, workflow functions appropriately. However, if a non-administrative user is logged onto the server, you might start to see NetConnect errors in the Application Log. Therefore, it is suggested that you change the Identity to a particular Administrative user.
- Are you a folder owner? Only folder owners can modify application-design elements, such as schema, forms, views, and workflow, of a folder. If you are not a folder owner, it will not be possible for you to use the Workflow Designer. Folder owner permissions can be granted from Exchange 2000 System Manager or from Microsoft® Outlook®. If you create a folder, you automatically become a folder owner.
- Has the server administrator granted you permissions to register workflows? Not every folder owner has permissions to write workflows. Users also must have permissions to register the CDO Workflow Event Sink. The server administrator determines who has permissions to register the event sink by managing membership in the Can Register Workflow role. Only users and groups listed in this role can register workflows on a particular server.
- What kinds of activities are you going to require in your workflow script? By default, workflow processes run in Restricted mode, which means script procedures associated with workflow actions are limited to modifying properties of the document undergoing workflow, sending notification mail, and writing to the AuditTrail. The server administrator determines who has permissions to run scripts requiring Privileged mode by managing membership in the Privileged Workflow Authors role. If your workflow processes must perform more complex script driven operations, then either you or the group in which you are registered must be a member of the Privileged Workflow Authors role.
Component Services
The above is an example of the Exchange 2000 Server Active Directory Users and Computers and Components Services consoles.
For the User
The second set of permission requirements apply to the items undergoing workflow at run time. The typical requirements for any Exchange application include:
- Does the user have write permissions? Users who modify, edit, or approve items undergoing workflow must have write permissions to those items. Permissions can be assigned at the folder-level or item-level programmatically or by using Microsoft® Outlook® or Microsoft® Exchange 2000 System Manager.
- Does the user have read permissions? Users who must open the contents of items, follow a URL to an item, or view the workflow items in a window must have read permissions to the items.
