Building Advanced Reporting Services Applications

Creating Reports
Reporting Services is built on SQL Server 2000, and the metadata definitions are stored in a database. On top of that, the Report Server contains a web service and a Windows service. The web service provides the interface into the system. Each of the underlying data processing, rendering, security and delivery services that sit under these interfaces can be extended to provide custom functionality. The Windows service handles all scheduled activity (agent activity) and offers no external interface. Reports are defined in RDL, an extensible XML format. You can create an RDL file externally to Reporting Services either by handcrafting it or using Visual Studio, and then upload it to the server

Accessing Reports via URL
The reporting web service can be accessed via URL from a web browser. Once uploaded, you can generate the report with a URL similar to this:


Parameters can also be passed as part of the URL: there are rs: parameters that specify server behaviour across all renderers, and rc: parameters which provide specific functionality for a specific output type (for example, disabling the toolbar for HTML 4.0 output). It's very easy to incorporate reports into your application using this approach, and it's possible to provide quite detailed parameterisation using the URL to control the output report.

Web Service Interface
Access via http://servername/ReportServer/ReportService.asmx. This is of course a traditional ASP.NET 1.1 ASMX web service interface, supporting WSDL with the ?wsdl parameter, and can therefore be accessed by any SOAP 1.1-compliant client. This is a pretty big web service: there are about 70 API calls (plus asynchronous Begin/End versions of those calls), and perhaps 100 different classes that can be created to model various elements of the Reporting Services architecture.

SOAP headers are supported within the web service to specify things such as a batch ID (to provide basic batch processing). To use the reporting service, you need to specify some credentials: either using basic authentication (create a new System.Net.NetworkCredential) or integrated authentication (use the System.Net.CredentialCache.DefaultCredentials property). You can then use the web service Render() method programmatically as an alternative to calling the report server via URL. The Render method is pretty sophisticated: it has twelve parameters, of which one is in turn a parameter collection! But of course this is the correct way to build web services: chunky rather than chatty calls reduce network bandwidth and roundtrips.

Extensions provide a way to extend the Reporting Services platform. You can write managed code that runs in the server process and implements published interfaces. Extension types should be your last resort!

  • Data Extensions: communicates to data sources and returns data

  • Delivery Extensions: delivers reports over different protocols and to different devices

  • Rendering Extensions: renders to specific formats and devices

  • Security Extensions: Authenticates and authorises non-Windows users.

Data Extensions are comparatively easy to write: you basically are implementing a subset of a .NET managed provider, supporting IDbConnection, IDbCommand, IDataParameter and IDataReader. There are some extended interfaces that can also be optionally supported.

Rendering extensions provide a way to generate a new output format. These are not simple to write or maintain, and since it's a process running on the server, it's important to carefully constrain memory usage, particularly if there are multi-million rows of data in a report. You implement the IRenderingExtension interface and provide a Render method.

Delivery extensions take an event and specified destination as input, and the output is the delivered reports or notifications. Here the interface is IDeliveryExtension, which delivers an input notification to a destination and verifies that a set of delivery information is valid.

Security extensions allow you to provide custom authentication: here you implement IAuthentication and IAuthorization interfaces. Further details are documented in a white paper. Note that these extensions are only supported in the Enterprise Edition of the product.

Comments (9)

  1. Anonymous says:

    does anyone know how to get the toolbar to show when using web services?

  2. Anonymous says:

    FYI I ended up building my own 🙁

    it works fine but the new problem is drill down.

    when the content is returned from reporting services, all the links are set to go to reporting services url.

  3. Anonymous says:

    Hi John,

    How did you handle paging (browsing the reports pages) in your custom Toolbar?


  4. Anonymous says:

    how handle pagenation and zooming if ur creating custmize toolbar.


  5. Anonymous says:

    I tried to work with the web service extensively and there is some rendering functionality lacking.  It looked like it was more designed for report server management, i.e. setting up folders, permissions, etc…

  6. Anonymous says:

    Any answers to above questions on how to handle pagination with custom tool bar??

  7. Anonymous says:

    how can u handel paging in the excel that u generate out of  a report

  8. Anonymous says:

    Paging in Excel is done by creating a tab per page

Skip to main content