Nixing the Report Manager

Doug W comments/asks:

You speak to not recommending the use of the report manager as an end-user interface, but could you enumerate those reasons?

… and I hoped to write back with information last weekend or earlier, but work got in the way.  Also it’s a bigger subject than I originally thought it would be.

Before I tackle it here, I just gotta show you guys something I saw for the first time last week while working in the Report Designer in Visual Studio:

 

 

Can you believe that one? Loved it.

Clearly, they’re out of ideas occasionally.
Luckily, we’re not stuck with it.

 
And that, my friends, in a nutshell (although I have every intention of elaborating in a moment), is why I often recommend against exposing Report Manager to end users: it’s not good enough, but it doesn’t have to be.

Whether we’re talking about Report Manager or Report Designer, the product we’re really interested in is Reporting Services. 

It’s an open system.

Report Designer is just a fancy way of creating report descriptions (RDL files).  While I don’t often talk about replacing it, you can use anything that creates XML if you prefer.  There are a number of people who have written generating programs to do this, and I sometimes just do it in whatever XML editor I have at hand.  At least one or two alternative GUI interfaces also exist.  Check out http://www.fyireporting.com/ for an open source project that implements the RDL specification, and includes its own WYSIWYG designer.

Creating your own RDL implementation on the Report Designer side is a non-trivial exercise, and not necessary for everybody.  By contrast, I would argue that Report Manager was designed from the get-go to be replaced.

Having some experience on the “other side of the fence”, I can even imagine the conversations that took place on the Microsoft dev team. 

Dev would have designed the architecture for SSRS, how it would store, render, and serve reports, first, complete with a SOAP API so that client software could invoke all its services. I’m sure they created some little test bed to exercise the SOAP API as they began to flesh out each internal service.

Meanwhile Product Management was scratching their heads over SSRS and saying “how are we going to get across this new, big idea? Where’s the easy-to-use way of dealing with this thing?” 

Obviously I don’t know the chronology but I can imagine the Devs shamefacedly trotting out their little test bed, their little proof-of-concept client…

…and Program Management starts shaping what they dub Report Manager, gussying it up, making sure it exposes, at least minimally every common task.

What’s wrong with this picture? The problem is, as it so often is with Microsoft efforts, that after a while everyone, both customers and even the PMs at MS, start treating the Wizard as the Product instead of a gentle introduction to the product. 

This change in emphasis can be frustrating for the Devs.  They are focussed on creating a robust internal architecture, right? (and they should be)  

But the Devs also know they aren’t “typical customers” (they’re told this once every three milliseconds) and have to accept the realities of the market.  Dev resources are either added or they’re not; in the former case, there can be a disconnect betwen the teams, in the latter case, Devs redouble their efforts as PMs and customers continue to ask for additional core functionality as well as its exposure in the UI. 

Sometimes core functionality doesn’t make it until it can be at least minimally exposed. Sometimes core functonality makes it but exposure doesn’t happen. Either way, we do the product a disservice when we treat the Report Manager as all there is. 

The most productive and constructive way that Devs frustration comes out is in the blog posts that expose deep functionality in the product that is documented nowhere else, because User Ed either doesn’t hear about it as a priority, or hears about it too late, or is simply overwhelmed by the need to document every click in the UI.  When this happens — as it so often does — the Dev blogs come through with amazingly lucid explication of the inner beauty they worked so hard to create.

A few examples are in order.

Well… actually I’ve given you more than a few examples already, in an offhand kind of way.  Every time I tell you about a technique to roll your own, it’s because of something you can’t do by default in Report Manager.  It’s not a trick.  It’s just something that the developers always expected we would do if we needed it.

Exports

I’ve written a number of times about creating the Excel you want using XML + XSLT, instead of the Excel rendererer. Doing this through Report Manager has some obvious limitations:

