Workflow Design
Workflow Design
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
You can develop workflow applications by making direct calls to the ProcessDefinition object. You can use Microsoft® ActiveX® Data Objects (ADO), OLE DB, or WebDAV to create the necessary data bindings.
To develop a workflow application using any language that supports COM
- Define an action table.
- Develop script functions or custom Component Object Model (COM) objects to represent your business logic.
- Create a ProcessDefinition.
- Register the workflow event sink in the workflow folder.
The first three steps constitute your workflow design. In the final step, you save your workflow design as an item in a public folder and create an association between the workflow event sink and Exchange store synchronous events. For more information about registering a workflow event sink, see Registering a Workflow Event Sink in a Folder.
Defining an Action Table
The action table encapsulates the logic of your design. You define the action table by outlining the rules for documents that are saved or posted in the specified folder. A rule tells the workflow engine to execute a given action when a document is in a given state and a given condition is true. Each row in the table addresses a combination of state, condition, and action. The ActionTable schema includes fourteen properties that are defined in the ActionTable Property of the IProcessDefinition Interface.
Developing Script Functions
Action table fields include Condition, Action, and CompensatingAction. You can include script functions within these fields, and you can reference a CommonScript item in any of these fields by using the CommonScriptURL Property. You can declare the CommonScript as a separate item or include it as the default stream of the IProcessDefinition item.
If you are a privileged workflow author, you can use a COM object as a Condition, Action, or CompensatingAction, in which case the ActionTable contains the programmatic identifier (PROGID) for your COM object in the respective field(s). The ActionTable requires that you set flags indicating whether conditions and actions contain COM objects or script.
Creating a ProcessDefinition
After you have created the two previous pieces of your workflow design — the action table and the CommonScript — you can associate them with a ProcessDefinition object. You can then set other important properties of your design, such as the following.
- The security mode that you want the process to execute under (Mode Property).
- The logging tool you want to use for monitoring and debugging your design (AuditTrailProvider Property).
After you set the ProcessDefinition properties, save them as an item in the workflow folder by using their DataSource Property. You can also use the ADO Fields collection with the Exchange store schema property names to set these values. If you have physical access to the server, you can use CDO for Workflow (CDOWF) interfaces to set these properties. For remote scenarios, you need to use ADO.
The topics in this section provide additional information about defining action tables and creating process definitions.
Send us your feedback about the Microsoft Exchange Server 2003 SDK.
Build: June 2007 (2007.618.1)
© 2003-2006 Microsoft Corporation. All rights reserved. Terms of use.