Robert Bruckner's Advanced Reporting Services Blog : Upgrade

SQL Server 2008 SP1 and Report Builder Update

Robert M. Bruckner — Wed, 08 Apr 2009 08:30:00 GMT

Service Pack 1 for SQL Server 2008 is now available for download. The service pack is primarily a roll-up of Cumulative Updates 1, 2, and 3 and minor fixes made in response to requests reported through the SQL Server community.

While there are no new features in this service pack, a notable addition from a Reporting Services point of view is the ability to configure Click Once deployment to either launch Report Builder 1.0 or the updated Report Builder 2.0, directly from Report Manager (native mode) or SharePoint. If you run Reporting Services in SharePoint integrated mode, make sure to also install the updated RS add-in for SharePoint.

Furthermore, the April 2009 Feature Pack is now available and includes an updated version of Report Builder 2.0. You can get it either as Report Builder 2.0 stand-alone download, or as click once deployment from a Report Server with SQL Server 2008 SP1 applied.

Summary of download links:

Other download resources:

Enjoy!

Custom Report Item

Robert M. Bruckner — Wed, 31 Dec 2008 21:55:00 GMT

Custom Report Item in Reporting Services 2005

This server extensibility feature introduced in Reporting Services 2005 (RS 2005) provides the ability to develop custom report items for embedding in reports. Examples of resources available that provide insights into how one can build custom report item solutions include: documentation overview, sample, and a great MSDN magazine article by Teo Lachev.

Over time, several independent partners utilized this extensibility mechanism and developed nice 2005-based Custom Report Item (CRI) controls, such as Dundas Visualization Products for Reporting Services, various barcode controls, and even some that take RTF and draw it as image into reports.

Custom Report Item in Reporting Services 2008

RS 2008 introduces a new RenderingObjectModel and an on-demand paradigm for processing and rendering reports. Consequently, also the CRI runtime control interfaces and how the control interacts with the new on-demand RenderingObjectModel have changed. An updated CRI-Polygon sample is available for RS 2008.

Using 2005-based Custom Report Items in Reporting Services 2008

I have seen two common questions regarding the support of 2005 CRIs in RS 2008:

Q: What if you bought or developed a 2005-based CRI runtime control - can you run those old reports after upgrading your report server to RS 2008?

A: Yes, running 2005-based CRI runtime controls on a RS 2008 server is supported. Your old 2005-based reports will run on RS 2008 without modifications - however make sure to verify that the Web.config of your 2008 report server contains an assembly binding redirect for the Microsoft.ReportingServices.Interfaces.dll as specified in KB 955795.

Q: What about 2005-based CRI design time controls?

A: 2005-based CRI design time controls work with Business Intelligence Development Studio 2005 (BIDS 2005) only. You can continue to design reports with BIDS 2005 and deploy directly to your RS 2008 server with the 2005-based CRI runtime control installed.
For BIDS 2008 however, the CRI integration interfaces have changed, and you will need 2008-based CRI design controls to develop reports utilizing the full 2008 feature set (e.g. tablix) and 2008-based CRIs.

Additional information about upgrading a report with custom report items is provided in the documentation.

Special Case: Deploying 2005 Reports utilizing Dundas CRI controls to a RS 2008 Server

In short, your existing reports will run on RS 2008 without modifications. You may no longer need your 2005 CRI controls on the RS 2008 server in particular cases, as explained below.

With the acquisition of the data visualization products of Dundas Inc., reports utilizing 2005-based CRI controls from Dundas generally will be automatically upgraded on-the-fly into native 2008 charts and gauges in RS 2008. In that case, your old reports will run as native 2008 reports when deployed to a RS 2008 server.

If your 2005-based reports with Dundas CRIs utilize certain features, such as annotations or custom code, the reports won't be automatically converted into native RS 2008 charts/gauges, but instead remain 2005 reports that are executed in a transparent backwards-compatibility mode¹ of the processing engine in the RS 2008 server. In that case, or if you use the Dundas Maps or Dundas Calendar products, the reports will automatically run on the RS 2008 server, but you still need your 2005-based Dundas CRI runtime controls installed on the server.

Alternatively, Dundas is releasing several new 2008-based CRI design and runtime controls. You could upgrade your existing 2005 reports in BIDS (with the 2008 Dundas controls installed) to 2008 reports, utilize all the new 2008 features such as tablix, and then deploy them as 2008 RDLs to a RS 2008 server. Please contact Dundas directly, if you are interested in that option.

¹The related posting about the enhanced ExecutionLog2 in RS 2008 explains, among other topics, how an administrator can utilize the AdditionalInfo.ProcessingEngine value to determine whether an old report automatically upgraded to 2008, or if the report contains a 2005-based CRI and therefore is running in the transparent backwards-compatibility mode of the processing engine.

Happy New Year!

Using Group Variables in Reporting Services 2008 for Custom Aggregation

Robert M. Bruckner — Mon, 21 Jul 2008 07:00:00 GMT

Introduction

SQL Server 2008 Reporting Services (SSRS 2008) features an on-demand report processing engine. This on-demand architecture has a number of key advantages over the processing engine design that existed in previous major releases. The most significant benefits are vast improvements to report engine scalability and performance (you can read a bit more about it here). Because of this fundamental change from previous versions, there are some specific design patterns that have changed. This post is a discussion of one scenario that, due to the new processing engine, requires a different design pattern in 2008 than was required in 2005 and 2000.

Special thanks to my esteemed colleagues Chris Baldwin and Chris Hays, who helped with the contents of this posting. Note: screenshots and how-to steps in this post are based on the currently available SQL Server 2008 RC0 release of Report Builder 2.0. Future releases of this product may change. The attachment at the bottom of this posting contains both, a 2005 version and a 2008 version of the final reports. The reports are based on the Northwind sample database (download link).

On-Demand Report Processing

The new processing engine in Reporting Services 2008 still retrieves datasets upfront, but only pre-computes certain invariants, such as grouping, sorting, filter expressions, aggregates, subreport parameters and queries. Everything else are "on-demand" evaluated expressions; most notably, textbox values, and style expressions.

Furthermore, the processing engine now exposes a cursor-based report structure as so-called RenderingObjectModel. Rendering extensions, responsible for translating the processed report to the desired output format, traverse the report using a hierarchy of RenderingObjectModel cursors. This is in contrast to the processing engine in 2005 and 2000 in which the entire report was fully processed upfront. A couple implications of this on-demand model are that
a) objects are evaluated hierarchically throughout the report,
b) hidden textboxes are not evaluated, and
c) the concept of Report and Group Variables has been introduced

Report and Group Variables

In Reporting Services 2008 / RDL 2008/01 namespace, one can declare variables that are global throughout the report or local to particular group scopes and refer to them in expressions. Report and group variables can only be set/initialized once and have a read-only semantics.

Typical use cases for variables include:

Caching values:
Report/group variables can be used to make an expensive call to an external assembly once, cache the result, and then reference the variable value from other expressions in the report.
Time-dependent calculations:
For example, retrieve a currency conversion value and store it in a report/group variable to be applied consistently during the lifetime of the rendering session.
Specific execution-order semantics:
Achieve particular expression execution order semantics that is independent of the rendering extension used later for generating the report output.

The latter use case of group variables will be discussed in more detail in the remainder of this blog posting to implement custom aggregation in a Reporting Services 2008 report.

Custom Aggregate Scenario

The scenario discussed is one where a report author implements a custom aggregate, illustrated by an implementation of a Median function.
A common pattern for implementing a custom aggregate such as Median in Reporting Services 2005 is like this.

With the custom code for GetMedian and AddValue as follows:

Dim values As System.Collections.ArrayList

Function AddValue(ByVal newValue As Decimal)

If (values Is Nothing) Then

values = New System.Collections.ArrayList()

End If

values.Add(newValue)

End Function

Function GetMedian() As Decimal

Dim count As Integer = values.Count

If (count > 0) Then

values.Sort()

GetMedian = values(count / 2)

End If

End Function

What happens here in SSRS 2005 is that for each instance of the detail row, the value gets passed to AddValue() and then added to the values ArrayList. A textbox in the Table header, then, makes a call to GetMedian() which performs a calculation on the values in the ArrayList, and displays it.

It's important to note that this wasn't exactly supported in SSRS 2005 and it wouldn't even work properly in most cases. For example, if you were to add end-user sorting to the table, then the processing would go through a different code path that would evaluate the headers before the details. This would mean that the GetMedian() function would be called before AddValue has a chance to add any values are added to the ArrayList. It just so happens that in this particular case, when there is no end-user sort, the details are processed first.

Whether or not it was officially supported, a number of people got this to work and are relying on this behavior. In order for the same pattern to work in SSRS 2008, the report needs to be slightly redesigned. Detailed, step-by-step, instructions are provided below. Note that the pattern of using group variables outlined below is not limited to custom aggregation, but can be expanded into more complex solutions. We can show you the path and the pattern, but you will have to apply it to your unique situation. YMMV (your mileage may vary).

Implementing this in SSRS 2008: Step-by-Step

The report needs to be slightly revamped in 2008 in order for this to work. The custom code itself, however, doesn't have to change at all. This is going to be a step-by-step procedure by which you can port this pattern from your 2005 report to 2008. Note that the attachment at the bottom of this post contains a 2005 report and a 2008 report, both implementating this custom aggregation approach.

Open the report in Business Intelligence Development Studio (BIDS) 2008 or Report Builder 2.0. When you open the 2005 report in a 2008-based tool, the RDL schema will be automatically upgraded to 2008. This is what you'll see in Report Builder 2.0:
In on-demand processing, items are generally evaluated from the top-down. This means that in order to add the values of your detail rows into the ArrayList from which you will calculate the Median value, you need to add a "dummy" tablix to your report with its own detail row. This row can be hidden, as it's used solely for calculation purposes. Specifically, its purpose is to make calls to the AddValue function to populate the ArrayList. So that this table can "share" values with the table that will be visually presented in the report, it they both need to be part of the same table. Add a single static row above the header row in the table. Right-click in the blue Product Name cell, and select Insert Row > Above. In the newly inserted row, merge all of the cells. This is what you should see:
Click the new cell (as shown above), and from the Insert tab on the Ribbon, select Table. Delete the top row from the newly created table, and merge the cells together:
Select the detail group for this new inner table, and set the Hidden property to True. Since this is used only for calculations, it doesn't need to be visible in the rendered output of the report:
Now, you need to add the call to the AddValues function within the context of the nested table. As I mentioned above, a hidden textbox's value will not be evaluated due to the new on-demand processing architecture. In order to make sure the call to AddValues is made regardless of the visibility of the group, add it as a group Variable:
The original rows of the table need to be slightly restructured so that the original row functions as a group header.
Step 1: Right click in the Product Name cell and select Add Group > Row group > Parent group
Step 2: In the Tablix group dialog: Group by: 0 (constant value); Select Add Group header
Select the newly created group header textbox (with the 0 in it), right click, and select delete column. You should then have this:
Copy the contents of the blue cells into the row below it, so that it's inside the group. Then, delete the row from which the values were copied. Re-add the blue background to the other row if you want. Now you should have this:
Now, in order to properly retrieve the calculated Median value, you need to add the call to GetMedian into a group Variable for the group that contains the header where you want to value to be displayed. Select the group from the grouping pane, and add this group Variable:

Scale-Up Improvements in Reporting Services 2008

Robert M. Bruckner — Mon, 21 Jul 2008 04:00:00 GMT

A few months ago, leading up to the release of RC0 of SQL Server 2008, I was involved in working with the SQL Server Customer Advisory Team. They were investigating and comparing the scalability of Reporting Services 2005 and Reporting Services 2008, using common customer report scenarios and workloads. A more detailed whitepaper is planned for the future, which will also provide the underlying code and test framework so that you could plug-in your own reports, define your workload, and run these tests on your particular hardware and environment.

In the meantime, if you are thinking of moving to Reporting Services 2008, I’d strongly encourage you to read the following technical note titled Scaling Up Reporting Services 2008 vs. Reporting Services 2005: Lessons Learned.

The key take away from the Technical Note is that SQL 2008 Reporting Services can scale-up better than SQL 2005 Reporting Services. Summarizing the results, quoting from the technical note:

1) "Reporting Services 2008 was able to respond to 3–4 times the total number of users and their requests on the same hardware without HTTP 503 Service Is Unavailable errors compared with Reporting Services 2005, regardless of the type of renderer."

2) "With our test workload, Reporting Services 2008 consistently outperformed Reporting Services 2005 with the PDF and XLS renderers on the four-processor, quad-core hardware platform (16 cores) both in terms of response time and in terms of total throughput."

The SQL Server Customer Advisory Team did a great job of pulling together report scenarios and workloads, testing on three different hardware platforms, testing a few configuration options, and identifying key results. These results validate some of the quite significant work we have been doing in Reporting Services 2008. Furthermore, note that the scalability testing was performed with a non-optimized pre-release RC0 build of Reporting Services – an RTM deployment of Reporting Services 2008 is expected to show even slightly improved results.

The underlying architecture has changed considerably in Reporting Services 2008 (e.g. removing IIS dependency), and we added a number of quite significant new capabilities in the report processing engine and rendering extensions (e.g. tablix with arbitrary grouping and flexible layout support, vastly improved scalability support). We have been doing ongoing and extensive performance, throughput, and scalability testing internally within the Reporting Services team – so I guess some of these great results shown in the technical note weren’t all that surprising to members of the RS team. There was also anecdotal evidence and excitement by customers in blog postings and other forums, impressed with some of the improvements in Reporting Services that were visible as early as with the public SQL Server 2008 CTP release back in July 2007.

In future postings on this blog, I plan to cover important tips and tricks related to diagnosing and improving performance of complex reports (e.g. involving custom code) in RS 2008. This will hopefully enable you to even better take advantage of some of the underlying architecture changes in the RS 2008 report processing engine, such as dynamic on-demand processing.