I’ve been working on a full end-to-end demand management workflow over the past couple of weeks and unfortunately as RTM is due any day now, much of the final documentation is still not public, meaning that some things just need to be figured out.

One problem that I found is the custom workflow task form, which has a very useful "Review project details" link on it. However if you have used Microsoft’s demo2010a image, then you’d see that for all of the workflow’s the link initially does not work. (See image)

clip_image001

 

Fortunately this one was relatively easy to guess, thanks MS for making it quite obvious!

Firstly a custom workflow task content type called PSWApprovalTask is created by default in the PWA site "Project Server Workflow Tasks" list, here’s what it looks like out-of-the-box:

clip_image002

 

Interestingly though, it is not by default added to the list content types, BUT if you run through the Sample Proposal Workflow once then you will see it appear in the list automatically. For the purpose of this just use the ‘Add from existing site content types’ option in List Settings to add it:

clip_image003

 

Now another interesting thing is apparent on the list settings page:

clip_image004

 

Specifically Microsoft has pre-defined three Columns named: Project Name, Project Owner and ProjectUid (and some others..), however they are not added to the content type by default either, but they are used in the views including the default My Tasks.

To the point:

Now getting to the point of this post, if you use the content type and populate all of those fields then the task approval page will work as expected! Specifically the ProjectUID Column needs to be populated with guess what: the Project’s GUID, once that is done then the link works as expected!

Too easy!

Well unfortunately not. The Visual Studio Workflow Activities included with Project Server 2010 gives you the very handy ReadProjectProperty action, however while having a choice of either reading a Custom Field based on GUID or a pre-defined built in field based on name, it does not include Project GUID. This is where it gets complicated.

The “simple” solution is to use PSI, then using something like this nice little method created by Chris Boyd you can retrieve the GUID by providing the Project Name using PSI method ReadProjectStatus.

Unfortunately having to use PSI in what otherwise could be a very simple SharePoint workflow in my opinion is clunky, it would be very nice if MS could add the Proj_UID property to the ReadProjectProperty action!

If you’re interested, based on Chris’s blog post linked above, here is an extract of my code to get all of those fields working (Note that this plugs in nicely to my last code post: Extending the Branching Workflow):

// Declare your PSI Stuff
private static WebSvcProject.Project project = new WebSvcProject.Project();

private void createTask_InitApproval(object sender, EventArgs e)
{
    [… insert your other required task attributes …]
    taskProps.ExtendedProperties["Project Name"] = Proj_Name[0];
    taskProps.ExtendedProperties["Project Owner"] = Proj_Owner_Name[0];
    taskProps.ExtendedProperties["ProjectUid"] = GetProjectUidFromProjectName(Proj_Name[0]);
}
public static Guid GetProjectUidFromProjectName(string projectName)
{
    Guid projectGUID;
    project.Credentials = CredentialCache.DefaultCredentials;
    WebSvcProject.ProjectDataSet readProjDs = new WebSvcProject.ProjectDataSet();
    readProjDs = project.ReadProjectStatus(
        Guid.Empty,
        WebSvcProject.DataStoreEnum.WorkingStore,
        projectName,
        0
        );
    if (readProjDs.Project.Rows.Count == 1)
    {
        projectGUID = new Guid(readProjDs.Project[0].PROJ_UID.ToString());
    }
    else
    {
        throw new Exception("No Project by the name: " + projectName + " Found");
    }
    return projectGUID;
}

Enjoy!

Update 4/08/2010:Check the comments below for a much easier way to correct this issue, without the use of PSI.