Verification: Preview the Report and Inspect the Effectiveness of Our Solution
Let’s
preview the report to inspect the results of our handiwork.
1.
Click the Preview
tab.
DBJ_OLAP_Report.rdl initializes, and the first prompt
(based upon the pre-existing ProductCategory parameter), becomes
enabled.
2.
Leave the Product
Category prompt selection at its default of” Bikes, Components.”
3.
Click the
downward pointing arrow on the right side of the Year selector.
4.
Select CY
2004 within the Year parameter picklist.
We
notice the absence of an “All Periods” selection within the Year parameter’s
picklist – as we might have expected, because we filtered out that row of the
respective dataset (as we did for the Quarter and Month parameter
supporting datasets).
5.
Select CY
Q2 from the Quarter parameter picklist.
6.
Select the
month of June in the Month parameter picklist.
We
notice at this stage that the parameter picklists do not cascade.
Moreover, it might occur to us that intelligent defaults would give our consumers
a better runtime experience. We will address these two items in an article
devoted specifically to these subjects.
7.
Click the View
Report button.
The
report executes quickly and returns the data for the selections we have made
within our parameter picklists, in a manner similar to that shown in Illustration
51.
Illustration 51: The Report
Parameters Operate Largely as Expected ...
Our
verification process has demonstrated the effective support of Report
Parameters through the creation and use of objects within the Analysis
Services layer of our BI solution. We will extend our examination of Analysis Services
supported parameterization yet further in a subsequent article, where we will
generate a solution to provide cascading picklists, and to meet the need
of our colleagues to provide intuitive parameter defaults to information
consumers at report runtime.
NOTE: Please consider saving the .rdl file we have created to this point
for use in the article that follows, so as
to avoid the need to repeat the preparation process we have
undertaken above.
8.
Experiment
further with the report, if desired.
9.
When finished
with the report, click the Layout tab.
10.
Select File
-> Save DBJ_OLAP_Report.rdl As ... to save our work, up to this
point, to a location where it can be easily accessed for the next article within
our series.
11.
Select File
-> Exit to leave the design environment,
when ready.
Conclusion ...
In
this article, we continued the extended examination of Parameters in Reporting
Services that we began in Mastering
OLAP Reports: Parameters for Analysis Services Reporting, Pt. I, and Mastering
OLAP Reports: Parameters for Analysis Services Reporting, Pt. II, and which we continued in Reporting Services: Customize Automatically Created
Parameter Support Objects and Parameter
Support Objects, Pt II: Support OLAP Parameter Defaults with Datasets.
Working
with the basic OLAP report we created in Reporting Services: Customize Automatically Created
Parameter Support Objects, we once more began within the scenario we
established within Parameter
Support Objects, Pt II: Support OLAP Parameter Defaults with Datasets, with an objective of meeting the
need of the hypothetical client to support parameterization, including picklists,
within the report. This time, however, we exposed the steps involved in
offering a simple means of supporting our solution from within the Analysis
Services layer of the integrated Microsoft BI solution.
In
examining the requested addition of parameter defaults within a sample
OLAP report, we began with a review of the concept of parameterization in general,
and briefly overviewed options for
supporting report parameterization among the three primary layers of the
integrated Microsoft business intelligence solution. We then opened the sample Report
Server project, AdventureWorks Sample Reports, and ascertained connectivity
of its shared Analysis Services data source. We continued our
preparation for the practice session by creating a clone of an existing sample OLAP
report, containing a Matrix data region, with which to perform our
practice exercises. We then made structural modifications to the clone report, to prepare
for our practice exercise session.
We discussed,
and then implemented, an approach, from within Analysis Services, to
meet the need of our hypothetical client to support Report Parameters
from the Analysis Services layer of the integrated Microsoft BI
solution. We then accessed
and employed the new Analysis Services parameter support components from
within Reporting Services. Throughout our article, we overviewed how the
various components of the parameter support solution we proposed are
tied together, as a part of our hands-on practice session, where we created and
aligned the necessary components within Analysis Services and Reporting
Services to support our runtime parameters. Finally, we previewed the report to observe the
effectiveness of our solution in runtime action, and looked ahead to our next
article, where we will examine the establishment of cascading picklists
into our current solution, together with the addition of intuitive parameter
defaults at runtime, for greater user-friendliness and overall operational
efficiencies.
»
See All Articles by Columnist William E. Pearson, III
Discuss this article in the MSSQL Server 2000 Reporting Services Forum.
» 
Comment and Contribute
