RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Build an XML Data Extension for SQL Server Reporting Services : Page 3

Get to know the main features of SQL Server Reporting Services and learn how to extend it with an XML Data Provider Extension.

Reporting Services Extensibility
The data processing extensions, the rendering extensions, and the delivery extensions allow programmers and third-party vendors to register additional extensions. Built-in data processing extensions provide access to SQL Server, OLEDB, OLAP, Oracle, and ODBC. Built-in rendering extensions are CSV, Excel, HTML, Web Archive (MHTML), PDF, TIFF, and XML. Finally, built-in delivery extensions let you send report results via e-mail or drop them on a file server. Oddly, RS currently doesn't support custom rendering extensions. This likely will change in the next version of RS, slated with the release of Yukon (SQL Server 2005).

Implementing an extension entails writing a bunch of .NET classes that implement specific interfaces defined in the Microsoft.ReportingServices.Interfaces assembly. The resulting assembly must be registered into the RS repository and given the required permission to execute. The following section addresses such registration details with a step-by-step guide to developing and deploying a Data Provider Extension.

Developing an XML Data Provider Extension
Quite often, the hierarchical structure of XML is better for representing data structures than tabular data. Additionally, XML is much more manageable when loaded in memory, thanks to the powerful query capabilities offered by XPath. Depending on your application's requirements and the amount of data you need to manage, you basically have two options (or some combination of the two) to store XML documents:

  1. Store XML documents in a database, mapping text elements and attribute values to table fields.
  2. Persist the document as-is in its angle-bracket representation on the file system (typically conceiving a folder structure and naming schema that helps in identifying specific XML documents).
Reporting on XML data structures is getting almost as common as reporting on database data sources. Tools like ActiveReports have accepted an XML document as data source for two or three years now. SQL Server Reporting Services doesn't natively support an XML stream as a valid data source. However, its flexible and extensible architecture lets you easily implement and plug in an XML data provider engine, which extracts and manipulates XML data, and passes it out to the report generator in a tabular form.

The interfaces you are required to implement when developing a data provider extension are modeled after a subset of the Microsoft .NET data provider interfaces. RS requires data extensions to provide data using a DataReader-like approach (i.e., using a forward-only, read-only cursor). The interfaces you implement when developing a custom data extension are:

  • IDBConnectionExtension
  • IDBCommand and IDBCommandAnalysis
  • IDataParameter
  • IDataParameterCollection
  • IDbTransaction
  • IDataReader
If you know the ADO.NET infrastructure, all the interfaces except IDBCommandAnalysis should look familiar. The IDBCommandAnalysis is inherited from IDbCommand. It is just a helper (optional) interface that provides support for parameters passing at design time. If it is implemented, VS.NET infers the required report parameters and asks for them when the report query runs within the designer.

You typically implement each interface (except the IDbCommand, IDBCommandAnalysis pair) in a separate, distinct class, placing code that raises exceptions when a non-supported functionality, such as transactions or parameters support, is required.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date