Quick Post : Workflows not working on a PS2010 farm where the Web Front End Service is disabled

I thought I would post this little gem so I don’t forget it. Hopefully it will be of use to someone else as well.

In the last couple of weeks a few people have told me about issues they encountered running Project Server 2010 workflows on a farm where the web front-end service has been deactivated. Deactivating the service can make sense if you are configuring the farm for improved performance by removing the need to listen to and render pages, or when trying to reduce the attack surface (although this is a lesser concern).

Anyway, to cut a long story short, it seems that when you turn the services off, you need to tell Project Server that the service has been turned off and to update it’s workflow configuration settings.  Thanks to Sameh, one of the excellent support guys at Nintex who found the procedure hidden away in an MSDN article from August 2010  at

http://msdn.microsoft.com/en-us/library/office/ff459292(v=office.14).aspx

I haven’t had a chance to test if this on a Project Server 2013 farm using the SharePoint 2010 workflow engine, but I would imagine the same will apply.

Skipping stages with ‘Change / Restart Workflow’ in Project Server 2013 and Project Online & SharePoint Designer

SharePoint Designer 2013 is another tool that provides a means for building workflows, what is new in the 2013 release is it can now build Demand Management workflows for Project Server 2013 and Project Online. Now I am not going to go into the specifics of the tool, as you probably already know my preference, but irrespective of that, I thought it important to share how to build workflows that leverage the Skip to Stage functionality with SPD.

Now I have been advocating using Skip to Stage in workflows forever, if your building a long running workflow, which demand management workflows always tend to be, you would be foolish not to think that the workflow will be perfect from day one and not need updating and restarting at some point. Obviously the more complex your process (and thus the number of tasks, approvals etc. that need to be reapproved / declined) the more painful it becomes to restart a workflow and then progress through to the point you were at before the restart. This is where skip to stage comes in, when the workflow is restarted using Project Server’s inbuilt ‘Change or Restart Workflow’ function and a stage to skip to is selected, the workflow is passed some special settings letting it know that it needs to restart and skip through to the stage the user chose. However, Skip to Stage only works if you build your workflow to take it into account, it doesn’t ‘just work’.

Change Restart Workflows

I should note, this post comes as the result of a question in the Project forums on MSDN / Technet. Specifically, the original poster was having trouble understanding what was happening when using the Skip to Stage functionality of a SPD Project Server 2013 workflow.

So how do you build a workflow to take into account Skip to Stage logic?

Assume the following SPD workflow, it consists of three simple stages, each sequentially transitioning to one another. For each stage, there is a simple Log to workflow history list action, so we can see what the workflow is doing, and a Wait for the Project to be Submitted action (this stop the workflow executing and zooming through to the end).

Example Workflow without skipping

In normal operation, when this workflow runs it will enter stage one, log ‘Stage 1’ to the workflow history list, and then pause waiting for the project to be submitted via PWA. Once submitted, it will move into the next stage, and so on, until it gets to the last stage, when on the final submit the workflow will complete.

If you try and restart this workflow via the Change / Restart Workflow feature, and choose to Skip the workflow on to Stage 3, you would logically expect the workflow to just kick off in Stage 3. However this is not the case, even though the new Workflow Manager workflows allow you to build workflows that jump back and forth, they are still sequential behind the scenes, meaning your workflow needs to start on Stage 1 and move through the various stages to get to Stage 3, including any logic that is defined.

In order to skip the logic, the secret is to use a new action in SharePoint Designer called ‘Include Stage’. When you add the ‘Include Stage’ action, you will see a step entitled ‘If Project Web App starts the workflow normally or restarts the workflow and includes this stage’ added to the designer. This step is the key for ensuring when a workflow is restarted using Change / Restart workflow.

Skip to Stage logic

So what you will see:

  • If a workflow is stated normally, i.e. when creating a project, then the actions within will be run (in the example, the Wait for Event: When a project is submitted action)
  • If the workflow is restarted using Change / Restart Workflow and the stage being evaluated is the one being skipped to, or follows it, then the actions within the step will be run.
  • If the workflow is restarted using Change / Restart Workflow and the stage being evaluated is prior to the stage being skipped to, then the actions within the step will NOT be run.

