MOSS 2007 Workflow Forms: Everything you ever wanted to know but were afraid to ask (Part I)

Background
What differentiates a workflow from a typical process written in code is the ability of multiple actors (human or otherwise) to interact with the long-running workflow process during the course of execution. This allows the executing process to behave in a manner that external actors want it to, as opposed to just performing a sequence of operations along a single pre-defined path. The rule-of-thumb while choosing between Sequential and State-Machine Workflows is based on a simple premise based on the scenario for which the workflow is being created:

• Sequential Workflow: Use when a pre-defined sequence of activities need to be executed, involving no external input, and the only repetitive activity executions are through loops.


• State-Machine Workflow: Use when external actors are involved, causing the workflow to stop and wait for input from the actor. Also use if the same activity needs to be executed multiple times based on a user-input or external event during the course of workflow execution.

Note: You can choose to use a Sequential workflow even when external actor interaction is involved. However, this will not allow you to jump to another activity, other than the one next in the sequence.

Developing a State-Machine workflow in Visual Studio 2005
Read the following posts to learn how to develop a state-machine workflow in VS 2005.

• Creating a MOSS state machine workflow - Part 1 of 4 : Concepts and planning


• Creating a MOSS state machine workflow - Part 2 of 4: Creating InfoPath forms


• Creating a MOSS state machine workflow - Part 3 of 4 : workflow development


• Creating a MOSS State Machine Workflow - Part 4 of 4: Workflow Deployment

Apart from the workflow code file (*.cs and/or *.xoml), the workflow project should include the following files:

• feature.xml (Contains information about the SharePoint feature)


• workflow.xml (Specifies the workflow properties for the SharePoint feature)


• PostBuildActions.bat (A batch file executed as a Post-build event inside Visual Studio that creates a sub-folder in the 'FEATURES' directory under 12 hive [C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE] and copies feature.xml and workflow.xml files into it; also executes the stsadm command to activate the deployed feature on a SharePoint site)

Note: You can avoid creating the PostBuildActions.bat file if you use WSPBuilder to generate a SharePoint solution file (*.wsp) and deploy it from within the VS2005 environment.

The life-cycle of a workflow involves the following stages:

1. Development: Visually creating the workflow in VS2005/VS2008 Workflow Designer and writing code for each activity. Also includes creating workflow.xml, feature.xml, and PostBuildActions.bat


2. Deployment: Deploying the workflow to a SharePoint Server farm and activating it either using the PostBuildActions.bat batch file or using WSPBuilder. In either case, a new folder is created in the FEATURES directory (explained above), the workflow.xml & feature.xml files are copied to it, the workflow assembly (*.dll) is installed into the GAC or copied to the Virtual Directory's bin folder, and the stsadm command is used to activate the feature


3. Association: Attaching the workflow to a list or content type and specifying when a new workflow instance should kick-off; either manually, OR automatically when a new item is created and/or updated.


4. Execution:This stage involves the following sub-stages




• Initiation: This is the first stage for any workflow instance, happens ONLY once during the course of execution, and is marked by firing of the OnWorkflowActivated event.


• Passivation or De-hydration: This is the process of persisting the workflow instance to a datastore so that it can subsequently re-loaded into memory for further execution. Also, passivation or dehydration occurs when the workflow instance wants to wait for an external input or event to execute further.


• Re-hydration: This stage involves the workflow instance being loaded back into memory by the workflow engine, after a user input is received OR an external event fires.


• Activity Execution: This is characterized by the workflow engine executing the code in each of the workflow activities in the defined sequence, or transitioning states in case of a state-machine workflow.


• Modification: This stage is optional, but it allows workflow actors to inject new values into the workflow instance while it is in execution to alter its behavior. This also entails that the workflow has the logic built into it to process the new values.




5. Completion: The competion stage is marked by the workflow instance completing execution successfully, and the status being written to the data store.


6. Termination: This stage refers to the workflow instance stopping abruptly due to an internal error, or an actor explicitly ending the workflow instance. Any data written to the list by the workflow instance is NOT rolled-back if the workflow is terminated. Terminated workflows cannot be restarted again.

Having got the above off my chest, lets delve into how users (workflow actors) interact with the workflow.

Workflow Forms
Workflows Forms (as the name implies) are typical forms that allow user input to be communicated to the workflow. In addition, workflow forms also allow data within the workflow to be presented to the actor so that they can take appropriate action. The 4 types of workflow forms that can be created are:

1. Association Forms: Displayed to the user at the time the workflow is being associated to a list or content type to allow user to enter any additional values that can be used in the workflow association process.


2. Initiation Forms: When the users initiates a workflow instance, the Initiation Form is displayed to allow entry of additional parameter values that the workflow instance can process during execution.


3. Modification Forms: Modofication forms are displayed either when the workflow instance encounters the EnableWorkflowModification activity, OR the user clicks the Modification link on the workflow status page.


4. Task Forms: During execution, a workflow creates tasks in the Tasks List that tell the user what they need to do, and in most cases, move the workflow forward when a task is marked as complete. From the users' perspective, tasks enable them to know where the workflow stands, and what needs to be done to get to the next process in the flow sequence.

In my next post, I will cover how to develop each of the Workflow forms in a state-machine workflow using both ASP.NET and Microsoft InfoPath 2007.