Introduction
SharePoint 2010 introduces many new capabilities that are categorized into six different workloads, one of which is the composites workload. A key component of creating composite applications is SharePoint 2010’s ability to create custom workflows, allowing end users to attach behaviour to data.
Workflows in SharePoint Server 2010 enable enterprises to reduce the amount of unnecessary interactions between people as they perform business processes. For example, to reach a decision, groups typically follow a series of steps. The steps can be a formal, standard operating procedure, or an informal implicitly understood way to operate. Collectively, the steps represent a business process. The number of human interactions that occur in business processes can inhibit speed and the quality of decisions.
Workflow in SharePoint 2010
SharePoint Foundation 2010 workflows are made available to end-users at the list or document-library level. Workflows can be added to documents or list items. Workflow can also be added to content types. Multiple workflows may be available for a given item. Multiple workflows can run simultaneously on the same item, but only one instance of a specific workflow can run on a specific item at any given time. For example, you might have two workflows, called SpecReview and LegalReview, available for a specific content type, Specification. Although both workflows can run simultaneously on a specific item of the Specification content type, you cannot have two instances of the LegalReview workflow running on the same item at the same time.
The figure below illustrates the conceptual workflow architecture in SharePoint Foundation. Each content type, list, and document library in the farm is linked to the workflows added to it through the workflow association table. Each workflow has a workflow definition. This XML definition specifies the identity of the actual workflow assembly, and class within that assembly, as well as the location of any workflow forms the workflow needs to run.
Share point workflow Life Cycle
Fig. below illustrates the four stages of the SharePoint workflow life cycle. These stages allow for the assignment of workflows to content type, handle the different ways for starting workflows, and keep the workflow infrastructure flexible during execution. This custom life cycle is provided by the SharePoint-specific workflow hosting environment. During some of the following stages, forms can be used to gather additional user input as parameters, which are required for this stage to execute.
Workflow Solution Spectrum
‘Out of the box’ Workflows
SharePoint 2010 Standard and Enterprise include a selection of ‘out of the box’ workflows. These tools help you automate the most common business tasks – sharing and collecting feedback on documents.
Workflow Types
Windows Workflow Foundation supports two fundamental workflow styles. You can create workflows of either type for Microsoft SharePoint Foundation 2010.
Sequential Workflows
A sequential workflow represents a workflow as a procession of steps that execute in order until the last activity completes. However, sequential workflows are not purely sequential in their execution. Because they can receive external events, and include parallel logic flows, the exact order of activity execution can vary somewhat.
State machine workflow
A state machine workflow represents a set of states, transitions, and actions. One state is denoted as the start state, and then, based on an event, a transition can be made to another state. The state machine can have a final state that determines the end of the workflow.
In the state machine style of workflow authoring, the author models the workflow as a state machine. The workflow itself consists of a set of states. One state is denoted as a start state. Each state can receive a certain set of events. Based on an event, a transition can be made to another state. The state machine workflow can have a final state. When a transition is made to the final state, the workflow is completed.
The following flowchart is an example of a state machine workflow.
Reference: http://msdn.microsoft.com/en-us/library/ms735945.aspx
Workflows Development Tools
Workflows for SharePoint can be designed in Visio and/or developed using Share point designer or visual studio.
Schematic diagram of the tools available for developing SharePoint workflows is as follows:
Designing workflows
It is also possible to design the share point workflows using Microsoft Visio and export it to share point designer for further development.
Points to consider:
- Only design of the workflow is possible (the business logic conditions need to be filled in later after importing to share point designer)
- Microsoft Visio Premium or higher is required to design the share point workflows
Developing SharePoint workflows
Share point workflows can be developed in SharePoint designer or visual studio.
Points to consider:
- Workflows created in Share point Designer can be exported and imported to visual studio but the other way around is not possible
- If input is needed for workflows, the forms for input can be done either using InfoPath or custom asp.net page.
- Custom workflow activities can be developed in visual studio and can be used in share point designer along with the other built-in activities to create workflows.
References:
Share point designer activities reference:
Custom activities:
http://www.stuartroberts.net/index.php/2011/09/13/workflow-activity-part-1/
Sandbox
Workflows authored with SharePoint Designer 2010 can run in a protected environment called the sandbox where they cannot put the farm in danger; workflows generated with Visual Studio must run in the farm mode, but not in a sandbox environment.
Versioning
Workflow versioning is a very important technique. When a workflow goes idle, the state of the workflow is and saved (hydrated) into the database. This saving of a workflow’s state is called hydration. When the workflow resumes, the state is dehydrated out of the database and the workflow starts processing again. Versioning is important because if you change the assembly while the workflow is hydrated (saved in the database), there’s no guarantee that when the workflow dehydrated it will match the construct of the new assembly. If it doesn’t match the construct upon de-serialization, the workflow will break. Changes like adding or removing activities and changing property values may necessitate a new workflow version. The best practice is to create a new version every time rather than just push the assembly and cross your fingers.
Reference:
http://philwicklund.com/Lists/Posts/Post.aspx?ID=145
https://blogs.pointbridge.com/Blogs/herzog_daniel/Pages/Post.aspx?_ID=4
Be First to Comment