Building your first Project Server app : Part Zero–The introduction

PublishAllLogoOne of the many exciting additions to Office 2013 was the introduction of apps, through these apps it is possible to add, extend and enhance the functionality available to users, for example you could have an app to help track election results, add Facebook social to your sites or build workflows. The apps themselves are available for a number of the desktop clients, as well as SharePoint 2013 and Project Server 2013.

The idea behind apps in SharePoint is pretty simple, instead of allowing users to deploy what are known as ‘Full Trust Solutions’ to the SharePoint environment (these are solutions that execute code directly on the SharePoint servers) that could destabilise or alter SharePoint and impact it’s availability, Apps allow the same functionality to be hooked in remotely. The key to the app model is some clever architecture, allowing apps to be run either inside an isolate app site within SharePoint (known as SharePoint hosted), within a Microsoft Azure instance (Auto Hosted) or remotely on a providers infrastructure (known as Provider hosted).  Through a number web friendly technologies such as oData, REST and CSOM, these apps can hook into SharePoint and Project Server seamlessly as if they were still installed on the same servers.

The apps, once built are available to be added to your SharePoint and Project Server sites from a central app marketplace. There are two options to choose from, a Microsoft hosted and operated app store, where apps are submitted, validated and then made available for download either at cost, or in a trial mode. Or if an organisation has developed their own app that they just want used internally, they can be deployed to a organisational app store called the Corporate Catalog (we’ll talk more about that later on).

SharePoint App Store

Of course the great thing about apps and the Microsoft ecosystem in general is the information and tooling that is provided for you to build and customise these apps. Microsoft has spun up a dedicated blog and developer site to guide you through the concepts, requirements and process of building apps.

So where is all this going?

Well, I thought I would set out to build an app for Project Server. Thanks to an idea from a mailing list and some discussion amongst some of the Project MVPs, I decided to set out to build an app that when installed in PWA, allows you to publish all Enterprise Projects at the click of a button.

There is a fair amount of things to cover, so I have created a number of posts to cover the various topics:

    So make sure you stay tuned over the next few weeks



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…$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