SQL Server Reporting Services is a comprehensive, server-based solution that enables the creation, management, and delivery of both traditional, paper-oriented reports and interactive, Web-based reports. An integrated part of the Microsoft business intelligence framework, Reporting Services combines the data management capabilities of SQL Server with familiar and powerful Microsoft Office System applications to deliver real-time information to support daily operations and drive decisions.

Reporting Services provides an embeddable and extensible framework that enables customers and partners to build custom business intelligence applications. Developers can use any developer tool or platform that works with Web services. This flexibility and interoperability makes it easier to create reports that leverage packaged or custom applications in almost any environment.

While Reporting Services provides a complete set of built-in reporting functionality, its modular architecture is designed for extensibility. Server extensions are pieces of managed code that execute inside the Report Server. Reporting Services supports four types of custom extensions: output rendering, security frameworks, delivery options, and data processing types. At a more granular level, it is also possible to write custom .NET assemblies or embed custom code in a report that can be used by report expressions for custom formatting and calculated fields.

Using SQL Reporting Web Services
The Reporting Services Web service is an XML Web service with a Simple Object Access Protocol (SOAP) API. You can use the Web service to add the full functionality of Reporting Services to your business applications. The Web service interface provides a set of rendering and viewing functions. However, the Web service also provides additional functionality for managing the contents of a Report Server through an extensive set of more than 75 Web methods.

For scenarios in which the management of reports, subscriptions, schedules, data sources, and other Report Server items is a requirement, the Web service provides a single entry point to the full report-management functionality of the Report Server. It is easy to develop applications that leverage the Web service using Microsoft Visual Studio .NET or any other SOAP-enabled development tools.

To call a Web service successfully, you must know how to access the service, what operations the service supports, what parameters the service expects, and what the service returns. WSDL provides this information in an XML document that can be read or processed by a computer. WSDL can be consumed by development kits that support SOAP and Web services, such as the Microsoft .NET Framework SDK.

To access Reporting Services' WSDL file using Visual Studio .NET, use the following URL: http://server/reportserver/ReportService.asmx (where server and reportserver are the names that were used when Reporting Services was installed). Once the location of the Web service WSDL is known, just three simple steps are required to make a Web service call.

1. Create a proxy class that references the WSDL file location using WSDL.exe, or create a Web reference to the URL.
2. Authenticate the client with the report server using the credentials of an authenticated user.
3. Call the Reporting Service method you want to invoke.

Another very powerful feature of the available Web services is the ability to render a report directly to a byte array in whatever format a user chooses. This byte array can either be saved directly to a file or sent to a browser for immediate viewing. The render function is very flexible in that it allows for the passing of a parameter array that the report can use to filter the data. See Listing 2 for an example that shows how to render a parameterized report directly to PDF format and open it in Adobe Acrobat viewer.

Using Custom .NET Assemblies and Embedded Code in Report Expressions
Custom code can be written that is used in expressions throughout a report. This can be done in two ways: embedding code within a report or by referring to methods within a custom assembly. It is acceptable to use "embedded" code for complex functions or functions that are used multiple times in a single report. However, if the code will be shared across multiple reports, then a .NET assembly that is stored on the server is more appropriate.

To embed code within a report, navigate to menu Report > Report Properties and select the code tab. If you do not have a report menu showing, just click somewhere on the report in the designer and it will appear. This custom code can contain multiple methods, which must be written in Visual Basic .NET and must be instance based. Methods in embedded code are available through a globally defined code member. The functions can be accessed by referring to the code member and method name. The example shown in Figure 1 calls the method SetColorToRed, which sets the color of a textbox font to red if the value is greater than a certain limit:

=Code.SetColorToRed (Fields!StandardCost.Value, 800)

To use custom .NET assembly functions in a report, the assembly must be referenced in the report properties window on the References tab (see Figure 2). Note: For issues related to deploying, securing, and debugging custom assemblies, please see the resources section.

To refer to custom functions in an expression, a direct call to the member of a class within the assembly must be made. This can be done by either calling static or instance-based methods. Static methods within a custom assembly are available globally within the report and can be called from expressions by namespace, class, and method name. The following example refers to the method SetColorToRed in the TechArch assembly:

= TechArch.CustomFormatting.SetColorToRed (Fields!StandardCost.Value, 800)

Instance-based methods are available through a globally defined code member. These methods can be accessed by referring to the code member, and then the instance and method name. The following example calls the instance method SetColorToRed:

=Code.m_myCustomFormatting.SetColorToRed (Fields!StandardCost.Value, 800)

Custom Extensions for SQL Reporting Services
The unique extensibility architecture of Reporting Services allows for enhancements to specific features of the product and its components. For instance, data processing extensions are responsible for returning a result set based on connection information, a query, and optional parameter values. These data extensions are able to connect to legacy or custom data sources. A data extension implements a subset of the .NET Managed Data Provider interfaces. This type of extension can optionally implement a set of extended interfaces to provide additional design-time information. In addition, there are delivery, rendering, and security extensions that allow for customized report outputs, formats, devices, and security frameworks.

Deploying an extension is as straightforward as copying a .NET assembly to the Report Server and adding a line of code to the sever configuration file. The Report Server automatically detects the new extension and makes it available to users. For in-depth information on extensions, please see the Resources section.

SQL Reporting Services is a very flexible, enterprise reporting framework that provides a rich set of features out of the box. By exposing all of the service's functions through XML Web services and allowing access to custom .NET assemblies, Microsoft has opened the door for its users to implement Reporting Services in a variety of scenarios. Because of this flexibility, SQL Reporting Services can be used as a stand-alone report distribution platform, be easily integrated into corporate portals, or be called from WinForms/Web applications. Even though SQL Reporting Services is in its first release, it is a stable and scalable solution for any size company.

Resources

• Figure 1
• Figure 2
• Source Code