SSRS export to PDF automatically from standard, built-in interface

Question

Our organization has many custom SSRS reports that we run from SSRS's built-in interface - where a user can see and set the parameters and click 'View Report' to generate the default HTML rendering. Then the little toolbar appears allowing them to export the report to PDF, Excel, etc.

I know that many organizations write their own report generation interfaces, which then pass the parameters to SSRS and return the report in the desired format. Before we explore that route, we would like to see what we can do by 'hacking' the built-in interface.

The advantages of sticking with SSRS's built-in interface, is that we can write reports that have parameters whose values/selections are generated depending on previously selected parameters. For instance, if I have two report parameters - 'School Year' and 'School Name', I can make the drop-down selection list for 'School Name' change depending on what the user selects for the first parameter of 'School Year'; and I can do this inside of SSRS without hiring a programmer to code a custom report selection/generation interface.

But what I can't do is automate - from with the standard interface - the export of a report to PDF after the user selects the parameters and clicks 'View Report.' But some posts I have come across today lead me to believe that we might be able to hack the standard SSRS interface by editing the 'ReportViewer.apsx' file on the SSRS server.

Click here for an example of hacking this file to add extra functionality to the 'View Report' button.

So, all you javascript gurus out there, can you figure out a way to hack SSRS's built in 'View Report' button so that the parameters are submitted and a PDF format report is returned automatically? (If jQuery would help, we can add a reference for it).

Answer 1

What I am about to say to you will undoubtedly not be the answer you're wanting, but I think it may be the answer you need to hear. What you're requesting someone help you do is really not a best practice, for many reasons. Here are a few:

1. If you find a way to adapt the SSRS config and source files (e.g., ReportViewer.aspx), such a change would alter the way any and all reports on the entire report server are generated. For instance, you would never be able to generate a report in MHTML format with dynamic parameters using the SSRS interface.

2. The ReportViewer.aspx page is currently not setup to display a PDF. To obtain a PDF, you must use the export functionality in the SSRS toolbar or use the rs:Format parameter, both of which will download a PDF report.

3. You say you don't want to hire a programmer to build a custom interface, but what you instead want to do is hack the core files of the SSRS application. This seems like a fairly bad practice if you don't have the development staff to maintain the changes and handle any unexpected problems that arise.

I'm guessing that at this point I've either got your attention or you've already downvoted my answer, so here are some alternative solutions that don't require hacking SSRS.

Provide Users with Links to Open Reports in the Desired Format It is entirely possible to build reports that utilize SSRS parameters and provide the user with links which will generate a file in any format specified, all by just clicking on a link. For instance, all of our Dashboards have a "Print this page" link which generates a PDF with all the relevant report parameters passed through.

One specific example: we have dashboards for our staff that will show top X records based on some business need and then provide a link at the bottom of that section to a report which contains all records in a PDF in a printable format. The PDF carries any parameter values already entered on the Dashboard into the PDF report, streamlining the user experience.

Additionally, you can build and customize what I call "Portal reports" to be loaded from the minimal amount of data to minimize loading time. To me, "Portal reports" provide users with a small amount of relevant information based on parameter values from upstream reports or from report parameters in the portal report. Then, links are provided to allow a user to generate a file containing a specific set of data in whatever format they need. Below is a screenshot of a simplified example I used to make something for my boss. It reads the current system time and generates different reports available in the formats either needed or wanted with the click of a button. Believe it or not, the page you see below as well as all the datasets generates by the links are all part of one report.

Additionally, you can control what kinds of files users export to by controlling what SSRS toolbar options a user sees. You can change the default StyleSheet or provide your own custom StyleSheets using the rc:StyleSheet to disable the print button (which rarely works nowadays anyway) or the export or find features of the SSRS toolbar. Here's a technet link on how to accomplish this.

Finally, if you have JavaScript know-how and some vb.net or c#.net expertise, you can handle specialized situations with a webpage that queries a minimal amount of data from your system(s) and gives the user dropdowns followed by a link to generate the report as whatever format you wish. These project-oriented, one-off web pages are much easier to build than a fully-flexible .NET SSRS interface.

If you have any questions about any of my statements, please reply with a comment. I'll do my best to answer your questions.