Retrieving the ProjectUID of a workspace using _api REST interface

Project workspaces are awesome. There I have said it. But one thing that has always frustrated me and other users is how hard it is to determine what project the workspace is linked to. The only reliable way of determining the ProjectUID is to look in the Property Bag of the site where Project Server stores the association. There are a couple of tricks that will let you find out the ProjectUID, one of them being developing a custom web part like I did a while back, or using the CSOM in 2013 as Giles Hamson posted a while ago,

But there is an easier way, thanks to the new _api REST interface.

With this new interface you can expose all aspects of the SharePoint site including all the web, site and lists. However the coolest thing is that you can expose values from the Property Bag directly, meaning we can get the ProjectUID of the site with a simple URL call which you can either use in your JavaScript code, or call it directly from a workflow.

The URL looks like this…

https://mytenant.sharepoint.com/sites/pwa/New%20Project/_api/web/AllProperties?$select=mspwaprojuid

if you break down there are three components…

_api URL format

The first component is the URL of the site we want to get the ProjectUID from.

The second component is the _api call we wish to make, in this case we are retrieving the AllProperties of the web object.

The third component filters the AllProperties to only retrieve the MSPWAPROJUID property, which is where the ProjectUID is stored.

When you open that url in the browser, you receive the following XML back from SharePoint containing the ProjectUID.

ProjectUID returned

Of course you are not limited to just the ProjectUID, removing the filter component from the URL will retrieve all the properties of the Project site including the URL of the PWA site it is associated with (PWAURL).

All Properties

ProjectUID Filter Provider for Reporting Services Viewer Web Part

Visual Studio 2010 - Custom Web partA couple of months ago, I was wondering if there was a simple way to show project reports automatically within a project workspace. The problem seems quite simple at first, all you need to do is work out which workspace you are in, then pass that value into the Reporting Services viewer web part as a web part connection. After a bit of experimenting with the out of the box web part filter providers, jQuery and other black magic, I quickly came to the conclusion that this wasn’t going to be an easy ask and so cracked open my old friend, Visual Studio 2010.

A couple of hours later (yes, it really did take me that long), I came up with a web part which I have called the ProjectUID Filter Provider for Reporting Services Viewer Web part. To use it you simply drop it onto a Project workspace, the web part will determine the ProjectUID of project the workspace is linked to and then make that available via a web part connection that the Reporting Services Viewer can consume.

Once installed, the web part is available for use in the custom category of the web part gallery.

Web part in the web part gallery

When added to a workspace, the web part is very minimalistic with the following chrome in edit mode and nothing in the normal rendering mode.

ProjectUID web part chrome

If the workspace you are adding the web part to is not connected to a Project, or is not a Project workspace at all, then an error message will be displayed.

To utilise the filter, add a Reporting Services Viewer web part onto your project workspace. In this example I have added a single Reporting Services Viewer web part and configured it to render the Project Status Report from the Project Demo and Evaluation Pack.

Report Viewer Web Part

Next we need to connect the filter provider web parts together, to do this select the context menu for the Reporting Services Viewer Web part, then choose Connections > Get Report Parameters From > ProjectUID Filter Provider for Reporting…

Connecting the web parts

A dialog box will then be displayed allowing you to wire these together, which will default to the ProjectUID. Click on Finish and the web parts will be connected.

Configure Connection

Once you are happy with the page and stopped editing the Project Status Report will render automatically using the ProjectUID passed in from the Filter Provider for Reporting Services Viewer Web part.

The final connected webpart

Of course, the real value of this web part comes into its own when you have more than one report on the page that you wish to render for the specific project. By creating multiple web part connections you can supply the ProjectUID to other Report Viewer web parts.

Now, as I mentioned above I have been sitting on this web part for a few months, why you may ask? Well, for me the killer use of the web part would be to use it in a Project Workspace template, so you could template the reporting dashboard. Unfortunately though if you were to configure the web part connections and create a template, the connections are lost due to the way SharePoint works Sad smile There are solutions to this, which are quite complex and involve event receivers, which I haven’t had a chance to look at in detail just yet. So please be aware of this limitation if you choose to use the web part.  The reason I decided to release the web part now was to help a Project forum user that was after this very capability.

The web part and associated source code can be downloaded from my Skydrive account by clicking below. As usual, this is provided as is, with no warranties or support and use at your own risk etc etc.

Download from SkyDrive

ProjectUID Filter Provider for Reporting Services Viewer

Of course, if you find the web part useful, or wish to suggest changes, please do not hesitate to contact me.