How To: Use default SharePoint approve/reject InfoPath task form in custom Visual Studio workflows

Eugene Rosenfeld — Mon, 15 Mar 2010 02:17:09 +0000

Editor’s Note: In a new series of articles, I will be introducing you to some of the speakers who will be presenting at the SharePoint Evolutions Conference in London next month, pointing you to articles on their sites, offering downloads of white papers, and publishing articles on their subjects of expertise. — Mark Miller

Eugene Rosenfeld
Things that Should be Easy

I needed to write a customized approval workflow. I know I could use InfoPath to create custom approval task forms, and I saw many posts showing how this is done. But if I could use the SharePoint Approval Workflow task forms, I could save a lot of development time and deployment effort.

This post focuses on how I was able to use the out of the box InfoPath approval approve/reject task forms forms in my custom Visual Studio SharePoint workflow.If you’re looking for a general how-to post on creating SharePoint workflows with Visual Studio, this is not the post for you. I would instead point you to Serge Luca’s excellent 20-part series on creating SharePoint workflows with Visual Studio.

Creating the task

Here’s the skinny on what you need to do in order to use the default Microsoft Office SharePoint Server 2007 (MOSS) approve/reject InfoPath form in a custom Visual Studio workflow.

1. Create a SharePoint workflow project

There are many ways to do this, so I won’t go into details here. My personal favorite way is by using the WSP Builder Visual Studio workflow template project. Just make sure that your workflow class inherits from System.Workflow.Activities.SequentialWorkflowActivity or from System.Workflow.Activities.StateMachineWorkflowActivity.

2. Set the TaskListContentTypeId attribute

Edit the elements.xml file in your workflow feature definition. Set the TaskListContentTypeId attribute value to use the MOSS workflow task content type id:

3. Add the Task_FormURN and ExtendedStatusColumnValues elements

Continue to edit the elements.xml file in your workflow feature definition. Add the following MetaData element under the Workflow element:

  
    
        
          urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Review:$Subst:LCID;
          urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Review:$Subst:LCID;
          urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Review:$Subst:LCID; 

          
            $Resources:ReviewFeedback_CanceledStatus
            $Resources:ReviewFeedback_ApprovedStatus
            $Resources:ReviewFeedback_RejectedStatus
          
         

        …
    
    …

4. Add a CreateTask activity to your workflow

Add a CreateTask activity to your workflow. Make sure to set the TaskType property on the TaskProperties of the CreateTask activity to 1. This will tell the workflow runtime to create the task using the Form Urn corresponding to the inner text in the Task1_FormURN element. The CreateTask activity’s MethodInvoking event is a good place to set the property.

private void createTask1_MethodInvoking(object sender, EventArgs e)
{
    //initialize task infrastructure data
    this.createTask1_TaskId1 = Guid.NewGuid();
    this.createTask1_TaskProperties1 = new Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties();
    this.createTask1_TaskProperties1.TaskType = 1;

    //set task remaining properties
    //...
}

Processing a workflow task

Now that you’ve created a workflow task that uses the default approval form, you will want to your workflow to do something useful when a user approves or rejects the task. Here is how to detect when a user approves or rejects the workflow task.

5. Detect task change with OnTaskChanged

This is fairly straight forward: add an OnTaskChanged activity to your workflow. Set the task ID and correlation token to correspond to the ones used when creating the task in the previous section. See Serge Luca’s SharePoint workflow series for details.

6. Task approved or rejected

Here’s the interesting part. Whether a user approves, rejects, reassigns, or requests a change in the task form, the task is always marked as Complete. The actual value that corresponds to what the user selected is stored in the TaskStatus in the ExtendedProperties collection of the SPWorkflowTaskProperties class. The following is a table that correlates the user’s approval action to the value of the TaskStatus extended property:

User Action	TaskStatus Value
Approve	“#”
Reject	“@”
Cancel	[no change]

Here’s a sample helper method that checks whether a particular workflow task was approved:

public static bool IsTaskApproved(SPWorkflowTaskProperties TaskProperties)
{
    return TaskProperties.ExtendedProperties["TaskStatus"] != null
        && TaskProperties.ExtendedProperties["TaskStatus"] as string == "#";
}

Anything else?

That’s it. There is surprisingly little work involved in using the default MOSS approvals forms in your own custom SharePoint Visual Studio workflows, once you know what to look for that is. I’d like to wrap us this post with the benefits to this approach and a few things you should keep in mind when working with the default workflow forms.

Some benefits to this approach

Here are just some of the benefits you get when you reuse the existing MOSS approval task forms rather than creating your own customs InfoPath task forms:

No InfoPath forms development
No InfoPath forms deployment
Out of the box user interface for:
- Approve
- Reject
- Cancel
- Reassign Task
- Request a change
- Instructions to approver
- Capture approver comments
Out of the box multi-language user interface with appropriate MOSS language packs. Notice the references to “$Resources:”.

A few things you should know

Any action in default task forms except Cancel marks the task “Complete”. Your workflow must then create a new task with the desired action from the completed task. For example: If a user re-assigns the task to a new user, the task for the user is marked complete. Your workflow must create a new task and assign it to the new user.
The MOSS task forms derive most of their data from fields in the ExtendedProperties of the task, not the main task properties.

Guest Author: Eugene Rosenfeld
Things that Should be Easy

Eugene Rosenfeld is the CTO of Black Blade Associates. He started his IT career as a database programmer and soon moved into enterprise application integration (EAI) and portal systems. Eugene holds a strong belief that all systems should have the innate ability to intelligently communicate with one another. Most recently he has been heavily involved with distributed systems architecture, Services Oriented Architected (SOA), peer-to-peer systems, and cloud computing.