SharePoint 2007 incorporates an infrastructure that supports the use of existing document-centric workflows as well as the creation of new document-centric workflows by either developers or information workers.

 Windows Workflow Foundation (WF) forms the basis of the SharePoint 2007 workflow functionality. Windows Workflow Foundation is a part of the Microsoft .NET Framework 3.0.

Note: The Microsoft .NET Framework 3.0 was formerly known as WinFX. It adds four new technologies to the
.NET Framework 2.0: Windows Workflow Foundation, Windows Communication Foundation (WCF, formerly known
as Indigo), Windows Presentation Foundation (WPF, formerly known as Avalon), and Windows Cardspace (WCF,
formerly known as InfoCard).

Windows Workflow Foundation is not a stand-alone application; instead, it has a run-time workflow engine that can execute short-term as well as persistable workflows. The Windows Workflow Foundation run time provides additional services that are important for executing workflows such as tracking, notifications, and transactions.
Any application or service can leverage WF workflow services by hosting WF in its process. SharePoint 2007 acts as a host for WF and adds a couple of custom implementations for workflow services as well.

SharePoint 2007 offers two different tools for working with and creating workflows: SharePoint Designer 2007 and Visual Studio 2005 Designer. Both will be discussed in this chapter. SharePoint Designer 2007 is a great tool for creating ad hoc workflows. It places the tools to create workflows well within the grasp of normal information workers. Visual Studio 2005 Designer, on the other hand, allows developers to create advanced, enterprise-level workflows.

Note Actually, you can associate a workflow created in SharePoint Designer with more than one list. The
auto-generated code contains hard-coded GUIDs representing a list. If you change those GUIDs, it is possible to
associate a workflow with another list.

In the following sections, we will delve deeper into the concepts related to Windows Workflow Foundation.
Activities
I will begin by looking at the basic structure of a workflow. A workflow represents a business process that consists of a set of transactions which form a model to describe a real-world problem. Business transactions form the elementary building blocks of a business process. A business transaction involves two parties:

• The initiator is responsible for starting a business transaction by issuing some sort of
request.
• The executor is responsible for performing some kind of action based on a request.

Conceptually, the life cycle of a business transaction consists of three phases:
1. Order phase: This phase starts when the initiator makes a request for some kind of action to
be performed. This phase ends with a promise by the executor to perform that action.
2. Execution phase: In this phase, the executor performs the requested action. The action succeeds
or fails. Either way, a result is reached, thus ending this phase of the business transaction
life cycle.
3. Result phase: In this phase, the executor communicates which result was reached, which is
either accepted or rejected by the initiator.
In Windows Workflow Foundation, the abstract concept of business transactions (a concept that has meaning in the external world) is translated to activities (a concept that has meaning in the software world). Activities are the building blocks of a  workflow; every single step within a workflow requires an activity. Windows Workflow Foundation utilizes three different kinds of activities:
• Simple activity: A simple activity represents a simple action in its most basic form. An example of such a simple activity is the DelayActivity.
• Composite activity: A composite activity is an activity that aggregates one or more child activities within a single activity. An example of such a composite activity is the IfElse activity.
• Rule activity: A rule activity (also called a data-driven activity) drives the flow of a workflow. An example of this type of activity is the EventDriven activity.

Out of the box, the Windows Workflow Foundation framework contains a set of activities that provide functionality for the creation of workflows that contain control flow, conditions, event handling, and state management, and are able to communicate with other applications and services.

If you design a workflow, you can choose to make use of one of the activities belonging to this default set or you can create your own activities. Developers are free to create their own custom activity libraries and use them in other workflows. You can also use code activities to add custom code to a workflow. Code activities allow you to add basic behavior to a workflow; if you want complex behavior, such as the ability to create a composite activity that is able to contain other activities, you should create your own custom activity.

Activities can be sequential, in which case the order of workflow actions is specified at design time. Alternatively, activities can be event-driven. In such scenarios, the order of workflow actions is determined at run time in response to external events. Each activity contains the following logic/data:

• Metadata responsible for describing design time properties of the activity.
• Instance data describing the activity run-time state.
• Activity behavior in the form of programmed execution logic.
• Validation logic that can be used to validate activity metadata. This is optional.

Following figure shows a basic workflow that consists of several activities and uses custom activity libraries.