It is important to remember that any other actions outside of the ‘Include Stage’ step will continue to be run, irrespective of whether the workflow was started normally or restarted.

So there you have it, if you’re going to be building demand management workflows using SPD, then best practice has to be to wrap all your business logic / approvals in one of these ‘Include Stage’ steps.

One final bit of info, the ‘Include Stage’ action also is available for use in the Transition section of the stages, meaning you can change the logic and flow of your workflows depending if the workflow was restarted or not. I am not going to dig into this too much now, but it is there.

Many thanks to John from the Project Product Team for his assistance with the above.

Introducing Nintex Workflow for Project Server 2013

I try not to mix my day job at Nintex with my community work and the content on this site, but today I want to make an exception and share some news on one of the projects I have been working on for the past few months.

I am pleased to announce that we have shipped Nintex Workflow for Project Server 2013 (NW4PS), an update to the popular workflow product for Project Server 2013.

Nintex Workflow for Project Server 2013

NW4PS 2013 provides all the capabilities of the 2010 version for use within Project Server 2013, including:

  • Demand Management workflows– implement workflows that support your full project lifecycle, from creation, through selection, planning, execution and to closure, leveraging an array of actions, including Query Project Server (PSI data), Project Publish and Change EPT;
  • Event Driven workflows – associated workflows to over 115 different Project Server event handlers;
  • Collaboration workflows – build workflows to support project collaboration scenarios that can talk back directly into Project Server.

NW4PS 2013 provides a seamless upgrade experience from Nintex Workflow for Project Server 2010, allowing organisations to leverage the new Project Server 2013 capabilities and features without having to worry about rebuilding & refactoring workflows.

As you would expect, Nintex Workflow for Project Server 2013 is fully Project Server 2013 aware, supporting items such as the new security modes, claims and 2010 look and feel in project workspaces.

You can read more on Nintex Workflow for Project Server 2013 over at nintex.com/project

Setting up your Workflow Proxy account for 2010 legacy workflows in Project Server 2013

Workflows in Project ServerYou may be aware that Project Server 2013 can now use demand management workflows built in SharePoint Designer and the new Azure based Workflow Manager. But you may not be aware that the old 2010 ‘legacy’ workflow capabilities are also still present and available for you to leverage.

This is particularly important for organisations that may be upgrading from Project Server 2010 and have invested in demand management workflows and do not want to redevelop or significantly refactor their workflows for Project Server 2013 and the new Workflow Manager.

However, in setting up my Project Server 2013 instance I ran into an issue where I couldn’t register the workflow proxy account details for my PWA instance in Central Administration with what seemed like the correct credentials, resulting in the following error:

The specified Workflow Proxy User Account does not exist

Why is this the case? Well, under the covers, SharePoint 2013 (and Project Server 2013) the default authentication mode has changed from classic to claims. In fact it’s no longer possible to create a claims web app via the GUI any more, only PowerShell. If you have a claims based web application hosting PWA, you need to enter the workflow proxy in claims format. So instead of a domain\username format credential, enter the account in the correct claims format i.e. i:0#.w|domain\username.

One other thing I wanted to share when looking at 2010 legacy workflows in Project Server 2013, they will log to the ULS as Legacy Workflow Infrastructure, instead of the usual Workflow Infrastructure, so make sure you are looking in the right place Smile

Filtering Projects for Portfolio Selection

A question came up in the Project forums recently around how it was possible to filter the available projects for a portfolio analysis, so I thought I would post a little tip here, which from a majority of the Project Server 2010 implementations I have seen is usually forgotten or managed by business process.

When you create a portfolio analysis, Project Server allows you to choose which projects you want to use as part of the analysis, out of the box, this shows you all the projects currently within the PWA instance, irrespective of their status. This is fine, but can be confusing for end users who need to go in and manually pick out the projects they wish to include and can be prone to errors (you don’t want to include a project already selected in a project selection analysis again do you?).

