Project Server technical bits

This has been painful Project Online reporting has been a fairly significant limitation of the Online experience for me so far.  Besides the complexity in building the oData stream, the fairly fundamental limitations of the data filtering of the URI's has been a major falling down point for me. To digress for a moment, most reports people want are timephased in some way, either Actual Work by period, planned work by period, or timesheet data by period.  All of these reports lead to a "time by day" feed.  Now the thing with timephased reports is you are usually looking for a "last three months, next three months" view (or similar).  Also the thing with the Time By Day feeds is that they are HUGE! Add these things together and you really need a way of limiting your data feed to avoid extremely lengthy refresh times. Easy enough I hear you say.  Just put a timebyday ge '2014-01-01T00:00:00' select statement in your URI before adding it into your Pow...

I've been exploring the magical world of Project Online oData Reporting this last month. So far I've managed to pull together some pretty useful PowerPivot-based Timesheet dashboards, and some decent Project/Task Statusing reports.  Nothing as fun as on-premise, but not a bad start.   However....a s well as the well documented service change required to grant reporting access to project online (see here:  http://office.microsoft.com/en-gb/office365-project-online-help/grant-reporting-access-in-project-online-HA104021109.aspx ) there is another issue to be aware of. One thing has been concerning me, and that is data set sizes. As we need to pull down some large tables to build a decent data-model   it has become clear that filtering the feeds is the only way to make these reports workable.  Unfortunately,  with Project Online its not quite as easy as that. SharePoint in Office365 uses WopiFrame to display published Excel reports in the brows...