Components
Windows Workflow Foundation provides services as well as a framework and consists of the following
components (see Figure):
• Base activity library: This library contains all activities that are available out of the box.
Activities are essential building blocks for creating custom workflows and are discussed in the previous section, “Activities.”
• Runtime engine: The workflow runtime engine is able to interpret and execute workflows created using Windows Workflow Foundation. The runtime engine is also responsible for keeping track of workflow state.
• Runtime services: The WF workflow runtime engine can be hosted by different host applications, including SharePoint. This is a very flexible system, which is made possible via the workflow runtime services. The workflow runtime services are also  responsible for handling any communication between the host application and the workflow.




Windows Workflow Foundation ships with a couple important tools that facilitate workflow creation: a visual designer and a debugger.
The workflow runtime engine is hosted in-process within a host application (never as a stand-alone process) and is responsible for creating and maintaining running workflow instances. For each application domain (in .NET, the fundamental process that executes code), there can be only one workflow runtime engine. A workflow runtime engine is able to run multiple workflow
instances concurrently. The runtime engine needs to be hosted by a host process, such as a console application, Windows form-based application, ASP.NET web site, or a web service. Because a workflow is hosted in-process, it can easily and efficiently communicate with its host application.

The workflow runtime engine utilizes many WF services when a workflow instance runs. The following services are included in the runtime engine:
Besides the runtime engine itself, WF contains multiple runtime services. Runtime services are pluggable, so applications can provide these services in unique ways within their execution environment.

Workflow Styles
Windows Workflow Foundation supports two styles of workflow: sequential and state machine. Before you start creating a workflow project, it is important to figure out what style of workflow you want to use.

The sequential workflow style is used for repetitive operations such as designing a set of activities that must always be performed in the same order. The workflow follows the sequence until the last activity is completed, and the workflow always remains in control of what happens next.

Such workflows are not necessarily entirely deterministic; you can use branching logic such as IfElseActivity activities or ParallelActivity activities and let the exact sequence of events vary.
For example, imagine you are creating a workflow that describes the process of installing software. This is a typical scenario where you always follow the steps one by one and in the same order.
Therefore, you can represent this process using a sequential workflow. The following figure shows an example.



The state machine workflow style is used when you want to model your workflow as a state machine. State machine workflows are made up of different states, one being the starting state, which is the state that is entered once the workflow process begins. Each state can receive a certain set of events. Based on these events, the workflow can transition from one state to another
state. In state machine workflows, the end user is always in control. That is why this type of workflow is also known as a human-oriented workflow. It is not required to define a final state, but if you do happen to have a final state in a workflow and the transition is made to that state, the workflow will end.

An example of a state machine workflow is an online shop where one state of the workflow process describes the situation where the customer can submit an order and wait for approval of the credit card data. Another state in the workflow process describes the situation where the customer, for the time being, is satisfied with selecting a couple of products and wants to place
the order at a later time. Therefore, each customer finds himself in one of the states in the workflow process and goes to another state depending on his choices.

The following Figure shows a statemachine workflow.


Although you certainly can, you do not have to rush out and start creating your own workflows immediately, because, out of the box, SharePoint 2007 ships with a set of default workflows. They are..

Approval :
Collect Feedback:
Collect Signatures:
Disposition Approval:
Group Approval:
Issue Tracking:
Translation Management:
Three-state:

If you want to impersonate another user account to interact with the SharePoint object model, you can use the SPUserToken object. In Microsoft Office SharePoint Server 2007, several constructors of SPSite objects accept an SPUserToken object as one of the parameters to establish a different security context.

To demonstrate the use of the SPUserToken object, I will programmatically check out a file on behalf of a different user. We have created a test document called Test.doc and uploaded it to the Shared Documents document library (as shown in fig below). Make sure that versioning is enabled on the Shared Documents document library. Later in this section, we will use the version history of this
document to check whether the code involving the SPUserToken object has succeeded.



In the next example, I will programmatically check out and then check in a document. I have created a web part called SuperPart that is responsible for doing this. The code retrieves the current site collection from the current SharePoint context and gets the PrivilegesTest SharePoint site from this site collection. By default, you are not allowed to check out and check in files in SharePoint using HTTP GET requests. To get around that, my code sample allows unsafe updates on the PrivilegesTest SharePoint site. An instance of SPFile associated with the test document can be retrieved from the PrivilegesTest SPWeb instance. Finally, the code adds some information to the test document’s versioning comment. The code responsible for checking out and checking in the
test document looks like this (it will be added to the Load event of a web part shortly):

