Workflows: Comparing the Visual Studio Designer for Windows Workflow Foundation and SharePoint Designer 2007

The following sections offer a detailed comparison between the capabilities offered by the Visual Studio Designer for Windows Workflow Foundation and Office SharePoint Designer 2007, and the workflows you can create with each.

Visual Studio 2005 Designer

• Can write workflows for Windows SharePoint Services or SharePoint Server
• Code-behind file enables developer to write custom Visual C# or Visual Basic .NET code to express business logic
• Generates workflow markup file
• Workflow is authored as a template, which can be associated with multiple sites and lists
• Workflow markup file, or markup and code-behind files, are compiled into workflow assembly
• Workflow template must be associated with each list on which it is to be available
• Can use any forms technology. For example, ASP forms for Windows SharePoint Services workflows, or InfoPath forms for SharePoint Server workflows
• Can include workflow modifications
• Can use custom symmetrical InfoPath forms, which enables Office client integration of custom workflow forms
• Can author custom activities for inclusion in workflows
• Package workflow assembly and workflow definition as a SharePoint feature, and deploy to the site
• Can use Initiation form to gather information from the user when starting the workflow
• Can use custom forms for users to interact with SharePoint tasks
• Visual Studio debugging available
• Can author both sequential and state workflows

SharePoint Designer 2007

• Can write workflows for Windows SharePoint Services or SharePoint Server
• No code-behind file; workflow rules file declaratively encapsulates business logic
• Generates workflow markup file
• Workflow is authored against and data-bound to specific list at design time
• Workflow markup, workflow rules, and supporting file are stored, uncompiled, in a specific document library on the site
• Association happens when the workflow is authored against the specific list; no later association is necessary or possible
• Automatically generates ASP.NET forms, which you can then customize
• Workflow modifications are not available
• InfoPath forms integration not available
• Must use activities provided
• Automatically handles deployment to specific list
• Can use Initiation form to gather information from the user when starting the workflow
• Can use custom forms for users to interact with SharePoint tasks
• No step-by-step debugging available
• Can author only sequential workflows

Workflows: Workflow Architecture

The workflow functionality in Windows SharePoint Services 3.0 is built on the Windows Workflow Foundation (WF), a Microsoft Windows platform component that provides a programming infrastructure and tools for development and execution of workflow-based applications. WF simplifies the process of asynchronous programming to create stateful, long-running, and persistent workflow applications. The WF run-time engine manages workflow execution and allows workflows to remain active for long periods of time and to survive restarting the computer. Run-time services offer functionality such as transactions and persistence to manage errors gracefully and correctly.

The WF run-time engine provides the services that every workflow application needs, such as sequencing, state management, tracking capabilities, and transaction support. The WF run-time engine serves as a state machine responsible for loading and unloading workflows, as well as managing the current state of any workflows that are running. WF allows any application process or service container to run workflows by hosting WF — that is, loading WF within its process. Windows SharePoint Services hosts the WF run-time engine. In place of the pluggable services that are included with WF, Windows SharePoint Services provides custom implementations of the following services for the engine: transaction, persistence, notifications, roles, tracking, and messaging. Developers can then create workflow solutions that run within Windows SharePoint Services.

Following Figure shows the workflow architecture in Windows SharePoint Services. Windows SharePoint Services hosts the WF run-time engine within its process, and provides custom implementations of the necessary services. The functionality of the WF run-time engine, as well as the hosting functionality Windows SharePoint Services provides, is exposed through the Windows SharePoint Services object model.

Workflows: Workflows in WSS 3.0 and MOSS 2007

Workflow Templates and Instances
In Windows SharePoint Services, workflows that are available on a site or list are referred to as workflow templates; a workflow that is actually running on a specific SharePoint item is called a workflow instance. So, on a given list, several instances of the same workflow template may be running at the same time, each on a different SharePoint item. More than one workflow can be running on a given SharePoint item at a time.
Points of User Interaction with Workflows
Let's look more closely at the various stages at which users can interact with workflows in Windows SharePoint Services and SharePoint Server.

A. Association
Association occurs when a site administrator makes the workflow template available on a specific document library, list, or content type. At this stage, the site administrator customizes the workflow for this specific document library, list, or content type by specifying the following parameter information:

• A unique name for the workflow
• How the workflow is applied to a given item: either automatically when the item is created or changed, or manually; and which roles, such as Administrator or Contributor, can start a workflow
• The Task list, in which the workflow can create tasks
• The History list in which the workflow can store history events, as defined by the workflow

