About integrating Reporting Services into your application (for beginners)

In order to integrate Reporting Services into your Web Application you have the following options: using the Reporting Services SOAP API (consuming the Reporting Services web service), using the ReportViewer control and using URL Access (Integrating Reporting Services into Applications - https://technet.microsoft.com/en-us/library/ms153697(SQL.90).aspx ).

Also, a very good resource about the subject can be found here: Integrating Reporting Services into Your Application - https://msdn.microsoft.com/en-us/library/aa964126.aspx

a) The URL Access is the simplest method because all it does is to call the report directly on the ReportViewer control installed by default on the ReportServer IIS application. The report is called from a web browser (Internet Explorer) by requesting the path to the report that is deployed on the server. This method doesn't allow us to control in any way the way the report is displayed in the ReportViewer control, because it actually uses just the browser to request the report. It's the same thing as if we would try opening in IE a connection to https://servername/ReportServer and executing a report directly there. With this option, we cannot really talk about integration. At maximum, our application could contain links to those reports we need to execute and if clicked would either start a new browser with the report requested or would open the report inside an IFrame in our web application. (Using URL Access in a Web Application - https://technet.microsoft.com/en-us/library/ms153563(SQL.90).aspx )

b) Consuming the web service of Reporting Services (using the SOAP API) would give you the most freedom but would also require the most amount of investment into the development of the solution. Basically, you would just call the methods exposed by the web service of Reporting Services and handle the responses in any way you choose. For example, by calling inside your application the Render method of Reporting services web service, would give you, depending on the format chosen for the Rendering (HTML, PDF, EXCEL - the format is chosen as a parameter when we call the method) the executed report that you can handle at will - you could display it inside a control, you could save it somewhere, export it, store it. You could call the methods of the SSRS web service through a proxy class, so you would have an object model available for managing reporting (Building Applications Using the Web Service and the .NET Framework - https://technet.microsoft.com/en-us/library/ms154699(SQL.90).aspx  ).

(Using the SOAP API in a Web Application - https://technet.microsoft.com/en-us/library/ms155376(SQL.90).aspx )

Actually, "the Reporting Services Web service is the primary interface for developing against Reporting Services. Whether you are developing code to manage your report catalog or developing code to render reports to a supported format, the Web Service exposes all the necessary methods to integrate Reporting Services into you applications. An example of one such application is Report Manager, which ships with Reporting Services; it uses the Web Service for managing the report catalog." (https://technet.microsoft.com/en-us/library/ms153697(SQL.90).aspx )

c) Another way of integrating Reporting Services into your web application would be using the ReportViewer control inside your ASP.NET web application. You could configure programmatically the reportViewer control to display a report of your choice or even connect to different Reporting Services instances to render different reports. For example, you could use a combination of SOAP access and ReportViewer access like this: using a proxy class to access the Web service of SSRS, you could call the ListChildren methodto obtain the reports that are on the server and display them inside a list control and then, after selecting a report for rendering, you could display it in a reportViewer control. (Integrating Reporting Services Using the ReportViewer Controls - https://technet.microsoft.com/en-us/library/aa337090(SQL.90).aspx )

In all these scenarios, the way Reporting Services is designed to work, involves having reports (RDL files - report definitions) deployed on the Report Server and Data Source definitions either embedded into the reports or as standalone items that can be shared by multiple reports (we could have one datasource for more reports if they use the same connection string information).

A concern with this could be that the security would have to be managed separately. This should actually not be a concern if you are using Windows Integrated Security. Through role-based security mapped to Active Directory security groups, the management of security would be quite straightforward. (Managing Permissions and Security for Reporting Services - https://msdn.microsoft.com/en-us/library/ms156014(SQL.90).aspx )

Someone asked me once if it would be possible to deploy the report at runtime and somehow; don't have the reports previously stored on the server but just use a definition (RDL) we have at a given time to display data. The answer is yes, it is possible, but I don't think that this is a good solution because of a number of reasons. This would be possible if you take a report definition (RDL) at runtime and try to use it to render a report you would have to deploy it programmatically on the server - using the SOAP API - and render it immediately after. But this means having to perform two operations at once and therefore might run into performance issues. The second issue is that you won't get a chance to verify that the deployment was ok. Also, to deploy a report you need special permissions, more elevated permissions than those of a simple user and report browser. (https://search.live.com/results.aspx?q=deploy+reports+programatically+%22reporting+services%22&form=QBRE )

In local processing, the Reporting Services processing and rendering engine is not used at all. You don't need to have Reporting Services configured and don't need an SSRS instance at all for local report processing. All we can have in local report processing is capability to use the Report Viewer to display a set of data that is ready to be plugged into the control. Basically, information about parameters, data source, data sets, is not available at all. All we do is use the control and the Reporting Services Data Regions (Charts, Tables, Matrices) to display some data. The full Reporting Services processing and rendering engine can only be used in server processing mode. "Local processing mode provides an alternative method for viewing and rendering reports when Reporting Services is not installed. Unlike remote processing only a subset of the functionality provided by the report server is available in the control. In local mode, data processing is not handled by the control but rather implemented by the hosting application. However rendering of the report is handled by the control and processed on the client where the control is hosted. In local mode, only the PDF, Excel, and Image rendering extensions are available." (Configuring ReportViewer for Local Processing - https://msdn.microsoft.com/en-us/library/ms251704.aspx ; Reporting Services and ReportViewer Controls in Visual Studio - https://technet.microsoft.com/en-us/library/ms345248(SQL.90).aspx )

Concerning Local Processing, SQL Server 2008 behaves the same way, but instead brings great improvement in server processing and rendering - (https://blogs.msdn.com/robertbruckner/archive/2008/08/11/on-demand-report-processing-in-rs-2008.aspx ; What's New in Report Processing and Rendering - https://technet.microsoft.com/en-us/library/bb630400.aspx )

Comments

• Anonymous
  February 05, 2012
  Thanks for the post. Here’s a tool to use to create and publish your report online in minutes, without coding. You can create different graphs and layouts www.caspio.com/.../reports.aspx