Building a Practical Application with Windows WorkFlow Foundation, Page 3
Beyond the WorkFlow: Integrating WorkFlows into Other Applications (SharePoint, Office)
With the WorkFlow Foundation, Microsoft is creating a unified workflow framework for all its products. Until now, each Microsoft server has had its own WorkFlow engine. For example, the Human WorkFlow of BizTalk is well known, but CRM also boasts its own WorkFlow engine; and finally, SharePoint 2003's engine, though very flexible, lacks ample power.
The Office 2007 family of products, and specifically Windows SharePoint Server 2007, will be the first Windows software that integrates the WorkFlow Foundation into the core of the system. For the first time, a Microsoft server (SharePoint 2007) will be able to use the engine of the Foundation as an external paradigm, enabling not only SharePoint Lists and Libraries, but also individual documents inside a Library, to work as a host for a WorkFlow instance.
Because SharePoint is well integrated with all the products of the Office family, individual Office components such as Word and InfoPath are capable of initializing and using WorkFlows utilizing the WorkFlow implementation within SharePoint. Specially created to customize SharePoint, the SharePoint Designer (formally known as FrontPage) is a new Office product and can be used to ensemble WorkFlows for implementation by SharePoint.
There are two ways to initialize a WorkFlow from SharePoint: launched manually by a user or configured to run automatically when a document or item is changed or created. It is also possible to define a WorkFlow for a complete Library or arrange it in such a way that each item has its own WorkFlow. In any case, it is necessary to choose the WorkFlow from the repository of available templates.
Figure 5: Initialization of a WorkFlow from a document in SharePoint 2007
After configuration and initialization, the status of the WorkFlow instance is visible on the List and Item windows and a complete reporting system reveals the statistics of the WorkFlows in use in Excel.
Figure 6: WorkFlow report of activity from SharePoint 2007
The SharePoint Designer sanctions users to create, configure, and install WorkFlows for SharePoint 2007. The WorkFlows can be assembled using the Lists and Fields of the present site as input conditions and can manage different tasks as output actions.
Figure 7: SharePoint Designer creating a new WorkFlow for SharePoint 2007
The SharePoint Designer interface is markedly different from the Visual Studio Designer and the possibilities are less extensive. For example, it is not possible to design and program Activities and State Machine Workflows. However, SharePoint generates a fully functional Sequential WorkFlow where the conditions are defined using the WorkFlow Foundation rules engine. Another limitation of the SharePoint Designer is that it restricts using the created workflow with Libraries or Lists other then for its original instance. A further disadvantage is that the user cannot modify WorkFlows while the program is in use.
That said, it makes the learning curve for non-technical users less pronounced because of the ease of using the Wizard and the fact that the deployment is realized automatically by the tool.
If Word 2007 is installed in a computer with a connection to SharePoint 2007, it is possible to associate a Word document directly with a WorkFlow.
Figure 8: WorkFlow started from Word 2007
The Wizard will configure the Workflow for selected actors (other SharePoint users), and allows the user to determine the time to complete the process and set the values of the variables to be initialized. The chosen actors will receive an e-mail that announces their participation in the WorkFlow.
Because WorkFlows can be initiated and finalized with WebServices, each program or automated software process that can interact with SOAP WebServices can be used as a host for a WorkFlow. This opens up the potential for integration with any kind of software and back-end process. Visual Studio 2005 contains the infrastructure to publish the WorkFlow directly to a Web Server, if necessary.
The sample source code used in this article is available for downloading. To install and use the code, Visual Studio 2005 must be installed together with the Windows WorkFlow Foundation runtime components and the Visual Studio 2005 Extensions for Windows WorkFlow Foundation. The code was created using the Beta 2.2 version of the Foundation; this can be accessed from the Microsoft site (http://www.microsoft.com/downloads/details.aspx?familyid=5C080096-F3A0-4CE4-8830-1489D0215877&displaylang=en).
The sample solution consists of the WorkFlow project "Jupiter_WorkflowConsoleApp" with its test program "TestWorkFlow" and the Web Service "SendEmailWebService" projects. Each project contains the source code and the generated assemblies.
Our daily lives revolve around a series of activities, decisions, and rules that can be grouped in an organized way within a WorkFlow. WorkFlows exist everywhere; the programming world is no exception. In a traditional programming pattern, the instructions that describe and execute a WorkFlow are integrated into the logic of the program itself, thus making it cumbersome to maintain and re-use. The Windows WorkFlow Foundation provides the framework to build workflow-enabled applications that can be hosted in almost any software environment.
With these two articles, the theoretical and practical basics of the Windows WorkFlow Foundation have been introduced. Hopefully, the example displayed will prick the imagination and stimulate readers to take the plunge to program and employ of a WorkFlow of their own.
About The Author
Gustavo Velez, MCSD, is a Senior Application Developer for Winvision (http://www.winvision.nl), a Microsoft Gold Partner in the Netherlands, with many years experience in developing Windows and Office applications, and more than three years of daily programming experience with SharePoint. He also is Webmaster of http://www.gavd.net/servers, the only Spanish-language dedicated SharePoint site.