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.

Bugle

Hi, how did you ended up with this, I am trying to do something similar but I must need to provide tenantId in code behind otherwise will be at risk of leaking secured data to authenticated but wrong clients, any thoughts ? thanks – Dame

Answer 1

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.

Toreutics

Just to clarify: the form that issues the HTTP POST simply targets an iframe? Were there any resources that helped you figure that out (books, docs, etc)? I thought the SSRS Web Service layer was the more "standard" way of generating reports from a custom app, as opposed to HTTP POST. Interesting to know this trick. – Bugle

Here's the MSDN article on accessing reports via URL parameters - msdn.microsoft.com/en-us/library/ms155391.aspx The reason we ended up doing a HTTP POST (same commands apply) was to avoid issues with lots of selected parameters and the 1024(?) URL length limit. I just double checked and our form is in another hidden frame, so targets it's own frame, we just resize the frames when posting the form. We use the web services to get the list of reports available for the user, and use the native report viewer to display the report. The user can then interact normally with it. – Toreutics

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.

Devault

Answer 3

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...

Joly

Was this UI relatively static? I.e., were the input controls "hard coded" or created dynamically based on the parameters of the report? Curious... – Bugle

Each report had its own set of input controls (some reports require more criteria than others). So what we did was created a custom control that managed all of the communication between each of the custom aspx pages and SSRS. This way, all that was necessary to create a report was the definition of the inputs, the collection of the input data and the passing of this data into our custom Reporting Services Control. Each of our reports was a new aspx page with its own set of input controls. Some input controls were shown/hidden depending on the users' access rights and configuration. – Joly

Answer 4

An alternative way of creating a branded look on SSRS if you don't want to use ASP.Net. Use a sub report as header and have the navigation between reports there.

http://mybinote.blogspot.se/2012/03/branding-ssrs-and-make-it-look-like.html

Ani