Introduction to the Managing Phase
We
learned in the previous two-part article, The
Authoring Phase: Overview,
that a report definition is created by a developer via the Report
Designer (or, optionally, another authoring tool that leverages the Reporting
Services API). We overviewed connection, query, layout and other aspects
of the design process, within the creation of a tabular report as a practice
exercise. After Authoring, the next phase in the report development
life cycle, at least for reports that are managed in the first place, is
Managing, where the report is processed and rendered.
As we might imagine,
there are many variations and options in the steps involved, but, in general, publication
of the new report definition to a Report Server designates it as a managed
report. In addition to being saved on a Report Server, managed
reports are associated with meta data, and have properties, that
allow actions to be taken with them, including:
-
scheduling
-
linking to other reports
- application of security
-
movement to various locations
-
renaming, deletion and other
file maintenance
We can think of
processing as taking place in the following general sequence:
-
Extraction of the data as
specified in the definition (rdl)
-
The marriage of the data to the
report layout we have defined
-
The rendering of the output, as
an information product in a desired presentation format.
Once the report is
generated (and this can be arranged to happen on a schedule we establish, or
upon demand by an information consumer, or even both), the report can be delivered
to, or accessed by, consumers in a number of ways. We will discuss these
options, and some of the processes involved in their operation, in a subsequent
article that focuses on report access and delivery.
In this
article, we are going to get a good look at the centralized management of
reporting that becomes a reality with Reporting Services. In the middle of it
all is the Report Manager, with which we will become familiar over this
and subsequent articles. We already mentioned, in the introductory article to
this series, that reports can be uploaded to the report server easily
from either the Report Designer or the Report Manager; we also
noted that the reports can be viewed thereafter via a web browser. Multiple
types of security can be assigned during the upload process, as well as
elsewhere, for welcome (and rare) flexibility. We will explore these and other
features, as well as the degrees of management and administration
considerations that make the overhead involved with Reporting Services widely
customizable to an organization's needs. We will even examine some aspects of report
server administration within the context of management, providing a preview of
more detailed examinations that we will undertake with this component in
subsequent articles.
Let's get
started with our examination of the Managing phase and get a taste of
the future that is today with Reporting Services. Because this article
focuses on management of reports that are already designed (and in
keeping with our objective to make articles "free-standing" with
regard to readers being able to participate in each without having joined us in
previous articles), we will work with the set of report samples that accompany Reporting
Services.
Accessing the Sample Reports
To use the
sample reports, we must first install them as a part of Reporting Services
Setup. When we installed Reporting Services, we were given this
opportunity, with the default installation point for the files being the Samples
folder within the Reporting Services program folder. A common example of this
default path is as follows:
C:\Microsoft SQL Server\MSSQL\Reporting Services\Samples\Reports
The
documentation for the sample reports (search on "Samples" in the Reporting
Services Books Online) informs us that, although the reports are installed,
they are not deployed automatically to the Report Server. Since our Managing
phase articles concern themselves with this process, in part, and with managing
reports that are already created in general, the sample reports present an
excellent vehicle by which we can focus on managing, and avoid the diversion of
designing considerations. The MSSQL Server 2000 Reporting Services series will
afford us, as it progresses, many opportunities to design and write reports
that are targeted to specific business needs. Check back frequently to see how
I meet real world requirements, within illustrative contexts that have a
particularly practical flavor.
If you have already begun
to explore managing reports, and have deployed some or all of the samples by
manually uploading, using scripts, or publishing via Report Designer, we
can still use the sample files in our practice exercises. Simply rename
copies, locate them differently, or whatever other action fits your local
constraints, and perform the steps along with the rest of us, with your
variations in mind as you publish, save, and so forth.
Note: If you did not choose to
install the samples during Setup, it might be a good idea to do so at
this point, keeping in mind, as you run Setup again, the location to
which you choose to direct them. The Samples shortcut that is normally
installed in the Reporting Services program group of the Start menu,
along with the shortcut to the Report Manager URL in the browser, can be
useful, and we will refer to it occasionally within the series. This makes the
location of the files a little less of a memory chore, but we can certainly
customize our manner of arriving at these destinations in any way we choose.
Let's
upload the samples as a part of achieving the objectives of the practice exercises
in this lesson, as well as in preparation for exercises we will share in future
Managing articles. We will use Report Manager versus the Report
Designer interface, but rest assured we will get experience from loading
with the latter of the two options many times, as the series evolves.