Integrating Reporting Services into Custom Applications - Professional SQL Server 2005 Reporting Services - page 501

❑ Link to a report in web browser window using a URL rendering request.

❑ Replace web page content with a report by using SOAP rendering to write binary content to the

web Response object.

❑ Use SOAP rendering to write report content to a file.

❑ Embed a report in an area of a web page by setting the source of a frame or IFrame tag.

❑ Use the ReportViewer control in a Windows form or Web form application.

Rendering using a URL is very handy and easy to implement in many situations, but it does have its limi-
tations. When rendering from the URL, you have to make sure that you use the security infrastructure
provided with Reporting Services. For some applications, such as public web sites, you might want to
implement your own security. In that case, rendering from the URL will not provide the functionality you
need. In this section, you will take a look at rendering reports using the Reporting Services Web service.

You'll connect to the Reporting Services Web service, return a list of available reports, retrieve their
parameters, and finally render the report. Let's take a look at three implementations of programmatic
rendering. The first implementation is using a Windows form to render reports to a file. This will help
you to understand the basic principles without a lot of interface work. The second implementation will
take you through rendering through an ASP.NET page. You'll see some of the items that need to be con-
sidered when working through a web application. Last, you'll read about the ReportViewer controls
embed reports in a Windows application using one.

Common Scenarios
Before you look at the actual programming code for rendering reports, it is important to understand a
couple of scenarios where it is reasonable to do so. There are two scenarios that are commonly experi-
enced while working with clients. They do not represent the only scenarios where you would write your
own rendering code but do illustrate how and when custom code can be used. Let's look at each of these
scenarios.

Custom Security
Probably the biggest question I get when working with clients is How do I use Reporting Services if I
don't want to implement their security infrastructure? Reporting Services requires you to connect to
reports using a Windows identity. In many organizations, this is just not possible. They have mixed envi-
ronments or nontrusted domains that do not allow for identification to the Report Server. Some clients
also have large-scale authentication and authorization infrastructures already implemented.

You can still use Reporting Services in these situations. Using your own security infrastructure involves
creating both authentication and authorization code in your environment. After you have determined
that a user can access a report, a Windows identity that you define can be used to connect to reports. To
hide this security implementation, the Reporting Services Web service can be employed. You can render
reports directly to a browser or file without passing the original user identity to the Report Server.