| Platform SDK: Exchange 2000 Server |
[This is preliminary documentation and subject to change.]
Advanced developers can write their own workflow applications without using the Workflow Designer by making direct calls to the ProcessDefinition object and using Microsoft® ActiveX® Data Objects to create the necessary data bindings. You can also write your own workflow event sink, for calling the workflow engine directly, using the IProcessInstance object.
To write a workflow event sink
In other words, you save your workflow design as an item in a public folder and create an association between the workflow event sink and system and Web Store events in the folder. The following sections describe each step briefly.
The ActionTable encapsulates the logic of your design—the ProcessDefinition. You define the ActionTable by laying out the rules for what to do with documents that are saved or posted in the folder. A rule tells the workflow engine, "If a document is in a given state and a given condition is true, execute the given action." Each row in the table addresses a different combination of state, condition, and action. The ActionTable schema includes 13 properties that are explained in more detail later in this documentation.
Three of the ActionTable properties are Condition, Action, and CompensatingAction. You may include script functions within these fields of the ActionTable, and/or you may have a reference to a CommonScript function in any of these fields. You can declare the CommonScript as a separate item, include it as the default stream of the ProcessDefinition item, or attach it to the ProcessDefinition item.
If you are a privileged workflow author you may use a COM object as a Condition, Action, or CompensatingAction, in which case the ActionTable contains the ProgID of your COM object in the respective field(s). The ActionTable requires you to set flags indicating whether conditions and actions contain COM objects or script.
You have already created the two mission critical pieces of your workflow design—the ActionTable and the CommonScript. Now you associate them with a ProcessDefinition object and set other important properties of your design such as:
Once all these are set, you persist the ProcessDefinition as an item in the workflow folder using the convenient DataSource property of the ProcessDefinition. Alternatively, you can use the ActiveX Data Objects Fields collection with the raw schema property names to set these values. If you have physical access to the server you may use CDO Workflow to set these properties. For remote scenarios you will need to use ADO.
You need to register the workflow event sink for the following three events.
You do this by creating a new ADO record that represents a store event registration for the event you want your workflow application to trap. Creating the record includes setting Web Store schema properties to identify the event type, the ProgID of the workflow event sink, and any other necessary information.
You set two properties on the registration item to configure your application. The first is the AllowAdhoc property that tells the workflow runtime environment whether to allow individual workflow processes to define their own behavior. In this case, new items can contain their own ProcessDefinition. You set the DefaultProcessDefinition property to tell the runtime environment what the default behavior will be for documents in the folder. This is necessary in cases where ad hoc process are not allowed, or ad hoc process are allowed but a new item doesn't contain its own ProcessDefinition. You also use the registration item to enable the Just-In-Time (JIT) script debugger and to limit the types of entries made in the audit trail.
A new item in a workflow folder becomes a ProcessInstance unless it was mailed and can be correlated to an existing ProcessInstance in the folder. You don't have to do anything to create the ProcessInstance object. The event sink takes care of this whenever an item is saved or mailed to the folder. Normally, you won't use the ProcessInstance object directly unless you want to implement your own event sink.