Before delving into how workflows can be used in SharePoint, you should get familiar with WF and the key concepts and structures involved. Workflow, to illustrate how a workflow differs from the traditional applications on which we developers spend most of our time.
Workflows are declarative—that is, they focus on what should be done rather than how to do it. This has a significant implication: Determining what should be done within an organization is a role performed by business users as opposed to developers, and exactly what should be done often changes as business priorities change. As developers, we’re very aware of this problem since it ften leads to a constant shifting of deliverables when it comes to developing line-of-business applications. By adopting a workflow-based approach, organizations can change business processes simply by amending the workflows that define them.
Secondly, workflows are long running and stateful. You may be thinking that most business applications are long running and stateful, but there is an important difference with workflows: The management of state and the processing of interactions with running workflows is handled automatically by the runtime engine. Although building business applications that maintain state is common practice, such an implementation will usually involve a lot of custom code. The same is also true for managing interactions with long running processes. There is a fundamental difference between using workflows and traditional application development, and it all comes down to perspective. When building traditional applications, we focus on handling events and managing data; with workflows, the focus is on the actual process logic with event handling and data management handled automatically.
Types of Workflow
You can host two types of workflow using SharePoint: sequential workflows and state machine workflows. A sequential workflow is probably the most common type of workflow. State machine workflows are not widely used within organizations.
This type of workflow commonly manifests itself as a business process and is the muse of many a Visio artist the world over. Sequential workflows generally have a single starting point and follow a series of sequential steps before reaching a discrete stopping point. Consider the expenses approval workflow, for example. An employee completes an expenses claim document. Completing the document starts an approvals workflow that sees the document being sent to a manager for approval. Once the manager has approved the document, it is automatically passed to the accounts department for payment. When the claim has finally been paid, the workflow is concluded. This business process follows a series of steps toward a final conclusion and is therefore typical of a sequential workflow.
State Machine Workflow
A common perception, possibly arising from the assumptions of the various process improvement methodologies, assumes that everything can be reduced to a series of welldefined sequential processes. However, the core assumption of the sequential workflow is that a process will progress in a predictable manner toward a well-defined conclusion. In reality, however, this is not always the case.
Consider, for example, the processing of a customer order. A customer places an order for a particular item. The item is not currently in stock and is ordered from a supplier. At the time of ordering, the supplier provides an estimated delivery date, and from this date an expected delivery date for the customer is provided. The supplier ships the goods as expected, which are ultimately forwarded to the final customer. On the surface, this may seem like a perfect candidate for a sequential workflow, but what happens if the customer decides to cancel the order? Or if the supplier can’t deliver the goods? Or if the price of the goods changes between the time the customer places the order and the order being fulfilled? Of course, we could create complex sequential workflows to handle these exceptions, but the point is this: Many exceptions can occur; trying to capture all of them and define processes for handling all of them in a model intended to represent a core business process can result in a process that is fraught with minute detail. We’ve moved from defining what should be done to defining how it should be done. The state machine workflow is a far more powerful tool when it comes to mapping business processes within a software application. It allows us to focus on the key steps while still allowing flexibility in handling unexpected events. In the processing of a customer order example, using a state machine approach, we could use four states:
Of course, several other business processes are involved in the transitions between these four states, but the important difference is that the actual logic of those business processes does not necessarily need to be well defined. For example, when the customer places an order, if the ordered item is out of stock, most likely a business process would be in place to order it from a supplier. However, the details of that process don’t matter to our workflow, because we’re simply waiting for the state of the order to be updated to Order Fulfilled after the ordered item becomes available.
As you can see, not all processes are predictable, and sometimes modeling every eventuality simply muddies the waters and creates a rigidity that defeats the objective of workflow. State machine workflows allow you to focus on the goal of declaratively defining business processes while still maintaining operational fidelity.
Making Workflows Work
Let’s move on to consider how workflows are defined and the nuts and bolts of performing useful functions. As you’ll see in our demonstration scenario, SharePoint allows you to create workflows in a number of ways. The end result is the same: an eXtensible Application Markup Language (XAML) file containing an XML representation of the steps to be performed and the rules governing their execution. Although the file format used by WF is XAML, workflow files use the extension .xoml, allowing design time tools to differentiate between other uses of XAML syntax such as Windows Presentation Framework artifacts. Workflow XAML defines two key elements: workflow rules and workflow activities.
Let’s consider an example of a simple workflow that might make use of workflow rules: An employee completes a purchase requisition form, starting a sequential workflow. The workflow rules determine that if the amount specified is less than $5000, the requisition can be approved by any manager within the organization. However, if the amount is greater than $5000, the requisition must be approved by the purchasing manager.
Since the amount is a significant factor in determining what should be done, it’s important that it can be changed as part of the workflow definition. To make this possible, workflows can contain rules and define variables for use by these rules.
When it comes down to performing actual work, workflows use a series of activities. Each activity effectively defines a method call, and within the method is code that performs a particular function. So, for example, if a requisition is sent to the purchasing manager for approval, a workflow activity creates an e-mail message containing the details of the requisition and then sends it to the manager for approval. When the manager clicks the approval button in the e-mail, the workflow activity completes processing and returns the results to the workflow runtime. The results of workflow activities can be assigned to variables and can therefore be used by workflow rules. Out of the box, SharePoint 2010 includes many workflow activities. Confusingly, within SharePoint, workflow activities are sometimes known as actions, which include the following:
Custom Workflow Activities
Although more than 80 workflow activities are available in SharePoint 2010, when it comes to building custom applications, you will invariably have to create new activities that are specific to your problem domain. Custom workflow activities can be used in exactly the same way built-in workflow activities are used; although it’s fair to say that a bit more effort is involved in creating a custom workflow activity than in writing a standard function. Workflow activities have to satisfy the needs of two distinct audiences. First, workflow activities need to do something useful at runtime. As developers, we’re completely comfortable with writing the code to make our custom activity do something useful. In addition to performing some function, a workflow activity must also provide a useful design-time interface. Business users must be able to configure our custom activity easily within a workflow design tool if its runtime functionality is to be used.
From a runtime perspective, creating a custom activity is simply a case of creating a new class that is derived from System. Workflow. ComponentModel. Activity. Custom code can then be executed simply by overriding the virtual Execute method from the Activity base class.
As well as the runtime behavior, you need to consider the design-time experience. The WF framework allows you to define the design time experience in three distinct areas, which are discussed in the sections that follow.
By adding validation to an activity, you can catch configuration errors at design time. To implement this functionality, you create a new class that derives from System. Workflow. ComponentModel. Compiler. Validator. As before, by overriding the virtual Validate method from the Validator base class, you can add your custom validation code. Customizing Toolbox Behavior When you create workflows using Visual Studio, you can add activities to the design surface by dragging them from the toolbox, as you’re accustomed to doing with other design-time elements. WF lets you customize the behavior of your activity when it’s dragged onto the design surface by implementing a custom Activity Tool boxItem class and attaching it to your activity. Creating a Custom Designer As well as validating the configuration of our activity using a validator and automatically setting up default values using a custom toolbox item class, you can also extend the visual representation of your activity by implementing a custom designer. In much the same way as other WF objects, a custom designer can be implemented by deriving a new class from System. Workflow. Componen tModel. Design. Activity Designer.
By implementing a custom designer, you can not only alter the visual appearance of an activity at design time, but you can also implement logic that determines how your activity behaves on the design surface. For example, you can determine whether child activities can be added to your activity or how many connection points your activity exposes.
External Activities via Pluggable Workflow Services
A new addition to SharePoint 2010 is the ability to use external activities. Connecting to external systems has always been available as part of the WF framework. However, creating a practical implementation required a few additions to the workflow runtime. In MOSS 2007, extending the workflow runtime was not possible, and therefore implementing the extensions required to support external activities was not possible. Now with SharePoint 2010, communicating with external systems is simply a matter of creating a new class that inherits from the SPWorkflow External DataExchange Service base class. The addition of external activities to the SharePoint workflow runtime greatly expands the scope of SharePoint as a workflow host. To pick up on the order fulfillment example used earlier, if a product is out of stock and requires an order to be placed with a supplier, it’s now possible for the order to be placed directly from the workflow. Furthermore, any response from the supplier can also be picked up within the workflow and acted upon automatically. Bearing in mind the declarative nature of workflow and the aim of easily allowing business users to model business requirements, this is a very powerful enhancement to the platform.
When it comes to creating workflows for use with SharePoint, you have a choice of a few methods, each targeted to a particular audience and set of requirements.
Using SharePoint Designer
Creating workflows using SharePoint Designer provides a complete no-code design experience. As you’ll see in the upcoming demonstration scenario, workflows can be created by using a series of simple wizard-based steps. In previous versions of SharePoint, workflows created using SharePoint Designer were not portable—that is, if you wanted to use the same workflow on more than one list, you had to re-create it again for each list. With SharePoint 2010, that’s no longer the case; workflows can be easily used across multiple lists and can also be exported for further enhancement using Visual Studio 2010.
Using Vision 2010
The ability to use Vision 2010 to create workflows is a new feature in SharePoint 2010. Visio is undoubtedly the tool of choice when it comes to documenting business processes, and now, by adopting the Microsoft SharePoint Workflow template, workflows created in Visio can be imported into SharePoint Designer for implementation. Furthermore, by using Visio Services, imported workflows can make use of the Visio model to provide a runtime status indicator. As well as importing workflows from Visio, you can also export workflows from SharePoint Designer in a format that can be modified in Visio and then re-imported.
Using Visual Studio 2010
Using SharePoint Designer and Visio 2010 to create workflows is undoubtedly the easiest way to go for the majority of cases. But what happens when you need a bit more flexibility? You can use Visual Studio 2010 to take advantage of the entire range of functionality exposed by the WF framework. Some features aren’t available outside of Visual Studio, such as the ability to use pluggable workflow services or the ability to use the CodeActivity which allows developers to execute arbitrary code easily without having to create a custom activity. Another important feature that is available only to Visual Studio users is the ability to create state machineworkflows.
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
Share Point 2010 Tutorial
The Microsoft Sharepoint 2010 Platform
Developing With Sharepoint 2010
Presentation Layer Overview
Client Object Model
Infopath Forms Services
Enterprise Content Management
User Interface Customization
Application Services Overview
Service Application Framework
Word Automation Services
Data Access Overview
Linq To Sharepoint And Spmetal
Business Connectivity Services
User Profiles And Social Data
Packaging And Deployment Model
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.