• You can attach one and only one XSLT to the report definition to have it serviced by Report Manager.  This means anybody who invokes XML through Report Manager is going to get this one and only one result.  What if you want to use the XML to produce more than one Excel report, or indeed some other results that aren’t Excel at all?
• Your users have to know to use the XML Export to get their Excel, rather than the Excel Export option.  Depending on their client environment, they may also have to Save As a file with an appropriate (non-default) extension.  What’s up with that, they say?

If you write a very minimal amount of code, you can put a button in your own interface that does this work intelligently; you pick the XSLT you want, you name the file however you want, and the process is transparent to the user.  If you don’t want the user to see the default Export to Excel option — or Export at all — you can do this in your own interface.  You can’t do it in the Report Manager.

Well, I guess you could remove Export to Excel entirely from Report Manager by using the global config file.  But does that really make any sense?

Suppose you want a CSV export that’s slightly different than standard for a particular purpose.  While the default CSV renderer is configurable in theory, in practice it’s a lot easier to write your own to get exactly what you want.  And, while you could do this observing the rendering API and installing your new renderer into the default architecture, you could write a lot less code under your own button.  You could also restrict its usage to a single report, if that’s what you needed to do.

Subscriptions

I love Report Subscriptions, and I love that they are so well integrated into Reporting Services.  But I don’t love how they’re exposed in Report Manager; it’s a really klunky interface to wade through (especially the data-driven version). 

I also don’t love the part of Data-Driven Subscriptions that really isn’t Data-Driven: the subscription schedule.  As an example, I recently had a requirement to deliver a certain report by email “one week before the end of the semester”.  There is simply no way to create a subscription on this schedule based on the interface exposed in Report Manager.

But, just like everything else in Report Manager, this interface is only calling SSRS SOAP methods when it creates a subscription.  Is it really that hard to call the same methods yourself, with whatever arguments you want?  I think you know the answer to that question.

Access

While it’s technically possible (and I’ve done it) to create a custom security extension for SSRS just so you can lock down Report Manager and its individual folders exactly as you need, there is usually no good reason to do this.  Whatever complex logic your application(s) use to ensure access to individual web pages, actions, or functionality, this logic can be equally applied to report and report management functionality if you create the pages that render, configure, upload, and perform other activities on reports and report data sources or other RDL-related resources.

If you have a specific doubt or question about some Report Manager action, and how to re-imagine it appropriately for your application, please let me know what it is.

Parameters and Usability

This is probably the most important part. While I’ve talked a number of times about re-branding Report Manager so it doesn’t look horribly out of place in your application context, that’s a bandaid.  In most cases, a tighter integration with your application is going to make your users a lot more comfortable.

The most significant bit (IMHO) for raising your users’ comfort level will come when you simply hide the default parameters display and write your own.  Think about it:

• why should a boolean be displayed as two separate radio buttons rather than a checkbox?
• if you want to allow nulls for a parameter, what if the word “Null” isn’t an appropriate prompt for your users and/or your data?
• suppose you want to arrange parameters more pleasingly as a group? 
• suppose you want to have fine-grained control on parameter dependency and refreshing?

All of this is easily possible in a .NET form but impossible in the default parameter panel for ReportViewer — and therefore impossible in Report Manager.  That’s why I’ve spent some time, in various posts here, showing you how to feed parameters to a report yourself, including how you do it in SOAP, in URL-style access, from an SISX package that renders a report, by setting a property on the ReportViewer control.

I’m not going to list references to posts here; just search the blog for the word “Parameter” and you’ll find plenty.

I hope I’ve answered Doug W’s question, and I hope this gives you some ideas.

Don’t be a stranger

If you need more help, let me know. 

I do enjoy talking about this, probably because it’s a basic part of bringing report development into the fold of “normal development”, rather than leaving its nose pressed up against the window looking longingly at good practices, testability, and goshdarned deeply creative work. 

I think the Reporting Services team has done an amazing job giving us an extensible system.  Now we just have to own it.