SPSite objSite = SPControl.GetContextSite(Context);
SPWeb objWeb = objSite.AllWebs[“PrivilegesTest”];
objWeb.AllowUnsafeUpdates = true;
SPFile objFile = objWeb.GetFile(“Shared Documents/Test.doc”);
objFile.CheckOut();
SPUser objUser = objFile.CheckedOutBy;
objFile.CheckIn(“check-in version: “ + objFile.UIVersion + å
“ by “ + objUser.Name);

The complete code looks like this...
using System;
using System.Runtime.InteropServices;
using System.Web.UI;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Serialization;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.WebPartPages;
namespace KwikSliver.ImpersonationAndElevationDemo
{
[Guid(“47500629-54d5-4ac4-ac44-097b4ce2e3eb”)]
public class SuperPart : System.Web.UI.WebControls.WebParts.WebPart
{
public SuperPart()
{
this.ExportMode = WebPartExportMode.All;
}
protected override void OnLoad(EventArgs e)
{
SPSite objSite = SPControl.GetContextSite(Context);
SPWeb objWeb = objSite.AllWebs[“PrivilegesTest”];
objWeb.AllowUnsafeUpdates = true;
SPFile objFile = objWeb.GetFile(“Shared Documents/Test.doc”);
objFile.CheckOut();
SPUser objUser = objFile.CheckedOutBy;
objFile.CheckIn(“check-in version: “ + objFile.UIVersion + “ by “ +
objUser.Name);
}
}
}

In this example, I first navigated to a page containing the SuperPart web part while logged in as user SuperB. This caused the SuperPart web part to load and execute, which checked out and then checked in a document in a document library under the SuperB system account. Then, I logged in as user NormalA and went back to the same page, causing the creation of a new version of Test.doc under the identity of NormalA. Figure down below shows the version history of the test document.

The version history can be used to check our results. As you can see, the document was first updated by a system account, followed by an update by the NormalA user.




Now we are ready to show how to impersonate a user account using the SPUserToken object. We will access the default page of the PrivilegesTest site while logged in as SuperB, but we will check out and check in the file using the NormalB account. To make it easier to concentrate on the impersonation part of the code, copy the code concerning document modification to a new private  method called CheckInAndOut() in the web part.

First, the web part needs to retrieve a valid SPUser object from the current SharePoint site representing the NormalB user account. We will use the AllUsers collection of the current SharePoint site to retrieve the NormalB user account. Then, we will need to create an instance of an SPSite object in the context of the NormalB user account. This is done by passing a valid user token representing
the NormalB user account. This token is retrieved from a property called UserToken that is a member of an SPUser object. The UserToken object needs to be passed to an SPSite object’s constructor in order to impersonate a given user. This is shown in the following code fragment:

SPUser user = web.AllUsers[@”web1\NormalB”];
SPSite objSite = new SPSite(“http://web1”, user.UserToken);
The complete code for the web  part that uses the NormalB account to check out and then check in a document is listed here..

using System;
using System.Runtime.InteropServices;
using System.Web.UI;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Serialization;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.WebPartPages;
namespace KwikSilver.ImpersonationAndElevationDemo
{
[Guid(“47500629-54d5-4ac4-ac44-097b4ce2e3eb”)]
public class SuperPart : System.Web.UI.WebControls.WebParts.WebPart
{
public SuperPart()
{
this.ExportMode = WebPartExportMode.All;
}
protected override void CreateChildControls()
{
try
{
string strValue = String.Empty;
SPSite site = SPControl.GetContextSite(Context);
SPWeb web = site.AllWebs[“PrivilegesTest”];
SPUser user = web.AllUsers[@”web1\NormalB”];
CheckInAndOut(user);
}
catch (Exception err)
{
Controls.Add(new LiteralControl(err.Message));
}
}

private void CheckInAndOut(SPUser user)
{
SPSite objSite = new SPSite(“http://web1”, å
user.UserToken);
SPWeb objWeb = objSite.AllWebs[“PrivilegesTest”];
objWeb.AllowUnsafeUpdates = true;
SPFile objFile = objWeb.GetFile(“Shared Documents/Test.doc”);
objFile.CheckOut();
SPUser objUser = objFile.CheckedOutBy;
objFile.CheckIn(“check-in version: “ + objFile.UIVersion + “ by “ +
objUser.Name);
Controls.Add(new LiteralControl(objFile.Name +
“ checked out by: “ + objUser.Name));
}
}
}

The result of executing this web part is shown in Figure below: