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