Portfolio Selection - All Projects

Luckily the project selection component supports views. It’s tucked away in the top right hand corner but it’s there. Through the views we can choose to restrict the default view of the project selection dialog to show just those projects that are at a certain stage in the project lifecycle, for instance, ready for selection.

To configure the view, navigate to Server Settings > Manage Views and look for the Portfolio Analysis Project Selection views. By default Project Server creates a single Summary View. I would suggest leaving that view intact and create a new view that we will place a filter on, in this example I will call it the Projects for Select view. Within the view, choose the project custom fields you wish to have visible.

Configure the Project for Select view

 

In order to only show those projects at a certain stage, we need to add a filter to the view, to do this click on Filter and configure it as follows:

Configure the filter

In this example, the view will now filter for those projects that are in the workflow stage of 3. Select Checkpoint

Finally, assign the view security category as you would with other views and click on Save.

Select Projects - Filtered for correct stage

The new Portfolio Analysis Project Select view is now available to be used, ensuring only those projects that should be considered in the portfolio analysis are available.

Collecting business requests in SharePoint and automatically pushing into Project Server

At SharePoint Saturday Toronto, I presented one of my favourite sessions on SharePoint Governance and Lifecycle Management using Project Server 2010, based on Christophe Fiessinger’s and Scott Jamison’s session from TechEd NA 2011. I’ve delivered this session three or four times now, showing how organisations can benefit from using Project Server to collect business requests and guiding them through a process to successfully collect information, objectively determine which project to implement and then assist in the implementation.

Each time I have delivered the session, I have been asked if there were ways to collect the initial business requests outside of Project Server, in a SharePoint list for instance, reducing the need to licence and more importantly train all users within an organisation that may wish to lodge a business request. So, for SharePoint Saturday Toronto I decided to implement an interface that allows the business requests to be created initially in a SharePoint list and then via a workflow pumped into Project Server for the Project Server governance process to be applied.

image

 

This post shows you how you can implement it too. For this example, I will be using Nintex for the workflow component (disclosure, I work for Nintex), but you could also use a SharePoint Designer built workflow with the Christian Glessner’s iLSP SharePoint Designer Add-ons and a little elbow grease.

At a high level the solution has three components:

  • A SharePoint list that will be used to capture the business request. The list should be configured to capture the relevant items for the business request. In this example, the list requests the project name and a description, but you could extend this to capture other information such as anticipated budget, business need etc;
  • A default Enterprise Project Type configured to use the SharePoint Governance and Lifecycle Management demand management workflow. This EPT should also have a default Project schedule template associated; and
  • A list workflow associated with the SharePoint list above that will be used to call the PSI to create the project.

 

The list

Configure a SharePoint list to capture the information you want to capture. In this example, I have only captured two fields, as the rest will be captured within Project Server.

Both fields are set to be mandatory and the title field has been set to enforce unique values.

SharePoint list columns

 

The EPT

The Governance and Lifecycle Management white paper and databases guide you through the process of configuring a demand management workflow and EPT. For the list workflow to create a project automatically, it is essential to make sure this EPT is set as the ‘default’ and that a Project schedule template has been uploaded and associated with the EPT.

Before building the workflow, we need to know some information about the project schedule template, this will be used by the workflow to create the project. Each project template is stored within the DRAFT Project Server database and can be extracted with the following query:

SELECT PROJ_NAME, PROJ_UID FROM MSP_PROJECTS WHERE PROJ_TYPE = 1

Write down the PROJ_UID of the relevant record for the Project Template you associated with the default EPT.

 

The Workflow

The key component of the process is the workflow that will take the list item and create a project in Project Server. As I mentioned above, in this example I will use Nintex Workflow & Nintex Workflow for Project Server as it has Project Server specific actions, but you can achieve a similar outcome in SPD with a little more effort.

