Saturday, November 1, 2008

WF MOSS Human Workflow Part 1 - Introduction


There are many situations where you may need to build complex human workflows within MOSS and you do not have an enterprise workflow server like to do it with. This is the first in a series of articles that will show you how to build complete human workflow solutions using Visual Studio WF and InfoPath. This series will not just focus on the nuts and bolts on how to do something; it will also give you insight to design decisions and how workflows function within MOSS.

The following topics will be discussed in this series:

  • What functionality is necessary for human workflow?
  • Introduction into MOSS Workflow.
  • Construction of a request form in InfoPath.
  • How to create a state workflow process.
  • Working with business data.
  • Archiving the request.
  • Task management, task security, delegation, and creating a task queue.
  • Reminders and escalations.
  • Automated deployment across environments.
  • How to create business process performance reporting.
  • How to create a dashboard.

Just note that products like K2 blackpearl and blackpoint make doing much of what I am about to describe as trivial. I have literally seen that this took a few weeks to pull together, get the design pattern hardened and ready for production. The same workflow when using K2 would literally take me a day. After for the first two workflows, the cost justification for K2 will be made.

Getting Started with Requirements

When getting started to build a business process there are several things you need to ask so that you have all the right information when building your human workflow. I think many of us know how to gather requirements these days, but it is worth discussing it. I had written an article on how to gather K2 requirements and after reviewing it, all of the information really holds true. Here are the questions again that I would always try to ask when going into a meeting with business users:

  • Can a business flow diagram be constructed?
    • What are the steps in the business process?
    • What are the decisions a user can make for each step of the process?
    • What role must the user have to make that decision?
    • What stakeholders are there for each decision?
    • What must occur when a decision is made?
    • What should occur when a step is not completed?
    • What are the success criteria for a process to complete? How should a process complete if success criteria cannot be met?
    • What data must be available for a user to make a decision?
    • Are there rules that affect the routing of the business process?
  • What views/dashboards are required to assess that status of the business process?
  • What reporting is required for business processes (in flight, completed, user performance, etc.)?
  • What is the user experience desired? Where do users go to complete tasks? How should users be notified when a task has been assigned?

What I will show throughout this series is how these questions will drive the actual implementation.

Workflow Design

After going through a requirements gathering process, you should be able to draw a diagram such as the following. Although this process may seem pretty simple, there is some work that needs to be done. As well, this diagram does not capture all of the usability requirements that are needed to support such a process. What this diagram does show us is the human/system steps of the workflow, the actors both system and human, actions/decisions that can be made and success criteria.

This workflow is a basic approval process where a requestor makes request, a manager must approve, then the request is sent to a queue where it is opened and finished. Along the way, the request may be sent back to the requestor for revisions. That is pretty simple.

Now the next question is how should I do this? There will be lots of things that will be done but the first step will be to create a workflow. Looking at the requirements, it becomes evident that doing a workflow in SharePoint Designer is not going to work. The problem is that the workflow is sequential and SharePoint Designer does not really work well with calling systems that reside outside of MOSS. It possible to create custom activities in SharePoint Designer to do such things as call out to a database, however this is difficult to accomplish. Plus getting to the data in InfoPath form is not clean either and processes created in SharePoint Designer cannot be deployed across MOSS environments. At this point, that option is out. The only other option would be to create a workflow in Visual Studio. Given the type of workflow this is, making this a state workflow process would be best rather than doing a sequential. The main reason is that the sequential really cannot handle the flow of this process because the process literally goes from one "state" to another "state".

As for the user interface, we are going to go ahead and use InfoPath. Really, InfoPath is not that bad if you are trying to shave some time off the delivery. There are tons of reasons why you may not want to use InfoPath and you can review those considerations by reading this. In this case, the data is really flat and I really do not have any "special" user interface rules. All we need to do is capture data and use it to make decisions. Data validation rules will be extremely simple. Plus I strive to make sure that I put as little business layer logic into my user interfaces as possible. Knowing that, there is no real good reason why I should not be able to use InfoPath.

Understanding Workflows Form and Workflow Life-Cycle

I have seen several examples out there where people spend the time wiring up a sequential workflow but do not take the time to explain the forms that you have and how you should use them. When building a MOSS workflow there are three basic forms: Association, Initiation and Task forms. There is also a modification form but that is outside the scope of this.

The association form will be displayed when the workflow is first added to a list or library. This form will only ever be displayed once and will not be seen again as workflow instances are later created for content items. The association form will be displayed after you have gone through the "Add a Workflow" page.

The initiation form will be shown when a form is started. However, this form may not be seen by a user depending on how the workflow is configured for the SharePoint list. When adding a process to a SharePoint list you have the ability to say how the workflow will be initiated. Keeping this simple, the workflow can be manually started, started when an item is created or when it is changed. The initiation form will not be displayed when a file is uploaded or submitted to a SharePoint list. It will be shown when a user manually starts a workflow.

The task form, for all intensive purposes, overrides the out of the box view of a task item in a Task List. The underpinning of everything for workflow in MOSS is a task. Whether it is a state or sequential workflow, the workflow is waiting for an event to make the workflow go to the next step in the process and nine times out of ten that is a user completing a task. The need for overriding the task form is required because based on the state of the workflow you will want to display specific information to a user. A task item is not scalable.

Now the association, initiation and task forms are NOT the request form in my opinion. This is a big point which many people do not make when talking about how to make a workflow in MOSS. Many try to embed the request form as part of the association, initiation and task forms where they are constantly trying to get the initial data from the initiation form and then loading it back into the task form. I think that is wrong approach for several reasons:

  • Association, Initiation, and Task InfoPath forms only have a short life-span. They are not a form that resides in a Form Library. Once the form has been displayed and the user submits, the form is basically gone. I like this approach well because it works with content that may not be an InfoPath request form. Calendar items, list items, pdf, etc. can be used with the workflow.
  • Both the Association and Initiation InfoPath forms can be viewed by the user once. If these forms have complex data structures (repeating information) you have the ability to access it. However, that is not the case with an InfoPath Task form. You have the ability to access data in the Task form before and after the user takes action however, you cannot work with repeating data structures. The only way accomplish this is to have the InfoPath form save the data externally to a database and then in the workflow process you will have to add more code to get that data. Just this alone, turned me off completely to trying to use the Task Form as request form as so many try to do.

The following is a diagram that should hopefully clearly explain how the forms are used in a workflow.

As you can see in the diagram, the Association form is shown only once when the form is added to a list. The Initiation Form may be shown when a workflow instance is created and the Task form will be shown for every task that is created for the workflow. The diagram shows that the Request form is not one of the workflow forms and the request form should be treated as a piece of content that is within MOSS.

Coming Up

The next thing I plan to write about is how to create a State Workflow project and start diving into how to create the InfoPath forms that will be used in the workflow.

No comments: