Report Variables and Group Variables in Reporting Services 2008

Note:   this posting provides an overview of when to consider using Report Variables and/or Group Variables for general report design patterns.  There is also a detailed blog posting that describes a particular report design pattern (custom aggregation) report authors may have been using in Reporting Services 2005, which requires group variables in Reporting Services 2008. 

On-Demand Report Processing

Reporting Services 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 releases.  The most significant benefits are 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.   
 
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 at the time a particular page is rendered; most notably, textbox values, and style expressions.

As a result, the internal execution order of expressions in Reporting Services 2008 might be vastly different compared to previous releases.  If your reports make custom code / custom assembly calls with side-effects relying on undocumented expression evaluation order (e.g. accumulating state via an expression in a table detail section, and relying on the state being fully populated in a "later" expression), the report may not work as before when upgrading it to Reporting Services 2008.  Report and group variables were introduced to address this scenario.

Report and Group Variables

In Reporting Services 2008, 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 / expensive calculations:
  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 (to avoid re-evaluating the original expression repeatedly during on-demand report processing).
   
• 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.  This use case is not as common, but also a bit more complex.  It is discussed in detail in another blog posting titled Using Group Variables In Reporting Services 2008 for Custom Aggregation. That posting also includes sample reports and step-by-step instructions.

-- Robert