Never use Thread.Sleep in SharePoint Workflows

From last 2 months, i was very busy in developing custom workflows. So, I didn't get chance to blog my experience during all these days. I really got great experience by working on a custom workflow. I am trying to put my experience in various posts including this post.

Coming to the main point, never ever use Thread.Sleep in SharePoint workflows

Reason: If we deploy the custom workflow with Thread.Sleep instructions, then IISReset will keep these instructions out of memory and the workflow will struck there.
Alternative: Use appropriate inbuilt or custom workflow activities.

How To: Choose between InfoPath Browser Forms and Custom ASPX Forms

Choosing between InfoPath forms and ASPX pages, depends totally on the nature of the problems we are solving on one side and level of skill set we are investing in solving that problem on the other side. Usually, in most cases, any manager or developer would want to use InfoPath Forms part of Office 2007 because it’s quick and easy. But, as the requirements get more complex and requires more and more customization, one might feel its better to go with ASPX pages and Visual Studio 2005 and SharePoint designer. Technically, InfoPath Forms by itself is incomplete; It needs a container which is again an ASPX web form using the XmlViewer web part. If we go with custom ASPX form, then it has to be designed either using SharePoint designer or Visual Studio leveraging web parts to show the required forms. So for this, developing web parts and its complexity needs to be taken into consideration.
So, to decide on one, we may have to take the decision step by step.

If the requirement is for a single form and showing data from an external data store or from within SharePoint, then going with InfoPath Forms is recommended.

If it’s a single form and needs complex actions, to and fro between the form and the data store, then choosing custom aspx pages is recommended.

If the requirement needs wizard kind of feature i.e. which requires user to go through multiple screens, then custom aspx is the solution.

If the data submitted through the form has to be saved to multiple locations (database, SharePoint, file storage) then InfoPath Forms is a good solution.

If the requirement is for designing numerous forms which are simple enough and well documented, then InfoPath Forms should be considered. InfoPath can help deliver the solution in a short time period.

InfoPath browser based forms has few limitations on the repository of controls one can use. For example: combo box, master/detail view control and many advanced controls are not supported in browser based InfoPath Forms. Depending on these limitations we have to decide on InfoPath or ASPX. ASPX has no such limitations.

InfoPath forms is based on XML. The form is rendered using XSLT stylesheets and the data submitted through the form is available in XML format. The data is well structured to retrieve later on and dump the data/forms in some external system. This in combination with BizTalk server is a perfect architecture for document transition through multiple levels.

InfoPath forms certainly have an edge over ASPX forms as a quick and neat solution. It has some complex out of the box controls, like date picker, file attachment control, repeating sections. InfoPath forms can also have code-behind if needed to manipulate the data on the form or behind the form.

ASPX can have and do everything InfoPath Forms does, with an exception of additional development effort. Apart from it, the deployment process of aspx forms is much better and easier than InfoPath Forms.

Below are some of the excerpts from few blogs I follow which provides some valuable input comparing InfoPath and ASPX forms. Below are the Pros and Cons in using InfoPath Forms:

Pros:

• Ideal for simple forms
• Easy to build a form – no coding involved
• InfoPath form itself is an xml document.
• Support versioning
• Works very nicely with SharePoint custom workflows as a workflow association tool.
• Fully integrated in Microsoft Office 2007 suites like Outlook e-mail messages that can be deployed as Outlook e-mail messages, so colleagues can complete forms without leaving the familiar Outlook environment.
• Firewall friendly. InfoPath Forms Services make it easy to extend forms solutions beyond firewall because of using many different Web browsers and mobile devices.
• InfoPath can easily convert Word documents and Excel spreadsheets to forms and build templates to work with.
• InfoPath provides data integrity and version control for document management purposes, and add structure to information gathering by converting legacy documents to rich InfoPath form templates.
• Design of a form is much easier in InfoPath forms with a simple drag-and-drop interface and provides support for prebuilt template parts and shared data connections.
• Creates PDF or XPS and other important document formats and is extensible by addition of a free plug-in to install third party tools and components for document, archival and records management
• Fully integrated with MOSS 2007 and capable of using integrated workflow management tools in Office 2007
• Fully Web browsed technology, includes a design checker to help ensure consistency for forms.
• Support for information rights management to help manage permission control and building a powerful document management team site.
• Fully centralized for entire organization and enables organizations to centrally

Cons:

• A web browser-enabled InfoPath form does not support all features of InfoPath client.
• Inflexible — Difficult or impossible to customize (well, you can argue that you can hack the xsl file of InfoPath)
• No support for image buttons
• No support for html
• No support for tree control
• Difficult to support Forms Based Authentication
• By default, InfoPath cannot support SharePoint web services data connections in FBA.
• Forms Services does not support username() function in FBA. This means that InfoPath form does not recognize the current user.
• Difficult to perform automated web test against Forms Services.
• Difficult to support automated deployment. Basically, you have to unzip the xsn file and programmatically modify the manifest.xsf file, and zip back to the xsn file for automated publishing.
• The way that Forms Services supports deployment of InfoPath forms is quirky – It creates SharePoint solution packages with GUID and creates features with meaningless names on the SharePoint Features folder.

Note: The above content is taken from following link: http://sharenotes.wordpress.com/2008/06/02/how-to-choose-between-infopath-forms-and-custom-aspx-forms/

Below are the blog links which talk more about this topic:
http://www.jyhuh.com/blog/archive/2008/03/02/AspNet_vs_InfoPath_Forms_Services.aspx
http://office12.blogspot.com/2007/06/infopath-web-forms-vs-aspx.html

Workflows: Major Microsoft.Windows.SharePoint.Workflow Objects

The Microsoft.SharePoint.Workflow namespace represents the workflow functionality contained in Windows SharePoint Services.

• SPWorkflowTemplateCollection object: Represents the workflow templates currently deployed on a site.
• SPWorkflowTemplate object: Represents a workflow template and contains properties you can use to get or set information about the template, such as the instantiation data and the history and task lists for the template.
• To associate a workflow to a list or document library, use the AddWorkflowAssociation method of the SPList object.
• To associate a workflow with a content type, use the AddWorkflowAssociation method of the SPContentType object.
• To create the appropriate workflow association, use the CreateListAssociation, CreateListContentTypeAssociation, or CreateSiteContentTypeAssociation method of the SPWorkflowAssociation object itself.
• Use the RemoveWorkflowAssociation method to remove a workflow association from a list.
• Use the RemoveWorkflowAssociation method to remove a workflow association from a site or list content type.
• Each SPWorkflowAssociation object represents a workflow template that is associated with a specific list or content type, and that contains properties that return custom information about that workflow's association with the specific list or content type. This information includes whether the workflow is enabled, whether the workflow can be started automatically, and the list or content type with which the workflow has been associated.
• The SPWorkflowCollection represents the workflow instances that have run or are currently running on a given list item.
• Each SPWorkflow object contains properties that return information about the workflow instance, such as whether the workflow has completed, its internal state, and its workflow history list.
• Use the Workflows property to return an SPWorkflowCollection object that represents the workflows currently running for that list item.

Managing Running Workflow Instances Programmatically
Users interact with the workflows running on items individually, through the Windows SharePoint Services user interface. But Windows SharePoint Services provides functionality for you to centrally control the running instances of workflows across your site collection through the object model. Use the SPWorkflowManager object to manage the running instances of workflows across a site collection. The SPWorkflowManager object has no equivalent in the user interface. Use the SPWorkflowManager object to:

• Start, run, or cancel workflows.
• Return all the workflows currently running on a specific item.
• Perform other workflow administration operations.

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.