BlackBelt Administration: Linked Reports in Report Manager

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"),
with the objective of presenting an overview of its features, together with tips
and techniques for real-world use. For more information on the series, please
see my initial Database
Journal article, A New
Paradigm for Enterprise Reporting.

As I
have stated since the charter article of the series, published about the time Reporting
Services was first publicly released, my conviction is that Reporting
Services will commoditize business intelligence, particularly in its role
as a presentation component within an integrated Microsoft BI solution.
Having been impressed from my first exposure to this exciting application, when
it was in early beta, my certainty in its destiny grows stronger by the day, as
I convert formerly dominant enterprise business intelligence systems, such as Cognos,
Business Objects / Crystal, MicroStrategy, and others, to the Reporting
Services architecture. I receive constant requests to conduct strategy
sessions about these conversions with large organizations in a diverse range of
industries – the interest grows daily as awareness of the solution becomes
pervasive. Indeed, the five- to six-plus figures that many can shave from their
annual IT budgets represent a compelling sweetener to examining this incredible
toolset.

Note: To follow along with the steps we
undertake within the articles of this series, the following components, samples
and tools are recommended, and should be installed / accessible, according to
the respective documentation that accompanies MSSQL Server 2005:

Server Requirements

• Microsoft SQL
  Server 2005 Reporting Services

• Microsoft SQL
  Server 2005 Database Services

• The
  AdventureWorks sample databases (relational and Analysis Services)

• Microsoft SQL
  Server 2005 Analysis Services

Client Requirements

• Microsoft
  Internet Explorer 6.0 with scripting enabled

• Business
  Intelligence Development Studio (optional)

Sample Files

For purposes of the
practice exercises within this series, we will be working with samples that are
provided with MSSQL Server 2005. The samples with which we are
concerned include, predominantly, the Adventure Works DW sample databases
and other samples. This database and companion samples are not installed by
default in MSSQL Server 2005. The samples can be installed during Setup,
or at any time after MSSQL Server has been installed.

The topics "Running
Setup to Install AdventureWorks Sample Databases and Samples" in SQL
Server Setup Help or "Installing AdventureWorks Sample Databases and
Samples" in
the Books Online (both of which are included on the installation CD(s), and
are available from www.Microsoft.com and other sources, as well),
provide guidance on samples installation. Important information regarding the
rights / privileges required to accomplish samples installation, as well as to
access the samples once installed, is included in these references.

About the BlackBelt Articles …

As I
have stated in earlier BlackBelt articles, one of the greatest
challenges in writing tutorial / procedural articles is creating each article
to be a freestanding document that is complete unto itself. This is
important, because it means that readers can complete the lesson without
reference to previous articles or access to objects created elsewhere. When
our objective is the coverage of a specific technique surrounding one or more
components of a report, a given administrative function surrounding reports in
general, and other scenarios where the focus of the session is not the creation
of reports, per se, challenges can arise because a report or reports often
has to be in place before we can begin to cover the material with which the
article concerns itself.

The BlackBelt
articles represent an attempt to minimize the setup required in simply getting
to a point within an article where we can actually perform hands-on practice
with the component(s) or method(s) under consideration. We will attempt to use
existing report samples or other "prefabricated" objects that either
come along as part of the installation of the applications involved, or that
are readily accessible to virtually any organization that has installed the
application. While we will often have to make modifications to the sample
involved (we will actually create a copy, to allow the original sample to
remain intact), to refine it to provide the specific backdrop we need to
proceed with the object or procedure upon which we wish to concentrate, we will
still save a great deal of time and distraction in getting to our objective.
In some cases, we will have to start from scratch with preparation, but my
intention with the BlackBelt articles will be to avoid this, if
at all possible.

For
more information about the BlackBelt articles, see the section
entitled "About the BlackBelt Articles" in BlackBelt
Components: Manage Nulls in OLAP Reports.

Overview

As administrators of enterprise
reporting systems can attest, management of the business intelligence solution does
not end when we deploy / publish the reports to the Report Server.
Within Reporting Services, many properties and options can be set and
maintained at the Report Server level, through the Report Manager,
or an alternative interface. Even in the simplest implementations, there is
typically at least some need to exercise control over what information
consumers can access. This is often initially handled through the management
of folder security, which comes "out of the box" with Reporting
Services, and often provides a great starting point for new
implementations: we can thus get started with the presentation layer of a
business intelligence system, affording the organization the capability to
gather business requirements and develop reports that consumers can "road
test." Progress can thus be taking place toward the crafting of a report
library, in the developmental meantime, regardless of the ultimate report
delivery mechanism (dashboards, scorecards, portals, other customized
interfaces, or combinations of these things). It is often to our advantage to begin
development quickly, and to deliver reports that can be executed by users, who
can be feeding them back with their input, as we continue to rapidly turn out
the new report library.

A common scenario I come
across in implementing Reporting Services lies in using folder
security to control report access, at least within the development cycles,
and sometimes beyond. In many cases, the reports that reside in a given
folder, say for the corporate finance department, are totally different from
reports that are deployed within, for instance, the folder designated to
inventory management. However, we often encounter situations where the same
report may need to be placed within multiple folders. Placing duplicates of
the same report in the folders involved might seem like a simple solution, but
can lead to added overhead from an administration perspective when events, such
as report modifications, occur.

Reporting Services offers a way to handle this
without the overhead: Linked Reports. When we use Linked Reports,
we create a single "master" report, and then deploy the .rdl file to
a single folder. We then create Linked Reports within the other folders
from which access to the report is required. The concept of Linked Reports
becomes quite attractive when we come across needs to make either identical or
multiple versions of the same report available in various folders – a
capability that has proven itself quite popular with many of my clients who
faced scenarios such as the need to provide an identical (in layout / format)
sales report to numerous departments, regions or even individual salespersons,
but with each report’s contents specific to the department, region or
salesperson accessing or receiving it. Linked Reports allow us to
provide this capability to our clients and / or the consumers within our
organizations with ease, while affording a single point of actual deployment
and centralized administration.

In this article, we will get some hands-on exposure to Linked
Reports. We will discuss the general concepts, and then set up a scenario
within which we deploy a sample report, and then perform the steps of setting
up Linked Reports in multiple folders. As a part of our examination of the steps involved in
establishing Linked Reports within Reporting Services, we will:

• Open the
  sample Report Server project, AdventureWorks Sample Reports, and ascertain connectivity of its
  shared data source;

• Create a clone
  of an existing sample OLAP report, with which to perform our practice exercise;

• Make limited structural
  changes to the clone report, based upon a sample SQL Server Analysis
  Services cube, to meet the business requirement of a hypothetical group of
  information consumers to use it as a basis for Linked Reports;

• Preview the clone
  report to ascertain its readiness for deployment;

• Deploy the report
  to a common folder within Report Manager;

• Create folders
  in Report Manager, to house Linked Reports for different consumer
  groups;

• Create Linked
  Reports within the new consumer group folders, based upon the common source
  .rdl file;

• "Hard code"
  a default, hidden parameter within each Linked Report to restrict
  the data to the intended consumer group audiences;

• Preview a Linked
  Report to ascertain the effectiveness of our solution.