Introducing Microsoft Reporting Services
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.
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)
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 e-mail 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.
Page 3 of 5