In addition, the workflow developer can enable the site administration to further customize the workflow by setting parameter information specific to the particular workflow. The administrator may have to specify parameters, default values, and other information for the workflow as it applies to items on the list, library, or content type with which the administrator is associating it.
Associating a workflow actually occurs outside the workflow itself; no workflow instance is actually started during association. Rather, Windows SharePoint Services stores the association information in a special internal workflow association table. Then, when the workflow instance is actually started, Windows SharePoint Services uses the association data (and the initiation data, if any) to set the parameters of the new workflow instance.

B. Initiation
Whereas association deals with the workflow as it applies to a specific list, library, or content type, initiation deals with the workflow as it applies to a specific SharePoint item.
Initiation occurs when a user actually starts a workflow instance on a specific item. The user supplies information custom to that specific workflow on that item, if necessary, and then starts the workflow.
Workflow developers can use initiation to let users override or append the association parameters set by administrators, or specify additional parameters or information about the workflow as it applies to the given SharePoint item. Not all workflows need initiation. In fact, a workflow set to start automatically cannot have initiation parameters.
The Windows SharePoint Services workflow project for the Visual Studio 2008 Designer for Windows Workflow Foundation includes an activity that acts as the event handler when the workflow is initiated. This activity is the first activity in any Windows SharePoint Services workflow.

C. Modification
Modifications enable users to alter the parameters or flow of a workflow instance as it is running. As a developer, you may have points in your workflow at which you would like to enable users to alter the workflow while it is running on an item. For example, you might want to enable a user to assign a task to another person, or even add a specific task to the workflow. The options you present to users to change the workflow as it is running on an item are called modifications.
The Windows SharePoint Services workflow project for the Visual Studio 2008 Designer for Windows Workflow Foundation includes an activity to enable a workflow modification, as well as an activity that acts as an event handler when a workflow modification is enabled.

D. Tasks
Workflow activities that are performed by people are represented as tasks in Windows SharePoint Services workflows.
As workflow author, you can specify the task schema. For example, the task listing could include the following:

• Task title
• Name of person to whom the task is assigned
• Task status
• Task priority
• Task date due
• A link to the referenced item

The user can then edit the task as necessary. The workflow instance is notified of changes to workflow tasks and can choose to respond to them as specified in the workflow.
The Windows SharePoint Services workflow project for the Visual Studio 2008 Designer for Windows Workflow Foundation includes activities that create, delete, and update tasks, as well as activities that act as event handlers when tasks are created, updated, or deleted.

One webpart for Intranet, Extranet & Internet

Today, I came across with a scenario "One webpart for Intranet, Extranet & Internet".

Requirement: "The web part supports multiple data sources. All data sources are not common for Intranet, Extranet & Internet versions. Based on the version, we have to show only corresponding data sources."

Example:We have a news web part with following data sources support:

• news pages from an intranet site which are created with a News content type.
• current/local site collection which has pages of a particular content type (this content type is similar to News content type but with few more fields additional)
• RSS Feed - This is generic RSS feed support. So, RSS defined in intranet, extranet or internet sites should be handled in similar manner. Ofcourse, RSS content xml format is not different than general RSS content xml format.

For INTRANET, News web part should show all the above data sources.
For INTERNET & EXTRANET, News web part should show the data sources mentioned in (b) and (c).
NOTE: The configuration should be hidden from end user who can see web part toolpane.

Solution:
Step1: Add a property in newswebpart.webpart file (this is an xml file) under ///
Step2: Add a browsable property in the web part C# file. Don't forget to set
WebBrowsable(false) for this property. This allows us to hide the configuration for data source support in web part toolpane.
Step3: Include a condition in web part tool pane display data sources based on the value of the property set.

Note: We can implement above in other ways also but I opted above to allow configuration from webpart xml file instead of modifying in the C# code or from web part toolpane.

Call JavaScript function from C#

Following describes the steps to call a javascript from C# code:
Let us assume that javascript function is residing in an external javascript file, then follow below steps:

Step1: Register the javascript file

this.Page.ClientScript.RegisterClientScriptInclude(this.GetType(), "NewsWebPart.js", siteCollectionRootUrl + "_LAYOUTS/Monsanto/MPS/NewsWebPart/js/NewsWebPart.js");

You can check the syntax for RegisterClientScriptInclude in .NET API.

Step2: Create HTML Generic Control for script tag and add attribute values.
HtmlGenericControl inlineScript = new HtmlGenericControl("script");
inlineScript.Attributes.Add("type", "text/javascript");
inlineScript.Attributes.Add("language", "javascript");

Step3: Call the javascript function
inlineScript.InnerHtml = "MakeConnectionRotateRequest("
+ "'" + SourceUrl + "'");";

In the above, you can see the javascript call by including parameter values from C# variables.

Step4: Include the HTML Generic control in the page
this.Controls.Add(inlineScript);