CTP1 of PivotViewer Extension for Reporting Services Available Now

Pivot No Comments »

It’s here! It’s here!

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d31f609d-a353-41ad-a1a4-f81456e3a6c4

PivotViewer Extension for Reporting Services is a utility that enables users to effortlessly build stunning data experiences on top of their Business Intelligence data. You can:

  • Interactively explore and analyze your Business Intelligence data in a very visual and dynamic manner, using a SharePoint web part that embeds the PivotViewer Silverlight control.
  • Instantly generate a PivotViewer application for SharePoint on top of your BI data, using the tools provided.
  • Go beyond standard limitations of the PivotViewer control and define collections that span large numbers of items and use the provided WCF service for SharePoint 2010 in order to serve these collections in a scalable and high performing manner.

Problem: MOSS Alternate Access Mapping (AAM) & PerformancePoint Reporting Services Reports

PerformancePoint 5 Comments »

(This refers to MOSS 2010 and PPS V2)

Today I needed to make an internal PPS demo available via the internet, so some alternate access mapping within SharePoint was in order.

I added an AAM entry for my default web site, essentially converting http://foo into http://demoname.domain.com inside MOSS.

When I fired up the dashboard via http://demoname.domain.com, my analytical grids/charts, scorecards and filters worked correctly. However, the PPS reports which are based on SSRS RDLs living in an integrated-mode SSRS server were broken. I got “Internet Explorer cannot display the webpage” errors instead of my reports.

It appeared to me that PPS Services wasn’t “checking in” with MOSS AAM to see if it needed to “fix things up” when it came to SSRS reports.  To validate this hunch, I used Fiddler while launching the dashboard. All of the calls to render my charts and filters dutifully hit demoname.domain.com. However, I saw a lone call to “foo”. The URL was:

http://foo/ReportServer?http://foo/Report%2520Library/WWReach_ClickThroughRate.rdl&rs:Command=Render&rc:Toolbar=false&rc:Parameters=false&rc:DocMap=false&rc:Zoom=100&rs:Format=HTML4.0

Bingo! I also tested an SSRS report embedded directly into a MOSS Reporting Services Web Part. It worked fine, too.  Looks like a problem with PPS only.

And I’m actually dealing with two reports – one with parameters, one without. I went into PPS Dashboard Designer and updated the Report Server URL and Report URL property for both. For example:

http://foo/ReportServer became http://demoname.domain.com/ReportServer …and… 

http://foo/Report%20Library/ReportName.RDL  became  http://demoname.domain.com/Report%20Library/ReportName.RDL:

Each time I made the change, DD threw this error:

Unable to find report server specified by URL. Please verify that both Server URL and Report URL are correct.

So it looks like the Dashboard Designer isn’t attempting to be “AAM-aware”, either.

Anyway, I re-published both modified reports from Dashboard Designer and checked the dashboard again. The report which did not use parameters worked fine. However, the parameterized report (which accepts input from PPS filters) still failed, but with a new error:

Unable to get filter values from “Filter Name”. You do not have permissions to view this data.

Sigh.

Back in Dashboard Designer, I saw the problem: By plugging in http://demoname.domain.com instead of http://foo, I had essentially “zeroed out” the parameters for my report. The only way I could get the parameters for this report to populate correctly was if I pointed  to http://foo, which obviously wasn’t going to do me any good.

The solution:

When in doubt, try notepad.  First, I used Dashboard Designer to “re-point” the Report Server URL and Report URL values of the still broken report back to http://foo so I could get my parameters populated again. I saved my changes.

After that, I opened the DDWX file up in notepad. I did a search for the property names “ServerURL” and “ReportURL”.  When I found the entries for my “broken” report, I swapped in demoname.domain.com for foo in both places and saved once again.

After that, it was time to open up the DDWX one more time in Dashboard Designer. I used the Mark Differences command to verify that PPS “saw” a change between what was on the server and in DD, then I did a Save All.

Lo and behold, the dashboard now worked…both SSRS reports were happy.