Reporting Services BI Tools (2008 R2)—a Wish List

• First, I expect the next version of the BI report authoring tools will use the new WPF version of Visual Studio. Hopefully it will be faster by then but it remains to be seen if that’s even possible given the architecture. Sure, it runs okay on my new dev system but it’s a i7 980x with 12GB of RMA and SATA 3 drives but on ordinary systems, it’s still pretty sluggy.
• Consider that by the release of the next version a significant number of developers will have an urge to use the SharePoint Integration (SI) mode instead of the by-default native mode to manage their reports and all of the infrastructure associated with it. Because of this, my clients and I would really like to see a migration utility to permit the SharePoint admin to import an existing RS catalog and leave very little work left to do to get back online. As it is, we’re forced to redeploy each and every report project and spend the next week adding back the subscriptions, snapshots, property settings, custom data sources, rights, users, roles and the rest.
• This leads me to my next point, I would like to see a way to more easily build a Visual Studio BI Solution containing several Projects—each targeted to a specific folder in the SharePoint scheme. Sure, you can do that now but it’s a PIA to configure each project individually. I think it would be very useful to target the Server URL and all other project properties pertaining to report deployment globally. This way, the individual project properties would simply provide over-rides to the default settings and dramatically ease the burden of visiting and resetting these properties one-at-a-time.
• Next, the Project property setter dialog needs to be re-written. It’s using the same dialog that was unsuitable 10 years ago. As it is, the dialog does not let one inspect the (rather long) property settings without hovering over each or dragging the column wider. Given that when using SharePoint integration almost all of the properties have the same preamble, all of the important details are pushed out of sight. Folks it’s about time this was fixed. This dialog cannot be made larger and does not remember the customization settings made on each visit.
• This same property dialog needs to be cognizant that the default configuration for SQL Server uses named instances. That is, each time the ReportServer is referenced in native mode it needs to have the correct instance name appended to the end. The help tips (and topics) need to be corrected to reflect this reality.
• I really like the concept of a “shared” dataset. This makes sense on a number of planes and I’m looking forward to adding to my courseware. I’m still working out the logistics and at this point it’s not intuitive how one can leverage an existing Shared Dataset in a Report Wizard. The documentation here is very “Report Builder” focused. I would like to see more emphasis placed on the BI tools in this regard—a walkthrough that shows how to leverage an existing (cataloged) or existing (project-based) shared dataset would be in order.
• I’ve always advocated use of Shared Data Sources but for some reason (that I don’t agree with) the team tells me that they cannot populate the list of shared data sources from the catalog to help developers choose the right DS when creating new projects. As it is, they must manually look these up and make sure the name they choose matches the cataloged name. Of course, this already works in Report Builder.
• Aug 2, 2010: If I need to build a large Reporting Services BI solution, I think it would be interesting to also have a “Solution”-based set of Shared Data Sources, Shared Data Sets and Shared Report Parts. I encourage the RS BI developers to think bigger—about solutions that mange larger sets of reports.
• I also don’t think it’s necessarily a good idea to redeploy reports that are unchanged. I notice that unchanged reports are bypassed (not recompiled) but they are still deployed. That is, if the version on the server is the same as that on the development system, it should not be redeployed. This bumps the “changed” date even though nothing has changed. This means the BI tools need to be smarter about deploying unchanged reports.

More later…