The workflow itself consists of only three actions, the first action ‘Call Web Service’ is used to call Project Server’s PSI and specifically the Project web service and the CreateProjectFromTemplate web method. This method creates a project within Project Server based on a specific project schedule template.

The action should be configured as below, ensuring you change the URL of the web service, credentials and Template GUID to match your environment.

Configure Call Web Service Action

The projectName field above is using the Title variable. A great thing about Nintex is that you have access to the list context information by clicking on the lookup icon as below:

Select item title

The final part of the configuration is to capture the UID of the project that is created. When CreateProjectFromTemplate is called, if the method is successful it will return the UID of the created project in an XML envelope.

The Call Web Service action can listen for the response and parse it. To do so, click on Specify Elements and then Select Element.

Web Service Output

A XML browser dialog will be displayed allowing you to select which item in the response to read, in this case we are interested in the CreateProjectFromTemplateResult, so select it and click on Apply.

Web Service Response

Choose to save the returned value into a variable called ProjectUID, this will be used later.

The second action is also a Call Web Service action, this time used to Publish the Project in Project Server, up until now our project has resided in the Draft database, performing this publish will make sure it is published and therefore visible in PWA.

Like the previous action, configure the web service to call the Project PSI server with the relevant URL and credentials.

Publish Project

For this action, choose the QueuePublish method. This method has different parameter requirements:

  • jobUid – A GUID used to identify the job, in this case use the inline function fn-NewGuid()
  • projectUID – the UID captured in the ProjectUID variable prior
  • fullPublish – true
  • WssURL – leave blank

Once these two actions are run, a project will be created in Project Server using the default EPT and schedule template, all that is needed to do is to copy the other fields from the list into the project custom field using the last action ‘Update Project Properties’ from Nintex Workflow for Project Server that provides a simple wrapper for updating project custom fields. If you decide to use SPD, you would need to perform a raw PSI call to update the property making sure you have created a valid XML message (Fiddler will be your friend here, but a word of warning, it is not simple).

Configure the action as shown below, ensuring you select Title from the lookup field for the Project Name and then choosing to update the WPROJ_DESCRIPTION field with a list lookup against our SharePoint list, the item we are starting the workflow against (our project idea) and relevant field (in this case the Project Description field).

Update Project Properties

If there were other fields you wished to push into Project Server, they can be chosen in the Project Property drop down.

Finally, configure the action to ‘Publish after update’ and to ‘Wait for job completion’.

The completed workflow should look like this:

Completed workflow

All that is needed to complete the workflow is to modify the workflow settings to allow it to be manually started, and to add it to the list item context menu as follows:

Configure workflow settings

Then publish the workflow and you’re ready to start pushing your project ideas from a SharePoint list into Project Server Smile

Of course, what I have shown you above is the tip of the iceberg, with a little more work you could:

  • extend the workflow to add in some approvals before the business request is pushed into Project Server, allowing people like team leads or managers that may not necessarily need access to Project Server to review, add additional information and approve or reject the request;
  • configure the demand management workflow to push updates about where the business request is back out to the SharePoint list; and
  • add additional fields to the list that are pushed through into Project Server custom fields at project creation time.

Speaking at SharePoint Saturday Toronto–7th July

SharePoint Saturday TorontoI am delighted to announce that I will be speaking at my first international SharePoint Saturday, the sell out SPSToronto on July 7th on one of my favourite topics ‘Leveraging Project Server 2010 for SharePoint Governance and Lifecycle Management’.

“You’ve installed SharePoint and now everybody is using it, but how do you handle business requests for new sites, workflows, custom applications, web parts and dashboards? Come along to this session to see how you could implement a powerful request / workflow solution to assist your organization to view, analyze, prioritize and resource requests using the workflow and portfolio analytics capabilities of Project Server 2010.”

I will be at SPS Toronto all day and would love to chat about all things Project, Project Server or Workflow, so if your attending please feel free to reach out via contact@epmsource.com or come and find me in person.

For those of you not lucky enough to have tickets, there is a wait list you can sign up for at http://spsto2012.eventbrite.com/