Project Online: Changes to Granularity of Time phased OData

This post has been republished via RSS; it originally appeared at: Project Support Blog articles.

First published on MSDN on Nov 29, 2017
This was announced a while back as you needed to be aware of the impact on reporting – and you should have seen the posting in the Office 365 Admin message center.  This is rolling out now, and the message center post has just been updated to say that we should be completed by around the end of the year.  (If you are not seeing the message center posts – then talk to your admin and share my blog post https://lwal.me/3n ).  The official article on the time phased data roll-up feature can be found at https://support.office.com/en-us/article/Configure-rollup-of-timephased-reporting-data-in-Project-Online-da8487fe-899e-4510-a264-e2ebc948928c .  I’ve also been beaten to the blogs by Paul Mather (and probably others) so I’ll try not to just repeat the great content that is already out there – but highlight a few of the nuances.

The change has a few different aims – and one is certainly to give you faster reporting against your Project Online data.  This can be achieved if the new granularities of weekly or monthly work for you better than daily – with the added bonus that the publish will be a lot faster too!  We don’t have to break the project data down to a daily level for publishing, then have you pull the daily data only to have you aggregate it back to weekly/monthly again.  It will save space too – both in your tenant but also in any local data warehouse you are using.

The first thing to say is we aren’t changing anything automatically.  We are changing the OData schema so you may need to change your reports to ensure the schema changes do not break anything – even if you stick with ‘Daily’ – see this article for more information on best practices.



If you create a new PWA however, we do now set the default granularity as ‘Never’ so that you will need to make a conscious choice on the granularity you want – or leave it as ‘Never’ if you do not need time phased data (your publish times will be faster!)

I’ll walk through some scenarios, and I’ve also changed my regional site settings to make it more interesting – with my week starting on a Saturday and the first week of the year being defined as the First full week.



I’ll use a dummy project that I’ve created with work, costs, baselines etc. – just so we can see what happens to the data in various scenarios.  This is my plan – with 3 work resources, a material resources, a cost resource and a budget cost resource.



With my new default (as I only created this PWA site this morning) of ‘Never’ for my timephasded data I find that I have no records in any of my timephased data sets.  This is expected!  I’m showing this in Excel – but you’d see the same just browsing to the OData endpoints under …/PWA/_api/ProjectData.  I see 2 projects as it records the Timesheet administrative dummy plan too too – which also accounts for the 7th Task – and the 6 baselines are for the 6 tasks in this project.  The TimeSet just records the days from 1984 to 2149, and will always be 60,631.



I’ll switch to Daily in my reporting granularity settings and republish and see what I see…  and now I have some time phased data – and 828 rows in each of the feeds.  This is a record for each day that has values – and in this snippet I see some costs, actual work and budget cost for one of my tasks.



Next I’ll take a look and see what weekly looks like…. and this gives me 120 records for each time phased data set.  One record for each task for each week there is something to report.  The records aren’t in exactly the same order – but you can seer the weeks that are totaling 120 and 80 are those with 16 and 24 hours per day.  The dates the time shows against – such as 9/30/2017 – are Saturdays as that was the day I had set in my regional site settings as the First day of the week.  I’ll come back to ‘week of the year’ later.

*** Update 11/30 - there is a slight change that will likely arrive before you see the feature - any roll-up such as weekly/monthly/fiscal periods - will record data against the FINAL date of the period rather than the FIRST.  Currently as of 11/30 you will still be seeing 'FIRST' as per my screenshots ***

*** Update 12/5/2017 - back to Plan A - all aggregations will list against the FIRST date in the period - as per my screenshots ***



Next I’ll go to the Monthly option – and that is Monthly set in the reporting time phased granularity page and not using a Fiscal Period of Monthly.  Here I just have 32 records in my time phased data sets (and they are only matching as I just have 1 assignments per task and the same durations for task/assignment) – with each data item being recorded against the 1st of the month – and we get to see all the rows in one view – with the project summary task being at the top.



Now stepping on to Fiscal Periods.  Hey – where did my data go!



As it mentions in the Reporting configuration page – “I mportant: Reporting data will only be generated for defined fiscal periods. Also, if you change an existing fiscal period, you will need to republish all projects.” and as I have no defined periods (see above – my FiscalPeriods feed is empty) so I will need to go and create some.  I’ll define 2017 first on its own to stress the point – and I’ll use the 4,5,4 method.





Now at this point I discovered a bug of sorts – fiscal periods need to be complete years, and the default for the 4,5,4 pattern leave 12/31 out on a limb…  My Reporting (Project Publish) jobs went down a hole trying to work out what their calendar was and after an hour or so they failed.  We are looking in to it and the fix is easy (once you know what caused the problem – I had a few variables in my plan and hadn’t noticed my year finished too soon).  Not sure if we will address this, but now we are making more use of fiscal periods it might make sense to not allow an incomplete year to be defined.  So once you define the 4,5,4 make sure the final period goes to 12/31- unless you are creating 2018 now too in which case you could start that on 12/31 – whatever works for you.  This same issue can be seen if you don’t have Fiscal Periods defined for the complete duration of your plan – so for example in my case as my plan starts in October 2017 and finishes in March 2018 and my Fiscal Periods start in January – I need to create both the 2017 and 2018 Fiscal Period.  I’m getting some confirmations of this, as the reporting page appears to indicate that you will only get data if you have defined the Fiscal Period – which to me meant that I could ‘choose’ not to create my Fiscal Period for 2018 if I was only interested in 2017 at the moment – so my publish would be quicker and I would use less space and reporting would be quicker (though only for 2017).  However, currently projects will fail (after about an hour in my tests) at the Reporting (Project Publish) unless all the Fiscal Periods you need are created.  I hope to hear that this is a bug.

*** Update 11/30 Confirmed as a bug and we have a fix coming - we will not fail if any missing dates or periods exist.  For example if you only defined Fiscal Periods for 2017 and 2019 then a plan from 2017 to 2020 would only publish the details for 2017 and 2019.  Not sure why you ever would - but that is a good way to describe the behavior you will see) ***

