Report Manager Update
Report Manager remains the default tool for end users to view and manage report content for Report Server in native mode. It is now the only tool available to manage reports, models, data sources, subscriptions, and permissions.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
If you are going to use SSRS in SharePoint integrated mode, see Chapter 36, "Managing Reports in SharePoint." That chapter provides more information about managing reports via the SharePoint user interface.
Here are the key changes in Report Manager in SSRS 2008 compared to 2005:
- Report Server administration features such as job management have been moved to SSMS, whereas report content management features have been removed from SSMS. This avoids duplication of features between the two tools.
- Model management, model clickthrough, and model item security have been added in Report Manager. Users can set model item security (see Figure 4.10) and associate clickthrough reports to entities in a model (see Figure 4.11).
FIGURE 4.10 Report Manager: model item security.
On the Data Source page, a Generate Model button is available. This button brings up a page that enables you to specify the name, description, and location of the model. After a model has been created, it can be managed in Report Manager. Figure 4.12 shows a general view of a model. Note the Edit and Update links. Edit allows saving the model .smdl file so that it can be edited. Update allows uploading the latest .smdl file to replace the existing one in Report Manager.
Report Engine Architecture Changes
The report engine is responsible for processing and rendering reports. A primary goal behind architecture changes in SSRS 2008 was to make the report engine capable of scal-able enterprise reporting.
SSRS2K5 suffered from a few limitations with regard to scalability and rendering consistency:
- Reports were bound by memory. This meant that large data sets and pages in reports could cause out-of-memory exceptions. A single large report could block or fail many small reports.
- End users had to wait for a long time if a report had hundreds of pages, even though they wanted to see only the first few pages.
- Report-rendering layout and page breaks were inconsistent across various report export formats (Excel, PDF, CSV, and so on).
FIGURE 4.11 Report Manager: associate clickthrough reports.
FIGURE 4.12 Report Manager: model management.
Here are the key changes that were made in the report engine in SSRS 2008 to address these problems:
- The processing engine takes advantage of new memory management capabilities in SSRS 2008 to swap memory to disk for large reports and to balance memory usage between large and small reports.
- Processing has been changed to follow an on-demand processing model, where each page of the report is processed and rendered only when the user wants to view it. This avoids handling of large amounts of report data at runtime.
- There is a new report-rendering object model in SSRS 2008 that supports on-demand report processing and consistent layout and pagination between different report-rendering formats.
Report-Processing Scalability Enhancements
SSRS 2008 enables administrators to specify minimum and maximum memory settings, and SSRS tries to keep within that bound by swapping memory to the file system when under memory pressure. For more information, see the "Memory Management" section in Chapter 2. Figure 4.13 shows the difference in behavior between memory usage in SSRS2K5 and 2008. In 2005, memory pressure could cause SSRS to fall over and recycle the application domain, which essentially kills all reporting requests. In 2008, memory pres-sure causes the report engine to swap memory to a file system cache and reduce the memory usage to remain below the maximum memory allocated to SSRS. This allows SSRS to scale to meet the needs of executing large reports and a large number of report-execution requests.
The primary enhancement in the processing engine in SSRS 2008 is on-demand processing, which allows processing each page of a report when the user actually wants to view it. This avoids the burden on the report processor to handle large amounts of data processing up front for all runtime requests.
Figure 4.14 and Figure 4.15 show how the SSRS report-processing engine behaves in 2005 and 2008, respectively.
In 2005, report processing and rendering follows this workflow:
- Execute queries and retrieve data sets.
- Perform grouping, sorting, and filtering, and calculate aggregates as defined in the report definition.
- Report items such as images and text boxes are evaluated and stored in an interme-diate format (snapshot).
- The entire intermediate format is exposed through the Rendering Object Model (ROM), and the report gets rendered.
In 2008, the renderers are invoked right after the data-fetch stage. Subsequent processing is triggered by each page-rendering request. Computations such as grouping, sorting, and
FIGURE 4.13 SSRS2K5 versus 2008 memory usage.
FIGURE 4.14 SSRS2K5 report-processing flow.
FIGURE 4.15 SSRS 2008 report-processing flow.
aggregation are done the first time a data region is accessed through the ROM. Report items such as text box values and style expressions are evaluated only when the relevant page is rendered. A report item cache is used to help optimize performance.
As a result of the on-demand processing enhancements in SSRS 2008, there is a reduced and predictable data-processing and computation cost for each page-rendering request. Figure 4.16 shows a comparison of page response time when running reports with the SSRS2K5 report-processing engine versus the page response time with the SSRS 2008 report-processing engine. Notice that the response time for rendering any arbitrary page number with SSRS 2008 is lower and predictable.
The new Rendering Object Model (ROM) in SSRS 2008 provides more consistent rendering layout between different renderers. When you set a page break in your report, 2008 pagination provides more consistent paging behavior when you are viewing or exporting a report.
Here are some key new report-rendering changes in SSRS 2008:
- Word rendering is now supported. Reports can be exported as a Microsoft Word document that is compatible with Microsoft Office Word 2000 or later.
- An Excel rendering extension can now be used to export reports with subreports and nested data regions to Microsoft Office Excel.
- The CSV rendering extension has been changed to produce data-only content, as opposed to a combination of data and layout in 2005. Data-only output files can be consumed more readily by other applications.
FIGURE 4.16 Report page response-time comparison.
Figure 4.17 shows the report-rendering architecture in SSRS 2008. Renderers are grouped as soft page-break renderers (such as HTML, MHTML, Word, and Excel), hard page-break renderers (such as PDF and Image), or data-only renderers (such as CSV and XML).
FIGURE 4.17 SSRS 2008 report-rendering architecture.
What's New in SQL Server Reporting Services 2008
SQL Server Reporting Services 2008 features and architecture changes
SSRS 2008 Report Manager architecture and scalability changes
SSRS 2008 ReportViewer and Report Designer enhancements
SSRS 2008 RDL and SharePoint integration enhancements
Printed with permission from Sams Publishing. Copyright 2009. Microsoft SQL Server 2008 Reporting Services Unleashed by Michael Lisin, Jim Joseph and Amit Goyal. For more information about this title and other similar books, please visit Sams Publishing.