So, you built your shiny and flashy SSRS report, and you hit “Deploy” in BIDS, or “SQL Server Data Tools” in newer versions. Your UAT is a breeze, and everything looks great. The million dollar question now becomes
How do you deploy your reports to production?
In most “enterprise” environments “production” means “no direct access for developers”. Any changes to production must be carefully documented and performed by dedicated people: release managers, system administrators, DBAs, etc. These dedicated people typically do not have BIDS on their desktops, nor do they want to. Thus, simply telling them to open the project, right click and hit “Deploy” won’t work. Whatever BIDS does when you hit “Deploy”, you’ll need to duplicate it in some way that works without BIDS. This is easier said than done, because, as it turns out, “Deploy” does quite a few things under the covers.
Scripting SSRS
But first off, how do you script SSRS in the first place? It comes with the rs.exe utility which on my machine is located at "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\rs.exe" (your location may vary), and is described on this MSDN page.
The “script” file that rs.exe accepts is regular VB.NET code that can call methods on a global rs object, which is actually a proxy to SSRS web service. You can put any valid VB.NET statements in your script, including reading files, opening sockets, and the like.
WSDL definition for the SSRS web service is located at
http://reportServerName/ReportServer/ReportService2005.asmx?wsdl for 2005 version of the protocol, or at
http://reportServerName/ReportServer/ReportService2010.asmx?wsdl for 2010 version.
In fact, all rs.exe does is:
- Download WSDL from reporting server
- Create a proxy class (perhaps using svcutil)
- Read your script
- Surround it with some extra code that defines the rs variable
- Compile and run
These steps are executed on every invocation of a script, and may take quite some time. Another limitation is that you must use VB.NET, C# is not supported. Also, you can’t have any Imports directives in your code, because it gets surrounded by the code generated by rs, and Imports in the middle of a class are not allowed. So, if you use classes like System.Xml.XmlDocument, they must be fully qualified.
If any of the above is an issue, you may want to bypass rs.exe and generate the proxy on your own. Simply create a console application and add a web reference to ReportServiceXXXX.asmx?wsdl. Your “script” will now be an executable file. The downside is that you lose dynamic compilation: quickly modifying the script “on the fly” is no longer an option.
But what exactly do you put in the script? This is going to be the topic of Part 2.
Permalink