SSRS with Custom Web UI

Question

Is it possible to create a custom Web front-end to run SSRS reports from?

We have an existing cross-browser web front-end for gathering reporting inputs (for a non-SSRS platform) that we would like to see continue with SSRS instead. It includes domain-specific UI controls that have been developed in-house already, and nothing comes close OOTB with SSRS.

We don't need to do dynamic rendering of type-aware controls - although I imagine the RDL can help tell us what parameters (and their type) the report takes - but we do need more than what Report Manager gives us.

Essentially we would like to customize/replace the input-gathering UI generated by Report Manager. We also need some modicum of branding. Would it be easier to scrap Report manager altogether (externally I mean) and interface directly with the SSRS Web Service via our own ASP.NET application?

I am new to the reporting terrain, and I cannot find any information on this. We are using SQL Server 2005 Reporting Services.

Answer 1

What we've done is built a UI to gather criteria and format (PDF, XLS, etc.) data and used the SSRS Web Services to fire the reports.

It allowed us to do exactly what you're talking about with respect to using your own UI & branding around the reports.

You essentially pass the RDL name and a collection of report parameters to the webservice and it'll return the HTML (or whatever format you specify).

Some gotchas include having to re-write URLs when you use SSRS's column sorting, and having to set your own mime types if you want to support PDF/Doc/XLS/etc...

Answer 2

If I understand you correctly, you'll want to use ReportViewer to render the reports.

You can implement the input gathering in anyway, and then simply pass the inputs to the reports as parameters:

//the report classes are in the namespace: Microsoft.Reporting.WebForms
Collection<ReportParameter> paramList = new Collection<ReportParameter>();
string reportPath = ApplicationInfo.ScorecardReportPath;
paramList.Add(new ReportParameter("UID", "5"));

ReportViewer1.ProcessingMode = ProcessingMode.Remote;
ReportViewer1.ServerReport.ReportServerUrl = new Uri("http://servername/ReportServer");
ReportViewer1.ServerReport.ReportPath = reportPath;
ReportViewer1.ServerReport.SetParameters(paramList);
ReportViewer1.ServerReport.Refresh();

The ReportViewer is a control you can drop onto your page:

<rsweb:ReportViewer id="ReportViewer1" runat="server" documentmapwidth="175px" 
font-names="Verdana" font-size="8pt" promptareacollapsed="true" width="100%"
zoommode="Percent" zoompercent="100"/>

I've used this approach to nest the reportviewer inside a page contained in a master page. It allows the menu/header/footer to be displayed.

Answer 3

Yes it is possible. We implemented a solution similar to this over 2 years ago when we were dissastified with the parameter selection that came OOTB.

Essentially we have a custom ASP.NET application that users interact with. When the first page loads it presents a list of reports available for that user (communication from the ASP.NET app to SSRS via web services and with identity impersonation so that the list is security trimmed). You'll need to use Kerberos here if the custom ASP.NET app is on a different server to the Report Server.

After the user selects a report the parameter selection screen is shown (still in the custom ASP.NET app). When they select their parameters and click 'Generate Report', some JavaScript adds input tags for each parameter to a HTML Form on the fly (hidden from the user) and then performs a HTTP POST to the SSRS web server.

We are then using the OOTB report viewer to display the report, however it is hosted in frame so that the top of the screen allows the user to be contained to the custom web app. This allows them to quickly go back and change the parameters.

We took this approach because we have a global organisation, but our app was centrally hosted - we wanted performance to be as good as possible for all users. What we found was that the Report Viewer was pretty good performance wise, but that the OOTB Parameter Selection that came OOTB was terrible for connections with high latency - lots of postbacks and far too much traffic transmitted.

One other trick - we made the parameters 'hidden' in the report so that the parameters were not shown in the Report Viewer.

Edit: We intitially did with this with SSRS 2005 and have recently upgraded to SSRS 2008 with minimal hassles.

Answer 4

Are there any custom UI interfaces available commecerially or otherwise? W