About the Series …
This
article is a member of the series MSSQL Server Reporting Services. The series is designed to
introduce MSSQL Server Reporting Services (“Reporting Services”),
presenting an overview of its features, with tips and techniques for real-world
use. For more information on the series in general, please see my initial Database Journal article, A New Paradigm for Enterprise Reporting. For the software components, samples and tools
needed to complete the hands-on portion of this article, see BlackBelt Administration: Linked
Reports in Report Manager, another article within this series.
Introduction
As we learned in Mastering OLAP Reports: Parameters for Analysis Services
Reporting, Pt. I and Mastering OLAP Reports: Parameters for Analysis Services
Reporting, Pt. II, a common enterprise reporting
requirement is the capability to filter reports at run time for specific
information. This is typically managed via parameterization, also known
as “prompting”, where the filter criteria is requested (and hence the
consumer is “prompted”) when the report is run. Depending upon the parameter
type (the most common are type-in and picklist), the filters are
typically enacted when the consumer types or selects a value, or a series of
values.
In the first half of this article,
Customize
Automatically Created Parameter Support Objects Pt. I, we
reviewed type-in and picklist parameters in general, and then
concentrated our focus, once again, upon picklist parameters, which we noted
to be a frequent choice among information consumers for user-friendly operation
within reports. Picklist parameters add value in several ways,
including the inherent elimination of typing errors, as well as the enforcement
of standard selections for report execution. We noted that the design of the picklist
is important in making runtime selections easy, and that picklists that
present long scrolling processes or other cumbersome methods can negatively
affect consumer perceptions, particularly when they are components within
commonly requested reports.
When working with clients to
design and create virtually any enterprise report, I ask questions about the
report’s objectives and intended appearance; moreover, I ask questions about
source data, filtering, and other considerations involved with the information
retrieved by the underlying datasets. When I reach the point at which we
discuss parameterization (the vast majority of reports contain parameters),
I virtually always follow up with questions about desired parameter defaults.
Parameter defaults are important to consider for a couple
of primary reasons. First, and certainly the most basic, is that the absence
of parameter defaults within a report results in one of two things at
runtime: either all sits idle until the information consumer makes parameter
selections and executes the reports, or a blank report is generated (assuming
the Report Parameters dialogs involved allow blank values within
the parameter input / selector boxes). While neither of these
conditions presents an issue to consumers understanding underlying settings,
each can still mean inconvenience in general and perhaps confusion to less
experienced users.
The second design consideration of
importance that surrounds Parameter defaults goes beyond their simple
absence or presence, and focuses more upon their intuitiveness. By
“intuitive,” I mean “dynamically intelligent.” While it is quite desirable to
select among numerous criteria at runtime, we can add finesse to the selections
we offer by having the more likely desired selections, considering the nature
of the report and its typical usage by information consumers, appear as defaults
at runtime. The obvious objective is to make the steps involved in report
execution more efficient, for most of the consumers, most of the time.
In this article, we will continue working with the basic OLAP
report we created in the first half of this article, Customize
Automatically Created Parameter Support Objects Pt. 1. We will establish a scenario within which we expose the steps
involved in meeting a basic need of a hypothetical client in adding runtime default
selections that will appear within the parameter picklists of the
report. In examining
the requested addition of parameter defaults within an OLAP report
containing a Matrix data region, we will:
-
Reopen the
sample Report Server project, AdventureWorks Sample Reports, and
access the existing sample report we prepared in Pt. I. -
Discuss
options for supporting intelligent parameter picklist defaults among the
three primary layers of the integrated Microsoft business intelligence
solution. -
Discuss an
approach to meeting the need of our hypothetical client to present parameter
picklist defaults that represent the last period of data entry in
our cube. -
Create a dataset
to provide parameter default support in the Reporting Services
layer of the client’s BI solution. -
Overview how
the various components of the default support solution we propose are
tied together, as a part of a hands-on practice session where we create and
align the necessary components to support our parameter defaults. -
Preview the
report to observe the effectiveness of our solution in runtime action.
