dcsimg

Parameter Support Objects, Pt II: Support OLAP Parameter Defaults with Datasets

January 31, 2008

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.







The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers