 In This Chapter SSRS is designed for extensibility. In the previous chapters, you learned how to extend SSRS' reporting capabilities by writing a custom code that can be called from a report. Extensions, on another hand, are called by SSRS. Extensions are composed of four key categories: security, delivery, data processing, and rendering (see Chapter 3, "Reporting Services Architecture," Figure 3.1). Typical extensions installed with SSRS are as follows : -
Data processing Microsoft SQL Server, OLE DB (including OLEDBMD for Microsoft SQL Server Analysis Services), Oracle, ODBC, and XML. XML was one of the most frequent requests for data extensions in SSRS 2000. Many developers are happy to see XML data sources in SSRS 2005. Additional extensions that can be deployed in this category are SQL Server Integration Services (SSIS) and SAP data-processing extensions. -
Delivery File share, eMail, NULL. -
Render Excel, MHTML, HTML3.2, HTML4.0 (Microsoft Internet Explorer 5.0 or later), PDF, IMAGE (graphical image output, such as TIF, GIF, JPG), CSV, XML, NULL (used to place reports in cache and in conjunction with scheduled execution and delivery). -
Other SemanticQuery and ModelGeneration to extend Report Builder's functionality. EventProcessing to act on the events generated by Report Server. Security extensions are not typically installed. By default, SSRS uses Windows integrated authentication. A complete list of extensions installed on a particular instance of SSRS can be retrieved by calling ReportingService2005.ListExtensions(ExtensionTypeEnum.All) or by examining the rsreportserver.config file. Rendering is, perhaps, the most developed category of extensions. With a wide range of rendering extensions and a multitude of applications (including Microsoft Office) that "understand" HTML, it is hard to think of a new rendering extension that would be immediately useful. Some of the SSRS capabilities that customers are frequently looking for and that are currently not available "out of the box" are as follows: -
Printer (fax) delivery The ability to print (fax) batches of reports without human interactions -
.NET data set access An ability to access a data set that was created inside of an application -
Custom authentication An ability to authenticate non-Windows clients It is possible to work around the need to have certain functionality. For example, instead of delivery to a printer directly from SSRS, an administrator can configure delivery of a report to a file share and have a separate process monitoring and printing from such a file share by using the Windows PRINT command, such as PRINT /D:\\<server URL>\<printer name > <files to print> . It is also possible to work around the scenario in which users cannot use Windows authentication. An administrator can create a Windows account for a user, configure IIS to accept Basic authentication (must enable SSL for better security), and ask the user to enter Windows credentials to access a report. Although it is possible to work around some of the limitations, custom extensions can offer elegant solutions to supplement missing functionality. A custom extension is a private or shared .NET assembly with a unique namespace (the exact name is not important, but it must be unique), and a class that implements the IExtension interface and one or more interfaces shown in Table 26.1. As with any .NET implementation, Visual Studio is the most frequently used development tool for development of assemblies and, therefore, extensions. Table 26.1. Typical Set of Interfaces Used in Custom Extensions | Interface(s) | Applied to an Extension Category | Description | | IAuthenticationExtension | Security | Implementation of this interface extends the authentication feature of SSRS. This interface is derived from IExtension . | | IAuthorizationExtension | Security | Implementation of this interface extends the authorization feature of SSRS. This interface is not Common Language Specification (CLS)-compliant. This means that not all .NET languages can call or implement this interface; also C# and VB.NET can deal with this interface just fine. This interface is derived from IExtension . | | IDbConnection, [IDbConnectionExtension], IDbTransaction, [IDbTransactionExtension], IDbCommand, [IDbCommandAnalysis], [IDbCommandRewriter], IDataParameter, [IDataMultiValueParameter], IDataParameterCollection, IDataReader, [IDataReaderExtension] | Data processing | [Optional] and required interfaces of a class that implements a data-processing extension. Those interfaces are modeled after .NET data provider interfaces and defined in the Microsoft.ReportingServices.DataProcessing namespace. | | IDeliveryExtension | Delivery | Implementation of this interface interacts with SSRS to share and validate an extension's settings and to execute delivery. This interface is derived from IExtension . | | IDeliveryReportServerInformation | Delivery | Implementation of this interface is used in conjunction with IDeliveryExtension . SSRS supplies information about itself through this interface. | | IRenderStream | Rendering | Implementation of this interface provides support for multiple streams rendering from a rendering extension. | | IRenderingExtension | Rendering | Implementation of this interface is required for a rendering extension so the extension is recognized by SSRS. This interface is defined in the Microsoft.ReportingServices.ReportingRendering namespace. | | [ISubscriptionBaseUIUserControl] | Delivery | Implementation of this interface provides a subscription UI for the Report Manager. This interface is what shows data-entry fields. For example, in the case of an email, it displays an interface to enter "TO:" email address, and so on. This interface extends IExtension . This interface is optional because a subscription can be created using SOAP API methods CreateSubscription and CreateDataDrivenSubscription . The class that inherits from this interface must also inherit from System.Web.UI.WebControls.WebControl . |
|
