Reporting Services—Team Development

| No TrackBacks

Just thinking aloud here. So, let’s say you have a team of report developers and you find that more than one report needs to access a common set of routines.

In the first scenario, let’s assume that this expression (while complex) does not change that much over time. As I see it, Microsoft expects every developer to manually locate, copy and paste this code into their report properties. Because the expression does not change, it’s just a matter of tediously pasting in the code and hooking up the parameters (if any). IMHO, I think it would be nice if the code property could be automatically loaded from a file in the BI project.

However, in the second scenario where the code is subject to change, this cut-copy-paste scenario gets tedious (and dangerous) as each report must be revisited, edited by hand and recompiled, tested and redeployed. This might take hours to weeks to accomplish if there are a lot of reports and the chances for errors or omissions are manifest. IMHO there should be a mechanism to permit a single change to a single VB file in the BI project that would be automatically incorporated into all reports in the project upon request. This concept of a set of global project properties and the ability to apply these values to a set of reports in a solution is new but sorely needed. This same concept could apply to re-directing deploying reports, share datasets, share report parts or data sources to different servers or folders by simply changing a global variable.

For this shared code that changes scenario I recommend putting the code into a DLL that’s accessible not only at design/preview time in the BI tools or in a VS ReportViewer project but at runtime where the sever-hosted report processor can find it. The problem here is that the mechanisms to do this are not at all clear and not automated. I think it would be great if VS BI project DLLs could be automatically deployed to the correct Reporting Services bin folder and properly registered (as required).

In summary, As MS has implemented in the 2008 R2, the concept of shared datasets is intriguing. This gives developers the ability to create a commonly required rowset to be leveraged by any number of reports. Not only that, they’ve implemented shared report parts which lets a report developer construct a customized report control for reuse by several reports. That’s cool, but what if there was a commonly accessible set of code snippets that could be centrally managed and easily incorporated into reports? This way the developer would simply include the common code parts into their new reports to incorporate these blocks of Visual Basic code in every report. Since they are centrally managed, changes made to the host would be propagated to the reports leveraging the code.

Technorati Tags: ,

No TrackBacks

TrackBack URL: http://betav.com/blogadmin/mt-tb.cgi/2434

Pages

Powered by Movable Type 4.21-en

About this Entry

This page contains a single entry by William Vaughn published on September 2, 2010 11:24 AM.

I’m Done with SharePoint was the previous entry in this blog.

Free Software for the Un/Under Employed is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.