SharePoint 2007 provides a basic set of business process management (BPM) functionality. Many IT shops and business users who have SharePoint 2007 running in their environment may be wondering what BPM capabilities SharePoint 2007 does have, and how it stacks up to traditional packages that promote themselves as complete BPM solutions.
Most Enterprise BPM solutions are comprised of the following high level components:
- Business Process Modeling User Interface
- Backend Workflow Engine
- Business Rules Engine
- Business Activity Monitoring (BAM) Reporting
- Web Service Integration Capabilities – calls to web services that can be integrated and modeled into workflows through the modeling user interface
- Forms designer for basic data capture
This article will focus primarily on how SharePoint can be leveraged to provide robust workflow and integration capabilities and where minor customizations can be done to enhance those out of the box (OOTB) capabilities.
SharePoint Workflow
SharePoint workflow is built on a very robust workflow API from Microsoft called Workflow Foundation (WF). SharePoint exposes the ability to utilize this workflow in three ways – each having its own benefits and drawbacks.
-
- Out of the Box Preconfigured Workflows: SharePoint has a handful of very basic preconfigured workflows that come out of the box. An owner of a list or document library can assign these workflows to the items in their list or library and enable some basic workflow and lifecycle to the items contained within it. These workflows are extremely basic, however, and not customizable.
- SharePoint Designer (SPD) Configured Workflows: SharePoint has exposed the ability to assemble workflow steps consisting of conditions and activities that can be connected through “if/else” branches. When using SPD, SharePoint allows the workflow designer to choose from a much wider array of workflow activities. An example of a workflow step is shown in Figure 1. There is also the ability to add your own custom activities. We will cover this later when integration capabilities are discussed. Workflows created with SPD, however, are not reusable and must be created for each list to which they are associated.
Figure 1
 |
- Visual Studio Custom Workflows: Visual Studio 2005 and 2008 have a Graphical User Interface (GUI) driven approach to workflow development built into them which allows the developer to create a workflow visually and have the workflow shell developed in the background. These workflows require .NET and WF knowledge, but are highly customizable and reusable once deployed.
When using typical BPM solutions, one major benefit is the ability to quickly be able to implement a simple data capture form, model a workflow and begin using the automated process. The closest representation to this is the second type of workflow implementation method using SPD as it allows a non-technical user the ability to create a custom workflow to mimic their business process.
Integrating SPD workflows with Web Services
Now that we have established a workflow created with SPD can give a non-technical user the ability to model their business process, we should talk about how SPD can be used to truly model an enterprise process that may span activities requiring human interaction as well as input from one or more enterprise systems. To really be considered able to automate an enterprise scale process, we must be able to implement processes where both human and system interactions are required within SPD.
To do this, we must create a custom workflow activity encapsulating a set of web service methods we may want to invoke. We will also have to make a small customization to SharePoint for each custom activity, so SPD will discover and use these activities. In a Visual Studio created workflow, activities are assembled to model the process in question. In an SPD developed workflow, activities and conditions are used to create workflow steps. Our custom workflow activity will allow us to invoke a web service call on a target system. This article will not go into task-level detail on how to create the custom workflow activity. However, you can find detailed information here.
At a high level, we want to create a flexible set of activities giving us the most availability to our target systems’ service layer. The recommendation would be to create an assembly for a set of service operations based on some natural grouping (i.e. all the operations on a single WSDL definition, services requiring similar security credentials, services for a certain target system, etc.). Getting this set up in your SharePoint 2007 environment is actually pretty easy. The steps to do so are listed below:
- In Visual Studio create a Web Reference (stub) for the web services you would like to invoke from your workflow
- Create a custom Activity class (sub class of System.Workflow.Activities.SequenceActivity)
- Create an xml file (the default file for the OOTB SPD activities is called WSS.ACTIONS) for your activity that defines all the inputs and outputs. This is the file SPD will use to drive the user during workflow creation. In this file we will create a field that allows the workflow creator to select the inputs and outputs as well as the web service to be called.
Once the above steps are complete, workflows can be assembled to integrate SharePoint 2007 lists and libraries with other systems in a controlled and configurable manner. In Figure 2, you can see the interface a workflow designer will use to create a step in a workflow invoking data in another system and potentially alter the course of the rest of the process based on data coming from the other system.
Figure 2 – Example of some service calls in a Pharmaceutical Clinical Environment Conclusion
 |
While this article doesn’t make a case to replace your Enterprise BPM solution or plans for a solution with SharePoint, it does show how some simple customizations can help bridge the gap between what the out of the box solution provides and what some would consider typical BPM solution features. Another item of note is that there are some solution providers such as K2 and Nintex, which provide much more robust workflow capability with SharePoint.
About HighPoint Solutions
HighPoint Solutions is a premier provider of specialized IT services dedicated to the Life Sciences and Healthcare industries. Since 2000, our business consulting and technology solutions have delivered, and continue to deliver, business value and competitive advantage to our clients.
With offices in Philadelphia, New Jersey, Chicago, and Los Angeles, our team of 400 consultants is strategically located to meet your needs through our laser focus on key industries, partners, and technologies.
