Speaking the language of business intelligence with an Australian accent

Showing posts with label Report Builder. Show all posts
Showing posts with label Report Builder. Show all posts

Friday, June 30, 2006

SSRS - End user report builders.Worth it?

My recent unwanted comment spam has reminded me to materialise some thoughts that have been in the back of my mind for a while now.

It's been interesting to watch in recent years the attempts to come up with a good way for end users to build their own reports without the need for SQL skills or a Visual Studio license; a valiant quest but nonetheless a difficult one. Around the time of the initial RS2000 release several development shops raced to come up with a something that MS would (hopefully) buy and then incorporate into the Yukon product. The successful company was Active Views and their product eventually became what we now know as Report Builder. As far as I am aware Active Views' main pre-Yukon competition was Cizer.

The initial gripe many had with RS2000 was that we had to have a VS2003 license in order to design reports. This was because of RS' early completion date and MS' decision to get it to market prior to releasing Yukon, hence the need to retro-fit report development into VS2003. Enter Cizer and Active Views et al. A big part of the value proposition was "you don't need to buy Visual Studio 2003 to build reports! All you have to do is buy our product" ;) Now that the Visual Studio shell (for BIDS) is shipped with the SQL Server 2005 license some of the shine has come off this proposition (if it was indeed that shiny in the first place).

Now, don't get me wrong, I think the concept of users building their own reports is great, as long as the users actually build reports (and then use them). Maybe I have been working for the wrong clients but I've rarely (if ever) encountered a company that employs any/enough so-called power users with adequate skills and enthusiasm coupled with complete lack of SQL skills to justify the purchase of one of these apps to build simple reports. Either you're a geek or you're not, this is rarely much in between.

As report developers we have all seen endless demos of SSRS in both the 2000 and 2005 incantations, and possibly demos of varying flavours of end user report builders. All report demos are supposed to be simple and easy, we all know that - it's part of the sales process. Then we cross the reality gap as we walk back into the office. When did you last build a production SSRS report whose requirements were so simple it could be built in under 5 minutes using drag & drop only? When was the last SSRS report you built that did not contain even just a liiittle bit of complexity that the user just had to have? Not many right? I'm sure there may have been a few, but not many. Remember that the "little bit of complexity" may be something easy to a developer (say, a variable or some simple string manipulation) but to our power user it may be something they just can't (or don't want to) get their heads around. Default reaction: "Call IT!"

The power users who fit the non-SQL skilled, but tech-savvy enough to build useful reports are, IMHO, few and far between and rarely enough in number to justify buying another product on top of the original SQL Server license for writing simple reports. Remember, you get Report Builder included in said license, and it's a pretty good product (esp. when you consider the price). RB's use of a semantic data model which, if well designed and maintained, can be a useful reporting platform even for experienced developers. I know the other products have all sorts of funky bells & whistles that make for impressive demos, but in the end are they really going to get used properly? Like all of the other bundled SQL Server components, why not try to make use of Report Builder? It doesn't matter if you don't use it, you haven't paid anything extra for it. This is not to say "Report Builder is the best", it is one of several options, but it is easily the cheapest and most accessible. Regardless of what you think of RB - some love it others don't - it's certainly worth seeing how good your organisation's uptake of this kind of functionality is before shelling out $ for a piece of potential BI shelfware. Now, by shelfware I am not maligning the various products that are out there, just that BI products (no matter how good) are renowned for being quickly forgotten once the initial sales presentation hype has died down and business reality sets in.

Nonetheless I'm sure there must be some companies out there who are making good use of their end user driven report building tools. Who are they? Am I completely alone in my opinion here? Are the products actually being used to build reports or are they more useful for the report portal-type functionality many of them inherently provide?

Interested to hear what anyone thinks about this.

Saturday, October 29, 2005

SSRS - Report Models as a data source in Designer

At a recent user group meeting in Sydney MS Evangelist Dave Lean reminded us that developers don't need to use the Report Builder app to create reports off report models. Just create a connection to the report model you have deployed (or generated) on the report server. In the data tab of designer you'll get a drag & drop interface which closely follows the RB experience (including the very intuitive filter functionality). So now, because we're working in Designer, we can build multiple result sets off the same model and include them on the one report just as we would with any other data source. Very cool.

Here's a post by Russel Christopher on how to create the model connection.

Sunday, October 9, 2005

SSRB - SSAS Report Models

Recently two of my colleagues asked me if it was possible to give users access to SSAS cubes via Report Builder (SSRB). My answer was an immediate no. I had always thought that report models had to be built in BIDS (Business Intelligence Development Studio) and be based on a DSV which we must first create. Because we're basing the model on a DSV we then can't take advantage of all the dimensions, perspectives, KPIs etc.etc. created through the cube designer. I have since discovered that I was wrong, completely wrong. We can generate (and regenerate) a Report Model based on an SSAS cube.

SSAS-based report models can be created using "Generate Model" either in Report Manager or in Management Studio (when connected to the Report Server). Generate Model is a function exposed on data sources which have been deployed to the Report Server. Both relational and SSAS models can be generated this way.

In Management Studio right-click the data source and select "Generate Model"


... or in IE through Report Manager. Go to the properties of a data source and you will find the Generate Model button at the bottom of the screen.











The resultant SSAS report model contains structures based on dimensional relationships to measure groups as well as perspectives defined in the source cube. Even KPIs (and access to their display images) are included in the model. One thing that we do not get, however, are structures which mimic the attribute hierarchies. Nonetheless the attributes that make up the hierarchies are all there.













Does the newly generated model interrogate the OLAP cube on which it was based, not just simply back to the original base DSV? A quick Profiler trace while using the model in Report Builder proves that MDX is being generated and sent to the Analysis Server - no relational queries.

If the cube structure ever changes on the server just hit the "Regenerate Model" button on the properties page of the model in Report Manager or "Update Model" in Management Studio. This will bring the model back into synch.

Friday, September 23, 2005

SSRB - Where'd my report go?!

There is a good Report Builder GROK talk by Richard Hundhausen available here.

This has been available for a while now but, now that I have a blog, I really wanted to write about it. Soon after this GROK was available in late June I saw a several blog posts saying that RB had a problem/bug/issue during the demo. This is incorrect. RB does exactly what it is designed to do. Watch the video and keep a close eye on where Richard saves his "Contact Report" (at around 7 min 55 secs). He does something we have all done several times in our working lives: inadvertently saved a file to a root directory (in this case "Report Server Home") and then had difficulty finding it again. When he switches back and refreshes Report Manager the newly-created Contact Report can be seen sitting innocently in the Home folder while he looks for it in the other sub-folders. I'm sure when he reviewed the video he stifled a quiet "d'oh!".

Don't worry Richard, I sympathise! ...and I agree: developers hate users :)