WF MOSS Human Workflow Part 2 - Project

• Part 1 - State Workflow Introduction
• Part 2 - Solution Set Up
• Part 3 - InfoPath Form Set Up
• Part 4 - Creating State Workflow (coming soon)

Introduction

This is the second part in a series discussing how to build human workflow with Visual Studio in MOSS. In the first article, I gave some background into considerations and assumptions that for creating a workflow in Visual Studio versus SharePoint Designer. As well, I took a deeper look into how forms work with MOSS workflows and I presented a simple approval process that will be created. This workflow will incorporate all of the basic necessities required for implementing a business workflow with WF and MOSS. One of the goals of this implementation is to make sure the implementation is easy for the business users to use, without requiring them to knowing they are using "SharePoint workflow".

In this posting I will take a deeper dive into how to prepare for the construction of a human workflow process using WF and MOSS. Specifically we will focus on the steps of how to build a project in Visual Studio..

Creating the WF Projects

In this example, I will be using Visual Studio 2008 however all of this can be done using Visual Studio 2005. Some of the steps for 2005 are different when creating the WF project and will need to install the SharePoint Extension for Visual Studio 2005.

Before opening up Visual Studio and starting adding projects, a plan of attack should be made. Nothing is more frustrating than inheriting a project from someone who did not think anything through. We want to ensure that the projects are layered, decoupled, maintainable, and scalable. There is no reason why we should create a solution just like we would anywhere. Remember all WF is a way to create even handlers that will raised in a specified order based on business rules. It is just a schedule of events. These events may call out to SharePoint, enterprise databases or access other resources across platforms.

Knowing the following will be my initiation project:

• WFDistillery.MyProcess: Solution file that contains code artifacts for the business process.
• WFDistillery.MyProcess.Business: Class Library project which will contain all business and domain classes used by the workflow. It is planned that Entity, part of the .NET 3.5 Framework, will be utilized.
• WFDistillery.MyProcess.Data: Class Library project which will do any data persistence for the workflow. There may be places where LINQ is possibly used within this layer. Note at that if Entity is used in the Business library there may not be need for this library. However, it should be part of the solution because there will be other enterprise data sources that you will have to interact with down the road which Entity may not be able to work with. WFDistillery.MyProcess.Form.Request: An InfoPath Form Template project which will contain the InfoPath request form that the user will fill out. Find this under Visual C# >> Office >> 2007 >> InfoPath 2007 Form Template.
• WFDistillery.MyProcess.Utility: Class Library project with any sort of utilities that are needed for this project.
• WFDistillery.MyProcess.WebService: Web Service project that will be used by InfoPath forms.
• WFDistillery.MyProcess.WF: SharePoint 2007 State Machine Workflow project. Find this under Visual C# >> Office >> 2007 >> SharePoint2007 State Machine Workflow.
• WFDistillery.MyProcess.WF.Form.Association: An InfoPath Form Template project for the workflow association form.
• WFDistillery.MyProcess.WF.Form.Initiation: An InfoPath Form Template project for the workflow initiation form.
• WFDistillery.MyProcess.WF.Form.Task0: An InfoPath Form Template project for the workflow task form.

Here are some assumptions and considerations made when creating this project:

• You will also probably want to change WFDistillery to something like Company.Department.ProcessName. MyProcess is the name of the process. You will probably want to rename this to TravelRequest, PurchaseRequest, SoftwareRequest, etc.
• WFDistillery.MyProcess.Form.Request project was done this way so if more forms are ever added to the process, you would do something like WFDistillery.MyProcess.Form.Receiving. These forms are not the workflow forms and should thought of as simply as a piece of content. Knowing that, you can use this solution pattern for other things in SharePoint like a list item, calendar item, etc.
• The InfoPath forms will be using web services to do all of their transactions. I really believe in trying to minimize putting any managed code into InfoPath (even if it requires more clicking). I try to treat them as simple, thin, XML based user interfaces. I have said in my blogs, if you are putting lots of .Net managed code in there; consider using ASP.net and not InfoPath. All the web service will be doing is exposing methods within WFDistillery.MyProcess.Business and WFDistillery.MyProcess.Data.
• WFDistillery.MyProcess.WF.Form.* projects are InfoPath forms that are used by the workflow. Both the Association and Initiation forms are self-explanatory. The Task0 is the first task form for the workflow. The naming convention corresponds to the <Task0> tag in the Workflow feature files. If you project has more than one task form, you would simply add another project called Task1, Task2, etc. I will go into this deeper in a future however I have found that a best practice is to create on Task form and simply switch the views.
• Side note, I was pretty excited to be have InfoPath Form Template project templates in Visual Studio 2008. In the past, I have put InfoPath .xsn files in VSS or had to crack them open and get all of the internal files in VSS. Now, I can do all my designing of InfoPath in Visual Studio and get all of the files in VSS for free. The only downside is I can really only do one form per project.
• Because WFDistillery.MyProcess.Form.Request project is part of this solution, there is an assumption that request form is coupled to this solution. It would be possible to try to write something really generic where we would move all of the projects prefixed with WFDistillery.MyProcess.WF.* into a separate solution; but time is limited J.
• It is possible to have more than one workflow defined in a WF library. The solution I am building makes the assumption that there will only be one workflow defined in this solution. If I wanted to create multiple business processes in this same solution, I would have done something like the following.
• WFDistillery.MyProcesses
• WFDistillery.MyProcesses.Data
• WFDistillery.MyProcesses.Utility
• WFDistillery.MyProcesses.Process1.Business
• WFDistillery.MyProcesses.Process1.Form.Request
• WFDistillery.MyProcesses.Process1.WebService
• WFDistillery.MyProcesses.Process1.WF
• WFDistillery.MyProcesses.Process1.WF.Form.Association
• WFDistillery.MyProcesses.Process1.WF.Form.Initiation
• WFDistillery.MyProcesses.Process1.WF.Form.Task0

The resulting Solution Explorer in Visual Studio will look like the following.

Creating the SharePoint 2007 State Machine Workflow Project
When creating a new workflow with Visual Studio 2008, there is a great new feature that allows you to configure your project so that you can debug your workflow from Visual Studio. In Visual Studio 2005 this was not an option. To change the debug configurations, right click the project in the Solution Explorer and select the SharePoint Debug Settings option. What this will effectively do is deploy the workflow as a feature and associate it to a list. Do not use this as a way to deploy your solution into a production environment.

When the project is created you will several files added to the project immediately. A feature.xml, workflow.xml and workflow class Workflow1.cs should be there. We will re-organize these files later on.

Coming Up
I will be taking a deep dive into how to create all of the forms that will be used for this workflow. I will be off for two weeks (11/4/08) here and will come back to this when I return.