First published on TECHNET on Jun 19, 2015
This does also apply to Project Server 2013, and will to Project Server 2016 too – but mostly OData will be used in the Project Online space. You can hit issues when using certain names for your custom fields if they clash with the names we are using for properties in the OData feeds. We don’t block you from using these words – partly because you may not care about OData so not need to worry – and maybe you already had these fields (in an on-premises environment) before coming to Project Server 2013. Another dimension to this issue is that in each of the languages for Project Online this list of words is different. I posted a while back on this topic – but didn’t give the full list or cover the language part.
My initial thought was to have a post which listed all the reserved words – but I soon found that this would probably not be too helpful or practical. But there is a way to get a list from your site itself! If you use the Url of the following format .sharepoint.com/sites/pwa/_api/ProjectData/$metadata">.sharepoint.com/sites/pwa/_api/ProjectData/$m... then this returns the full list. Here is a snippet from my PWA instance – which happens to be a US English system:
This goes on for quite a few pages, but basically anything after a Name= should be considered a reserved word. If I scroll down a little I will see my custom field names:
As you can see, one of these is ProjectID – which clashes with the ProjectId in the upper snippet and gives me an error if I try to look at Project level data via my OData feed. This ProjectID could even be Project ID or P ro JectI D – as we strip out any spaces when creating the OData names for the fields. If removing spaces gives a duplicate (within the custom fields) then we add a ‘1’. Here is the error I would see if I browsed to .sharepoint.com/sites/pwa/_api/ProjectData/Projects">.sharepoint.com/sites/pwa/_api/ProjectData/Pro...
<?xml version="1.0" encoding="UTF-8"?>
<m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<m:message xml:lang="en-US"> An error occurred while processing this request.</m:message>
</m:error>
If I were to browse to this same OData feed but force the language to be French for example – then I wouldn’t get an error – using Url .sharepoint.com/sites/pwa/_api/ProjectData/[fr-Fr]/Projets">.sharepoint.com/sites/pwa/_api/ProjectD... . Notice that I have the use the French ‘Projets’ in place of Projects – and I can see that the French translation of my ProjectId is actually IdProjet. My custom field is still called ProjectID as it has no translation.
To get the list of reserved words for any language supported by Project Online just use the Url with the format of .sharepoint.com/sites/pwa/_api/ProjectData/[https://<yourdomain>.sharepoint.com/sites/pwa/_api/ProjectData/[<LCIDstring>]/$metadata . LCID string is usually of the format en-US – so language then country. So for example pt-BR is Portuguese Brazilian and pt-PT is Portuguese Portugal.
So for example for French we use https://<yourdomain> .sharepoint.com/sites/pwa/_api/ProjectData/[pt-PT]/$metadata and this will start:
One check I have used to detect a reserved word issue is to switch languages. As shown above, I can switch from English to French and the view of Project data then works – and I can even scroll down to see the custom fields and see if any are likely reserved words – then check by using the $metadata view back in English.
I’ll be following this posting up with another related issue that the language differences can give you. Stay tuned.