Last month, in “Information Integration: SSRS
and MOSS 2007” (InstantDoc ID 96840), I introduced
you to the rich information-integration
environment available with SQL Server 2005 Reporting
Services (SSRS) SP2 and Microsoft Office SharePoint
Server (MOSS) 2007 Enterprise Edition. After looking
at the technical architecture that takes reporting to new
levels, I walked you through installing and configuring the
components required to integrate SSRS and MOSS.
This month, in the second article in this two-part series,
l show you how to perform familiar SSRS tasks—such
as deployment, security setup, and property management—
in the new MOSS environment. I also explain how
to implement new MOSS-enabled reporting features such
as versioning, workflow, alerts, and information management
policies as well as how to use information-integration
features. Taking advantage of SSRS and MOSS integration
will not only let your information workers more easily
find, use, and share information across the enterprise, but
it will also simplify your report management and security
implementation tasks.
Deploying Reports and
Data Sources
To deploy resources from Business Intelligence Development
Studio (BIDS), you must first install SP2 on each
developer’s workstation to update the designer tools.
These updated tools add the components that the design
environment requires to connect to MOSS for report,
model, and data source deployment. You’ll still be able
to deploy items to a native-mode SSRS instance if you’re
maintaining multiple report server instances.
You can deploy report definitions in MOSS integrated
mode in two ways. First, you can use BIDS to deploy
them directly to
the MOSS libraries
by changing your
report server project’s
properties to
reflect the target document libraries, as Figure 1 shows.
Notice that the folder references are different from nativemode
deployment requirements. Even when deploying to
the same server, you must specify the server name explicitly
in the URLs instead of using localhost. Alternatively,
you can deploy reports by opening the document library,
clicking Upload, and selecting a report definition file to
add to the library.
You can also deploy report data sources from BIDS,
but you can’t upload them directly to the Data Connections
library. If you choose not to use BIDS deployment,
your only other option is to manually create the
data source—a method some organizations require. For
manual creation, navigate to the Data Connections library.
On the New menu, select Report Data Source. On the
Data Source Properties page, assign a name, provider type,
connection string, and credentials. Windows Authentication
(Integrated) credentials work only if you’ve enabled
and configured Kerberos in your domain.
MOSS adds all new data sources in Pending mode,
which means that only the author and users with Manage
Lists permission can use the data source until it is
approved. To change the status of the data source, point
to the data source name, click the down arrow to open
the context menu, and click Approve/Reject. On the Data Connections page, you can set the status as applicable. As
long as the data source remains pending, users will get an
rsAccessDenied message when executing a report linked
to the data source.
To deploy a report model to a library, change the
report model project properties, as Figure 2 shows. The
report model is accessible for ad hoc reporting when a
user with the appropriate permissions opens the applicable
document library and selects Report Builder Report on
the New menu. When Report Builder opens, it displays
a list of report models in the current library, but the user
can change to an alternative location to list other available
models. Users can save Report Builder Reports to a document
library as long as they have permission to do so.
Setting Up Security
When you’ve deployed your reports and data sources,
you’re ready to address security. The most straightforward
approach to defining security policies for your reports is to
use the default SharePoint groups and permission levels.
Table 1 describes the default security policies by group
and permission level.
SharePoint security starts at the top-level site, with
libraries and library contents inheriting security policies
for ease of maintenance. Within the site, you map Windows
groups or users to a permission level for each library
or library item—much like using the role-based security
model in native mode. To override the inherited permissions
for an entire selected library, open Internet Explorer,
navigate to the Reports library on your MOSS site (e.g.,
http://your_server/ReportsLibrary), click Settings, and
then click Document Library Settings. On the Customize
Reports Library page, in the Permissions and Management
section, click Permissions for this document library.
On the Permissions page, you can add or remove users and
change permissions. To add a new user, click Actions, click
Edit Permissions, and click OK to confirm that you want
to override site permissions and create unique permissions
for the Reports library. Now, you can add new users by
clicking New and providing user or group names. You
then either associate the new user or group with an existing
SharePoint group so that the user inherits the appropriate
permission level, or you can explicitly assign a permission
level. To remove a user, on the Permissions page, select
the check box to the left of each user you want to remove,
and then click Actions, click Remove User Permissions,
and click OK to confirm. To edit permissions for a user
or group, simply click the user or group name and select
the applicable permissions on the Edit Permissions page.
If you need to manage security for each report separately,
you can open a report’s context menu (by clicking
the down arrow to the right of the report name), click
Manage Permissions, and edit the permissions to apply
item-level security. Simply click Site Actions in the upper
right corner, point to Site Settings, and click People and
Groups. Select the current name in the page title, select a
different group from the list on the left side of the page,
and then use the New menu to add new users or groups
to the selected group. Of course, you can also create
your own SharePoint groups and permission levels. On
the Settings menu, click Set Up Groups to create a new
group and assign a permission level. To create a custom
permission level, click Site Permissions on the left of the
Site Settings page, and then from the Settings menu, click
Permission Levels. On this page, you can add a new permission
level or edit existing permissions levels to apply
very granular security policies.
If you’re using report models, you already know that
you can define model item security in the Model Designer,
but now you can also use SharePoint if your login is in a
group that’s been assigned Full Control. From the report
model’s context menu, click Manage Model Item Security.
In the Model Item Security page, you explicitly add
permission at the root node for all Windows groups or
users authorized to use the model. Entities and attributes
inherit this permission. Then, for any group or user not
authorized to view a particular entity or attribute, you can
select that item in the model tree and assign permissions to all other groups or users that have authorization. Note
that you can’t deny access to a user; instead, you must
explicitly grant permissions to a user or allow the user to
inherit permissions from a parent item.
Prev. page
[1]
2
3
4
next page 
