Tips, Tricks, and General Info on the Msft BI Platform : Report Builder

Demo files Used In My BI Conference Session...

jbasilico — Tue, 07 Oct 2008 17:42:00 GMT

For those that attended my session (Designing Effective Dashboards with Msft BI Platform) at the 2nd annual Msft BI Conference in Seattle, and had asked for the demo files/projects, you can download my demo files here. The zip file contains the SQL Server 2005 Reporting Services project file, SQL Server 2008 Report Builder file for the combined sparkline and bullet graph, PerformancePoint workspace file, and the "minimum" masterpage for MOSS. Keep in mind that you'll need to alter the location of your Reporting Services installation, the Analysis Services AdventureWorks database, as well as the PPS service site on MOSS. Enjoy!

Creating UDM Report Builder Models in SSRS-MOSS Integration Mode

jbasilico — Thu, 31 Jan 2008 19:04:00 GMT

I've seen this question come up on many a proof...and that is how do you generate Report Models off an Analysis Services UDM (OLAP cube) once you've put SQL Server 2005 Reporting Services into Microsoft Office SharePoint Server (MOSS) Integration Mode. Well, when not in MOSS integration mode, it was rather simple...just deploy the data source to Analysis Services and then either use Report Manager or SQL Server Management Studio to generate the "model" off the data source. So now you’re staring at the MOSS UI, but don't see a way of generating the UDM based model...well, you’re probably missing some MOSS configuration to enable report model generation. The configuration you need is to enable multiple content types for the library your working with (for example the data connections library for the "Reports" subsite in MOSS), and then add report server types to that library. I normally will go ahead and add the "Report Builder Report", "Report Model" and "Report Data Source" content types to the library. For full details on how to configure these content types in MOSS, refer to this BOL section from SQL Server 2005.

Once you've added these content types to the library...actually creating the Report Model from the UDM is rather easy, and it’s just two steps: 1) Create the Report Data Source (if not already deployed to the MOSS site), and 2) Create the Report Model. With the new content types added to your MOSS library, both of these steps are as easy as clicking on the "New" item from the MOSS menu, and picking the correct item (either data source or model). Obviously you'll want to generate the UDM model based from the UDM data source you created in step 1. For full instructions on creating the Report Model from within MOSS, review this BOL section from SQL Server 2005.

Implementing Parent-Child Relationships in Report Builder - Well Sort Of...

jbasilico — Sun, 27 Jan 2008 22:34:00 GMT

Ok...everyone should know by now that SQL Server 2005's Report Builder doesn't support parent child relationships within a report model (think about the classic employee to supervisor hierarchy...or for another example, how a company may roll up into a parent company/entity). So...how do you overcome this limitation of the SQL Server 2005's Report Builder/Model? Well, unfortunately there isn't a simple answer or solution...but there is a partial workaround. The workaround leverages SQL Server 2005's Common Table Expressions (CTE) and a compromise by the business users.

First...lets tackle the compromise by the business users. Since a parent-child hierarchy can be infinitely long...you'll need to pin down from the business users the anticipated largest depth of the hierarchy. For example, does the employee to manager hierarchy have three levels, or four levels, or five levels deep? Once you determine the longest "known" depth of the hierarchy, you'll use this knowledge to create a recursive query within the database to produce known levels for traversal.

The next step is to create a recursive query within the SQL Server 2005 database. If you need to learn about the recursive query CTE, then read this SS2K5 BOL entry, or check out this great blog entry on the topic. The CTE based recursive query should give you a result set something like "parent, child, level". Once you have the recursive query in place, you'll then want to construct a view from the CTE, whereby you'll leverage the view to join the identifier parent and child pairs to the decode table to return identifier names (assuming your model is normalized in this manner) down to the number of levels deep as compromised by the business users.

Once the recursive query is defined, you'll most likely then create a named query with Report Builder's "Data Source View" (DSV). This named query can be simple, or rather complex depending upon your database model and the number of custom Report Builder "click through" reports you want developed. Meaning, if you want a custom click through report for level 1 versus a different custom click through report for level 2, you'll need to create two separate named queries within the DSV, since an entity can only have one custom report per scalar or aggregate value. (For more information on creating custom click through reports for Report Builder, view this SS2K5 BOL entry).

Ok...that's it. You should now be able to traverse a parent-child relationship successfully within Report Builder...albeit with a compromise from the business end-users.