Revisting Workflows in Sharepoint - Part 2

Creating workflows using Sharepoint Designer
It should be noted that any workflow you create using Sharepoint Designer is effectively a sequential workflow, wherein you define the sequence of the steps to be performed. Each step being composed of actions and conditions. Any new functionality would require you to create new custom activity in VS.NET and deploy it as an action such that it could be used from within Sharepoint Designer.

Some of the stuff noted in case of sharepoint designer (SD) :
a.) It does not allow for coding/scripting. The best you can define are rules.
b.) The association with a list/library/content type is done immediately when the workflow is first created.
c.) Unlike workflows created in VS.NET, SD does not allow for modification of active workflow.

Breaking out from SD
In case the limitations of sharepoint designer gets on your head, you might want to export the workflow from sharepoint designer to VS.NET. For this :

a.) Export the workflow as an FWP from within the designer.
b.) Rename .FWP to .CAB.
c.) Extract the .CAB file.
d.) Open the extracted .XOML, rules and other files from within VS.NET.

VS.NET namespaces
In addition to the activities which WWF provides, MOSS adds onto this list by enhancing the Base Activity Library (BAL) using custom activities. These activities are available in Microsoft.Sharepoint.WorkflowActions & Microsoft.Sharepoint.Workflow.

Interaction Points
From a developer perspective, there are usually four points in the life of a workflow task when the end user can interact with the workflow. Effectively, its these four interaction points that can be handled/customised by the developer.

Association : When the workflow template is associated the first time with a library/document/content type.
Initialization : When the workflow instance is initialized/created.
Completion : When each user completes their task/step.
Modification : When the workflow itself is modified.

All of the above interactions require you to create custom ASPX pages (for both WSS and MOSS). In case of MOSS, you also have the option to create these forms in InfoPath, which tends to be a lot easier to develop. The table at this blog should clear up any queries regarding which event to handle at each of the interaction points.

Developer Notes
1.) Unlike a WWF workflow, the base class the sharepoint workflow is either SharePointSequentialWorkflowActivity or SharePointStateWorkflowActivity based on your workflow type (sequential or state).
2.) OnWorkFloActivated needs to be first activity for a sharepoint workflow.
3.) Correlation Token (we had discussed this in an earlier post) needs to be set the same for the related activities.
4.) In WWF while you must have used ExternalDataExchangeAttribute , in MOSS most of the data exchange stuff is handled internally. (Is this a right assumption ?)
5.) DependencyProperty makes it simpler to access workflow object properties which are available after activation.