This post originated from an RSS feed registered with .NET Buzz
by Tim Sneath.
Original Post: Building Advanced Reporting Services Applications
Feed Title: Tim Sneath's Blog
Feed URL: /msdnerror.htm?aspxerrorpath=/tims/Rss.aspx
Feed Description: Random mumblings on Microsoft, .NET, and other topics.
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 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.
Previous Topic
