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.
About the Mastering OLAP Reporting Articles …
One of the first things that become clear to “early adopters” of Reporting Services is that the “knowledgebase” for Analysis Services reporting with this tool is, to say the least, sparse. As I stated in my article, Mastering OLAP Reporting: Cascading Prompts (where I treated the subject of cascading parameters for Reporting Services 2000), the purpose of the Mastering OLAP Reporting subset of my Reporting Services series is to focus on techniques for using Reporting Services for OLAP reporting. In many cases, which I try to outline in my articles at appropriate junctures, the functionality of well-established, but expensive, solutions, such as Cognos PowerPlay, can be met in most respects by Reporting Services – at a tiny fraction of the cost.
The vacuum of documentation in this arena, even taking into consideration the release of several books surrounding Reporting Services 2005 in recent months, continues to represent a serious “undersell” of Reporting Services, from an OLAP reporting perspective. I hope to contribute to making this arena more accessible for everyone, and to share my implementation and conversion experiences as the series evolves. In the meantime, we can rest assured that the OLAP potential in Reporting Services will contribute significantly to the inevitable commoditization of business intelligence, via the integrated Microsoft BI solution.
For more information about the Mastering OLAP Reporting articles, see the section entitled “About the Mastering OLAP Reporting Articles” in my article Ad Hoc TopCount and BottomCount Parameters.
In recent articles within this series, we have focused upon various aspects of parameterization within the Reporting Services environment. In some cases we have supported parameterization from structures completely contained within Reporting Services, and in others we have created parameter (predominantly picklist) support from within other layers of the integrated Microsoft business intelligence solution. As many of us are aware, enterprise reporting applications typically allow for parameterization (via what are sometimes known as “prompts” or “parameter prompts”) to enable information consumers to quickly find the information they need from a report. These parameters, whose values are physically passed to an axis specification or a slicer in the dataset query, often act to put filters into place “on the fly;” the “filters” are thus enacted when the consumer types or selects a value, or a series of values, at run time.
Because they allow information consumers to assume a role in guiding the delivery of information – and add a “self-serve” component to the reporting experience – parameterization in general is a popular topic in the forums and newsgroups of most enterprise reporting applications. My first exposure to the concepts of parameterization was in working with very early versions of Cognos Impromptu. My continued application of those concepts over the succeeding years within Cognos, Crystal, Business Objects, MicroStrategy, and several more specialized applications, has given me a great appreciation for the opportunities that exist in the business environment for effective parameterization. Whether the reports are to be printed, displayed on screen, or any of the other options for production / deployment, it’s easy to see the value that parameterization can add in making the selection and delivery of enterprise data more focused and consumer-friendly.
While I have extended parameterization concepts into many arenas, none have captured my attention as much as their deployment within the integrated Analysis Services / Reporting Services pairing. These applications work together to provide business intelligence in a way that is powerful and highly flexible. Indeed, I often advise clients who are attempting to locate a consultant to implement the integrated Microsoft BI solution (composed of MSSQL Server, MSSQL Server Analysis Services, and Reporting Services) to seek a “multidimensional architect” – a practitioner who has a good working knowledge of each of the components, and who can determine where, among three or more possible “logical layers,” to place which components so as to optimize the system as a whole.
NOTE: For details surrounding hands-on approaches (as you will see, they are Legion) to the mechanics behind supporting parameterization, (including the generation of picklists) in Reporting Services, see these articles in MSSQL Server Reporting Services series here at Database Journal:
- Mastering OLAP Reporting: Cascading Prompts
- Customize Automatically Created Parameter Support Objects
- Parameter Support Objects, Pt II: Support OLAP Parameter Defaults with Datasets
- Support Parameterization from Analysis Services
- Parameterization from Analysis Services – Cascading Picklists
- Support Parameterization from Analysis Services – Parameter Defaults
Throughout various articles of this series, we have generated simple lists to provide virtually all we need to support parameterization within Reporting Services and other enterprise reporting applications. In this article, we will perform a more detailed examination of the mechanics behind parameterizing an MDX function – or more precisely, for parameterizing the variable argument within such a function. We will illustrate the process using the popular LastPeriods() function, which we introduced in MDX Time Series Functions, Part I: PeriodsToDate() and Kindred Functions (a member of my MDX Essentials series at Database Journal), but the same logic can be extrapolated to many other similar MDX functions, as will become noticeable later in our article.
In this article, we will get hands-on exposure to parameterizing an MDX function, LastPeriods(), within a preexisting sample OLAP report. Beginning with the general concepts, we will continue into a practice session where we set up a scenario, within which we work with a basic OLAP report, to expose the steps involved. In examining the rudiments of specific function parameterization within an OLAP report containing a matrix data region, we will:
- Open the sample Report Server project, AdventureWorks Sample Reports, and ascertain connectivity of its shared Analysis Services data source;
- Create a clone of an existing sample report, containing a matrix data region, with which to perform our practice exercise;
- Make structural modifications to the clone report, to prepare for our practice exercise session with parameters within a matrix data region;
- Perform a brief overview of the MDX LastPeriods() function, which we will use to support the stated reporting needs of a hypothetical client;
- Discuss the parameterization of MDX functions in general, and the LastPeriods() function specifically;
- Add the required query parameters to support date and function parameterization;
- Ensure the adequacy of automatically created datasets to support report parameters and meet business requirements (in Part II of this article);
- Add syntax to the TimeMonth dataset query to enforce cascading (in Part II of this article);
- Leverage the MDX LastPeriods() function, containing the month parameter placeholder(in Part II of this article);
- Discuss the interaction of the various components in supporting the runtime parameters that the end consumer sees (throughout Part I and Part II of this article);
- Discuss the results obtained with the development techniques that we exploit (throughout Part I and Part II of this article).