About the Report Definition Language
At this point, you may be wondering what an RS-based report file looks like and how it is stored. RS saves the report as an Extensible Markup Language (XML) file that is described in a Report Definition Language schema.
Figure 1.2 With RS you can create various types of reports, including drilldown crosstab
reports like this one.
DEFINITION A report definition contains report data retrieval and layout information. The report definition is described in an XML schema, called the Report Definition Language (RDL).
Saving reports as XML-based report definition files offers two main advantages:
- It makes the report format open and extensible. Using the XML-based RDL format is beneficial for achieving interoperability among applications and vendors. Microsoft is working with other industry leaders to promote RDL as an XMLbased standard for report definitions. Visit the RS official website (check the Resources section for the link) for a list of Microsoft RS partners.
- It makes the report portable. For example, you can easily save the report to a file and upload it to another Report Server. In chapter 2 you’ll see how a third-party reporting tool leverages this feature for ad-hoc reporting.
If you use the Report Designer to create your report, its definition will be automatically generated for you. However, just as you don’t have to use Visual Studio .NET to write .NET applications, you can write the report definition using an editor of your choice, such as Notepad, or generate it programmatically (as you will see in chapter 2). Of course, the Report Designer makes authoring reports a whole lot easier. Third-party tools will most likely emerge at some point to provide alternative RDL editors.
1.2.2 Management features
RS facilitates report management by storing reports and their related items in a central report catalog. To deploy and manage a report, you need to upload it to the report catalog. When this happens, it becomes a managed report.
DEFINITIONS Throughout the rest of this book we will use the terms report catalog and report repository interchangeably to refer to the RS Configuration Database. For more information about this database, refer to section 1.3.2. A managed report is a report that is uploaded to the report catalog.
For .NET developers, the term “managed” has nothing to do with .NET managed code, although the pattern is the same. While .NET managed code runs under the supervision of the .NET Common Language Runtime (CLR), a managed report is generated under the control of the Report Server.
You may wonder what really happens when a report is uploaded to the report catalog. At publishing time, the Report Server parses the report definition (RDL), generates a .NET assembly, and stores the assembly in the Report Configuration Database for the report. The RDL file is never used again. When the report is processed, the assembly is loaded and executed by the Report Server.
A report can include other items, such as images and data source–related information. These report-related items are also stored in the report catalog. Finally, the report catalog captures additional information, called metadata, associated with reports. For example, just as you can organize physical files in folders, RS allows you to organize reports in folders.
DEFINITION The report metadata describes additional configuration information associated with a report, such as security permissions, the parent folder, and so forth.
RS offers centralized report management that administrators will appreciate. To simplify the administration of the report catalog, RS comes with a tool called the Report Manager. The Report Manager is implemented as a web-based application, and as such it is easily accessible. This tool empowers you to manage just about any aspect of the report repository, including
- Report information and metadata, such as the folder structure and report properties
- Data sources from which the report will draw data
- Report parameters (for parameterized reports)
- Security
1.2.3 Delivery features
Reports hosted under RS can be delivered using on-demand (“pulled”) delivery or subscribed (“pushed”) delivery. The more common scenario is on-demand delivery, where the user requests the report explicitly. As a report author, you don’t have to do anything special to web-enable your report because RS does this for you once it is uploaded to the report catalog.
The “pushed” delivery option alone can justify implementing RS. This option gives end users the ability to subscribe to reports, so reports will be sent to them when a certain event is triggered—when a timing event triggers, for instance, for report subscriptions based on a schedule. As another example, a financial institution could allow its customers to opt in and subscribe to certain reports of interest, such as a monthly bank statement. Then, at the end of the month, the bank statement report could be generated and sent to users via e-mail. We’ll discuss the report-delivery process in more detail in section 1.5.
1.2.4 Extensibility features
An important characteristic of every enterprise-oriented product, such as RS, is that it has to be easily extendable. Simply put, extensibility relates to the system’s ability to accommodate new features that are built out of old ones. One of the things I like most about RS is the extensibility features it includes by virtue of its open and flexible architecture. Developers can easily extend RS by writing .NET code in their preferred .NET language. Specifically, you can extend RS in the following areas:
- Custom .NET code—.NET developers can enhance reports programmatically by writing .NET custom code. Chapter 6 demonstrates how you can add forecasting features to your reports by using prepackaged code in the form of .NET assemblies.
- Data processing extensions—Out of the box, RS can connect to any data source that has an ODBC or OLE DB provider. In addition, you can write your own custom data extensions to report off other data structures, as chapter 15 illustrates.
- Delivery extensions—Out of the box, subscribed reports can be delivered via email or file share delivery extensions. Developers can write their own delivery extensions to deliver the report to other destinations, such as to web services, as you’ll learn in chapter 15.
- Security extensions—By default, RS uses the Windows-based security model to enforce restricted access to the report catalog. If Windows-based security is not an option, you can replace it with custom security models. You’ll see an example of how this could be done in chapter 15, where we’ll implement custom authentication and authorization for Internet-oriented reporting.
- Rendering extensions—Generating reports in other export formats than the ones supported natively can be accomplished by writing custom rendering extensions. See section 1.4.2 for more information about the supported export formats.
1.2.5 Scalability features
A scalable application responds well under increased loads. RS can scale up and out to address the high-volume reporting requirements of large organizations. It is designed from the ground up to process reports efficiently. For example, it supports several report caching options, such as report execution caching, snapshots, and report sessions, as we discuss in chapter 7.
Reporting Services Enterprise Edition supports clustered deployment, which you can use to load-balance several RS servers on multiple machines. This allows enterprise organizations with high-scalability requirements to scale out RS and provides fault tolerance. RS performance is the subject of chapter 16.
1.2.6 Security features
RS is designed to provide a secured environment from the ground up. It offers a comprehensive security model for accessing reports that leverages Windows authentication. This model maps the user Windows account or group to a role, and the role describes what permissions the user has to access items in the report catalog. Report administrators can add Windows users to predefined roles or create new ones.
Once again, when the default Windows-based security model is not a good fit, you can replace it by plugging in your own custom authentication and authorization implementations in the form of custom security extensions.
To promote trustworthy computing, RS leverages the .NET code-based security to “sandbox” custom code based on configurable security policies. We discuss the RS security model in chapter 8.
1.2.7 Deployment features
Because it is server-based, RS has zero deployment requirements for integrating with client applications. For this reason, any type of client applications can target RS, not only .NET-based applications. Because you can access RS through the two most popular web protocols, HTTP-GET and Simple Object Access Protocol (SOAP), any webcapable application can be integrated with RS, regardless of the targeted platform and development language.
DEFINITIONS The Hypertext Transfer Protocol (HTTP), on which the Internet is based, comes in two flavors: HTTP-GET and HTTP-POST. While HTTP-GET passes request parameters as a part of the URL, HTTP-POST passes them as name/value pairs inside the actual message. Simple Object Access Protocol (SOAP) is a lightweight XML-based protocol, layered on top of HTTP, for exchanging structured and type information on the Web. In recent years, SOAP has become the industry-standard protocol for communicating with web services.
Integrating your applications with RS requires a good grasp of its architecture. The next section outlines the major RS building blocks.
|