Back to the main story – I have my Fiscal Periods for 2017 and 2018 configured – complete with 12/31 for each year so I publish my project:



Now I see 31 rows – 1 fewer than my monthly based report as the pattern of the fiscal periods doesn’t quite match up to the monthly boundaries.  I can see too that I have records coming from my Fiscal Period feed – and also see the Fiscal Period UID in my TaskTimePhasedDataSet for each row (Previously I just saw the NULL GUID (0000000000…).

Time to take a look at some of the other fields new with these changes and lets dive into the ‘Projects’ feed.  We can see for the project which time phased granularity we have from the new field ProjectTimePhased – so this confirms that when this project was last published the granularity was set to ‘By Fiscal Period’.  We cannot tell what the fiscal period configuration is, but looking at the TimeSet feed we could deduce that from the dates and fiscal periods.



Towards the end of the field list in the Projects feed we have some more new fields – and these relate to workflow and you can read more about these in the support document at https://lwal.me/4f . In my feed these are unpopulated and I am planning another blog posting where I’ll take a deeper look at these, but you will see that we now expose the WorkflowCreatedDate, WorkflowError, WorkflowResponseCode, WorkflowInstanceId, WorkflowOwnerId and WorkflowOwnerName.



With this information we hopefully make it much easier to spot any issues with workflows, and you (The PMO or helpdesk) will be able to proactively see what is happening to workflow across all of your projects rather than waiting for a project manager to come across a suspended or failed workflow.  As I said – more on that in a future post.

So in summary the new options for reporting allow you to considerable reduce the amount of data you might need to access – by 25 times in my example, that is assuming that monthly totals is ok for you – or around 1/6 of the data if weekly is your thing.  And the added benefit not just when reporting on the data but each time you publish too!  You can change these at any time, but you would then need to re-publish all of your projects (or at least the ones you wanted to report on) – so you might also want to look at some kind of automated publish option such as using PowerShell or Javascript.  You can search online for various articles on this – one of my favourites would be Paul Mather’s javascript example .

I’d love to hear back on how you find this works for you and which granularity is best in your scenario.  Or do you think you might change?  Maybe run with Never or Monthly and maybe switch to Daily and republish when you need the deeper granularity?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.