Sorry, couldn’t resist!

Yesterday (or maybe it was the day before, I forget), the next rev of AllUp was released internally at Microsoft. It includes 3 new demos including a “deep dive” around PPS Planning, and new stuff for the manufacturing and hospitality sectors.  The image will expire around 12/4/2009.

The super-awesome product manager responsbile for this work of art says that it still needs to get a buy off from our legal department, so isn’t available to partners quite yet – but it will be soon!

I spent a chunk of time this morning scratching my head when I couldn’t get PerformancePoint Monitoring & Analytics display actions working in MOSS. They worked fine in certain dashboards I had  already published, but different dashboards published to the same site were broken – display actions didn’t work at all.

I finally got my “misbehaving” dashboards working by employing the following tactics in the Dashboard Designer:

1. Open the Scorecard that contains the KPI your display condition will leverage.

2. On the Edit tab, Update the scorecard.

3. Go back to your dashboard and add/remove/whatever the display condition in question.

4. Publish/Save.

5. Repeat for each display condition you want to work with.

I don’t know if step 5 is strictly necessary, but I spent so much time on this I didn’t want to experiment any more – just needed to get on with my life! I haven’t tested to see if this is fixed in SP1, but hopefully it is!

While building out some dimensions today, I ran into the following error while using Planning Business Modeler. The error occurred when I selected the name of a table/view in my data source:

Server failed to return the table schema from source database. (Error code: PerformancePoint_225000210). Getting table schema for table <table name> from database <database> on server <server> failed.

Turns out PPS can’t handle any tables or views which are not part of the dbo schema. I had a few of them, and had to use the command below to swap the schema each object belonged to before I could get them into PPS.  I suppose I could have created a dbo.View on top of each object, but I was being lazy:

 ALTER SCHEMA dbo TRANSFER someschemaname.tablename

The SQLCAT team just released a very interesting technical note which compares the relative “scalability goodness” of Reporting Services 2005 to 2008. You can read the article just as well as I can, but here’s the executive summary, and the results are pretty impressive (bold is mine, btw)

Executive Summary

Reporting Services 2008 was able to respond to 3–4 times the total number of users and their requests on the same hardware without HTTP 503 Service Is Unavailable errors compared with Reporting Services 2005, regardless of the type of renderer. In stark contrast, Reporting Services 2005 generated excessive HTTP 503 Service Is Unavailable errors as the number of users and their requests increased, regardless of the report renderer.

Our tests clearly show that the new memory management architecture of the report server enables Reporting Services 2008 to scale very well, particularly on the new four-processor, quad-core processors. With our test workload, Reporting Services 2008 consistently outperformed SQL Server 2005 with the PDF and XLS renderers on the four-processor, quad-core hardware platform (16 cores) both in terms of response time and in terms of total throughput. Furthermore, with these renderers on this hardware platform, Reporting Services dramatically outperformed other hardware platforms regardless of Reporting Services version, responding to 3–5 times the number of requests than when running on either of the other hardware platforms. As a result, we recommend that you scale up to four-processor, quad-core servers for performance and scale out to a two-node deployment for high availability. Thereafter, as demand for more capacity occurs, add more four-processor, quad-core servers.

Finally, with all renderers and with all hardware platforms using our test workload, the performance bottlenecks were the processor on the front-end server and the disk subsystem on the data source with Reporting Services 2008, whereas the Reporting Services front-end Web service was the performance bottleneck with Reporting Services 2005.

It’s a whole new ballgame, folks!