SQL Server 2000 Reporting Services is one of the most exciting additions to SQL Server-related technologies in the past 2 years. Although Reporting Services began as a new feature of SQL Server 2005, its capabilities and potential generated so much interest in the community that Microsoft made it available with SQL Server 2000 as a stand-alone release.
Reporting Services exposes a Web service interface that makes it easy to integrate report management, report viewing, and report rendering into your custom applications. I show you how to programmatically retrieve and populate report parameters in code and how to generate and save reports in different export formats. Learn how to use these concepts, and you'll soon be including report generation in your own applications.
Which API to Use
Reporting Services is a rich and powerful reporting platform that provides multiple ways to view, export, and deliver reports.You can use the Report Manager application that's included with Reporting Services, or you can use one of the two available APIs: URL Access or the Reporting Services Web service (also referred to as the Simple Object Access Protocol—SOAP—API).These APIs give you easy, flexible ways to include reports in your custom applications.
Using URL Access, you can request a report over HTTP by specifying the report URL in a Web browser or in a browser control. For example, the URL http://server/ Reports/Pages/Report.aspx?ItemPath=%2f SampleReports%2fCompany+Sales accesses a report called Company Sales located in the SampleReports subfolder.
The SOAP API provides much more than report navigation and viewing. This API provides full programmability over Reporting Services, letting you program all aspects of report management, including administration, deployment, and report subscription control.
Each API has its proper place and its own advantages and disadvantages. Use URL Access when you need to provide only report navigation and report viewing in Web applications. Report rendering is faster through URL Access, and unlike the SOAP API, it renders the report toolbar in HTML reports.
Use the SOAP API when you need to provide additional management capabilities and when URL Access is not desirable for viewing reports. For example, avoid using URL Access when you don't want to expose your Report Server over the Internet; instead, expose a facade that generates reports by calling a back-end Report Server and then passes the reports to calling applications. Use the SOAP API when you want to automate report generation, create a tool for easily exporting reports into multiple output formats, or automatically archive reports.
Now let's get down to the basics of how to program Reporting Services using the SOAP API. I show you how to render reports, manipulate report parameters, and save generated reports in various export formats.
To make things easy, I provide a demo application called Report Generator, including the source code in C#, which you can download. To run the demo application, you must first install the Reporting Services samples and the AdventureWorks database. The sidebar "Installing the Sample Reports and Setting Up the Demo Application" (page 40) provides details about installing the samples and configuring the application to use the Employee Sales Summary report, one of the sample reports Microsoft provides with Reporting Services.
Figure 1 shows the Report Generator window that results when the demo application retrieves report parameters from a Report Server Web service and presents them on the screen using selected list boxes. You can select multiple parameters and multiple export formats. When you click Render, the application loops through your selections, calls the Report Server rendering engine with each combination of selected parameters and export formats, and saves the rendered reports in the specified folder.
Using the SOAP API
Because the SOAP API is a Web service, you can use any programming environment that can call a Web service. Most likely, you'll choose to use Visual Studio .NET, so that's the programming environment I discuss here. You can use the SOAP API in any type of Visual Studio project—a Windows,Web, or console application.
First, in the Visual Studio project, create a Web reference to your Report Server Web service. In Solution Explorer, right-click References and select Add Web Reference. You can search for Web services on your computer, or you can specify the URL of a remote Web service. In the Report Server Web service, refer to the ReportServer.asmx page so that your Web reference has the format http://YourReportServerName/ReportServer/ ReportService.asmx.
To create a more descriptive name for the Web service object, you can change the default value in the Web Reference Name text box. When you click Add Reference, Visual Studio generates a proxy file for accessing the Web service. This proxy file contains an interface for all methods defined in the referenced Web service. The proxy file also contains a Web service property called Url that contains the HTTP address of the Web service. When Visual Studio generates the proxy file, it sets the value to the URL of the referenced Web service. You can change the Url value at runtime and point it to a specific Report Server. It's good practice to read the value of Url from the App.Config file when the application loads instead of hard-coding the value, as the following example shows:
rs.Url = ConfigurationSettings
.AppSettings["RsUrl"];
Using this approach, you don't need to recompile your application when you deploy it or when you need to point it to a different Report Server. After you add a reference to a Report Server, you can simply call the SOAP API to use whatever functionality you need in your application. Listing 1 shows a sample call to the Web service to generate a list of all reports available on that Report Server. Notice that before you can use any functionality, your code must establish credentials on the server. The code at callout A in Listing 1 uses the DefaultCredentials object, which means that the application runs in the security context of the user running the application. Alternatively, you can use the NetworkCredential class to run under the security context of a specific user:
rs.Credentials = new
NetworkCredential(UserName,
Password, Domain);
If you choose the network credential approach, ensure greater security for your application by encrypting the username and password before using them. To learn more about the methods and properties exposed by the SOAP API, I encourage you to read the Reporting Services Programming section of the Reporting Services Books Online (RS BOL) at http://msdn.microsoft.com/library /default.asp?url=/library/en-us/rsprog/htm/ rsp_prog_intro_1pia.asp.
Report Rendering
Now that you've seen the basics of using the SOAP API, let's move on to report rendering.The Reporting Services class in the SOAP API exposes the Render() method, which takes a multitude of parameters and returns a rendered report in the form of a byte array. I cover the most important parameters and mention a few things that you should be aware of when using the Render() method. Discussing all the parameters and details of this method would be lengthy and beyond the scope of this article, so I suggest that you read about it in RS BOL, too. The documentation for the ReportingService.Render method appears in the Reporting Services Programming section of RS BOL, at http://msdn.microsoft.com/library/default .asp?url=/library/en-us/rsprog/htm/rsp_ref _soapapi_service_lz_6x0z.asp.
Prev. page
[1]
2
3
next page 
