Using Reporting Services SharePoint Web Parts in SQL Server 2000 Reporting Services Service Pack 2

SQL Server 2000 Technical Article
Author: Duncan Smith, IdentityMine
Technical Reviewer: Brian Welcker, Microsoft
Project Editor: Kathy MacDonald, Microsoft

Applies To:
Microsoft SQL Server 2000
Microsoft SharePoint Products and Technologies
Microsoft Windows SharePoint Services
Microsoft Office SharePoint Portal Server 2003

Note

For information on using Reporting Services SharePoint Web Parts in SQL Server 2005, see Viewing Reports with SharePoint 2.0 Web Parts in SQL Server 2005 Books Online.

Summary: This article describes the new SharePoint Web Parts included with SQL Server 2000 Reporting Services Service Pack 2. It includes information about installing the Web Parts, ways to use them, features they support, and troubleshooting procedures. The SQL Server 2000 Report Packs are used as examples.

Intended Audience: This document assumes that you have basic experience with Reporting Services and SharePoint, and that you are familiar with running programs from the command line. The Technical Details section is also targeted at software developers who are interested in more in-depth information, but you can safely skip that section without missing any of the main points.

On This Page

Introduction
Scenarios
Tips and Tricks
Installing the Web Parts
Features
Technical Details
Troubleshooting
References
Acknowledgements

Introduction

The main strength of Web-based reporting is the ability to make up-to-date information available to a distributed group of users. SQL Server Reporting Services is Microsoft's server-based reporting solution. While Reporting Services provides a way for people to find and view reports, the Reporting Services interface may not be the most appropriate one for all report users. For example, someone who uses reports frequently may be familiar with the layout of the report server because they spend a lot of time navigating around it. On the other hand, another user might be very interested in one particular report, but may not know where to find it. A third user may need information that is already available on the report server, but may not even know that this information exists.

One way to present information on the Web is through a portal, a single point of entry that facilitates navigation of Web-based information. Microsoft's SharePoint products allow users to create Web portals without any programming. An important SharePoint concept is the Web Part. From a SharePoint user's perspective, a Web Part is a component of a portal that displays specific information, and can be moved around the page during the design process. For example, SharePoint comes with Web Parts for displaying information such as announcements, contacts, events, and images. SQL Server 2000 Reporting Services Service Pack 2 includes two Web Parts: an Explorer for navigating a report server, and a Viewer for viewing reports. This paper will show you how to use these two Web Parts to:

• Save time by embedding frequently-used reports on a SharePoint page.

• Provide a simplified interface to your report server to encourage new users to take advantage of existing business intelligence.

• Combine the Report Explorer and Viewer with other Web Parts to build a comprehensive portal.

Figure 1: The Report Explorer and Report Viewer Web Parts

Report Explorer

The Report Explorer Web Part allows you to navigate the report server and select a report to view. It is essentially a scaled-down version of the Report Manager that comes with Reporting Services. The Report Explorer can operate in one of two modes: connected to a Report Viewer, and standalone. The Explorer's mode determines what happens when you click on a report link. In connected mode, the report shows up in the Viewer that the Explorer is connected to. See the next section for more on this mode. In standalone mode, the report shows up in a new browser window. Which mode you choose depends on the layout of your site. For example, if screen real estate is tight, you may only have room for the Explorer on your SharePoint page. On the other hand, it may be less confusing for some users to have their report appear on the current page rather than in a new window.

In addition to providing a view into the report server, the Explorer allows you to subscribe to reports directly from the Web Part. When in Detail View, the Explorer has a new column called Subscription. Each report that you are allowed to subscribe to has either a New Subscription or an Edit Subscription icon in the Subscription column. The Edit Subscription icon means you have already subscribed to the report. In keeping with the goal of providing a simplified interface, the Explorer only allows one subscription per report.

Report Viewer

The purpose of the Report Viewer Web Part is to display a report. The Viewer supports the same two modes as the Explorer. In connected mode, the Viewer displays the report whose link you click in the Explorer. Connections are a Web Part concept that simply means that data is passed from one Web Part to another. In this case, the data in question is a link to the selected report. When the Viewer is in standalone mode, it has no Explorer to tell it which report to display. Therefore, you must enter the path to the report manually. The Viewer supports this through its tool pane, a Web Part configuration window that allows you to modify various settings. The advantage of this mode is that each Viewer on the page can display a particular report or a set of reports without user intervention. This is useful when visitors to your portal page are only interested in certain reports.

Scenarios

This section describes fictional examples of how people might use the RS Web Parts.

Embedded Report in a SharePoint Page

Hang, a Software Test Engineer working in the Microsoft Exchange team, uses SharePoint to provide status on QFE (Quick Fix Engineering) bugs that affect his team. On the main page of his team's SharePoint site, he wants to show a Reporting Services report that displays bugs resolved in the past week. He has deployed the Report Viewer Web Part to his SharePoint site. He configures an instance of the Web Part to point to the desired report and configures SharePoint to show this Web Part by default on the home page. He decides not to deploy the Report Explorer, which gives him room to maximize the size of the Viewer. This is an acceptable tradeoff because the Viewer always displays the report that the testers on his team need to see.

Discover and View a Report from a Report Server

Marissa is a researcher at the University of Washington School of Medicine. She uses a SharePoint site to keep track of experiment results. When a researcher in her department starts a new experiment, the researcher uses Report Manager (not the Web Parts) to publish a report on the experiment to the report server. Marissa has a SharePoint page containing the Report Explorer and Viewer Web Parts. Using the Explorer, she can find the reports that her colleagues publish using Report Manager. She can then view these reports in the Report Viewer.

Configure Delivery of a Report in SharePoint

Maria, an accountant at the University of Washington School of Medicine, is responsible for tracking expenses related to monthly experiments and issuing reimbursements for any out-of-pocket expenses the researchers have filed. An expense report is created to determine who is owed money. It is executed automatically on the 16th of the month. In the experiment tracking SharePoint site, Maria subscribes to the report through the Report Explorer subscription interface. The report is delivered to her through e-mail whenever it is executed. A few years later when her job duties change, she accesses her list of reports in Report Explorer and deactivates the subscriptions of those that she no longer wants to receive through e-mail.

Tips and Tricks

This section lists some examples of best practices using the Web Parts and other SharePoint components.

Web Part Layout in SharePoint

One of the goals of the Reporting Services Web Parts user interface design is to provide a simplified version of the Report Manager interface. For example, the Report Explorer does away with the area above the toolbar in Report Manager. The breadcrumb from that area moves to the toolbar, the Detail/List view toggle from the toolbar moves to the Tool Pane (which only opens when needed), and the Subscriptions tab becomes a New Subscription/Edit Subscription link in the content area. The Report Viewer does its part to conserve screen real estate by providing an option to shrink or eliminate its toolbar. Despite these changes, space is often at a premium on a SharePoint page because SharePoint has its own navigation controls. This section presents several layout examples. The example screen shots use a screen resolution of 1024x768. This is, by some estimates, the most popular screen resolution among worldwide users (see https://www.onestat.com/html/aboutus_pressbox31.html).

Standalone Explorer

A standalone Explorer Web Part on a SharePoint page is useful when the report server contains a large number of reports and folders, and the target user is familiar with the structure of the server content. This layout provides the maximum amount of space for navigating the server content, and viewed reports get an entire browser window. See the Features section, Report Explorer subsection, for an example of this layout.

Standalone Viewer

A standalone Viewer Web Part is useful when page visitors are likely to be interested in a particular report. The maximum amount of space on the page is available for that report, and you can bookmark a particular page so you always have the latest report content with minimal effort required. See the Features section, Report Viewer subsection, for an example of this layout.

Connected Explorer and Viewer

An Explorer connected to a Viewer with no other Web Parts on the page gives you the flexibility to choose the report that you want to see, but still leaves enough page area for a reasonable browsing and viewing experience. The page designer should consider where on the page each Web Part should be placed. Figure 2 shows the Explorer on the left and the Viewer on the right. In this configuration, the Explorer should be placed in List View mode, to minimize horizontal scrolling. Both columns of report names and descriptions are visible. In the Viewer, the Balance Sheet report fits well in the available horizontal space. Also, the toolbar and parameter area can be closed if desired to provide more vertical room. To create this page layout in SharePoint, select the Header, Left Column, Body layout. The Explorer then goes in the left column, and the Viewer goes in the body. The header is visible in design mode, but does not appear in view mode as long as you don't put anything in the Header zone.

Figure 2: Explorer on the left, Viewer on the right

Figure 3 shows the Explorer on top and the Viewer on the bottom. This reduces the available report viewing area, but it allows us to put the Explorer in Detail View. To create this page layout in SharePoint, select the Full Page, Vertical layout. Add the Explorer first, and then the Viewer. Adjust heights as needed in the Appearance section of the Tool Pane. Notice the large area of wasted space on the right side of the viewer. If your reports are formatted like this Balance Sheet report, it probably makes sense to use the left/right layout instead of the top/bottom one.

Figure 3: Explorer on top, Viewer on the bottom

Embedded with Other Web Parts

The layout examples above are easy cases because there is plenty of room for both Web Parts. However, many SharePoint pages are designed to consolidate a lot of information in one place. In these situations, the RS Web Parts may need to share screen real estate with a number of other Web Parts. This example shows a financial portal that could be made accessible on a company's extranet for investors to access securely. SharePoint provides an easy way to make information available to external users, simply by configuring your Web server appropriately.

Figure 4 shows a standalone Report Viewer (in the bottom left corner), along with two other Web Parts. The other Web Parts are:

• Scorecard (top left): This Web Part was created using the Office Business Scorecards Accelerator (see https://www.microsoft.com/office/solutions/accelerators/scorecards/default.mspx). This tool allows non-technical users to create scorecards, which are reports that show visual representations of key performance indicators (KPIs) using data from Microsoft SQL Server Analysis Services. Because KPIs are designed to provide information about high-level business trends, the Scorecard Web Part is ideal for the kind of portal shown in this example.

• Office Web Component (top right): This Web Part was created using Office Web Components (see https://www.microsoft.com/downloads/details.aspx?familyid=7287252C-402E-4F72-97A5-E0FD290D4B76 and https://www.microsoft.com/downloads/details.aspx?familyid=38BE67A5-2056-46A1-84B1-337FFB549C5C&displaylang=en). Because OWC technology includes Web Parts, Office Web Components can be used on a SharePoint page. Users who have Office installed on their client computers can even interact with the graph or report. For example, the report dates in the Net Income graph can be specified using the Calendar Year, Calendar Quarter, and Month drop-down menus.

• Document Library Web Part (bottom right): This standard SharePoint component is a Web Part version of the frequently-used SharePoint Document Library. It is simply a view into documents that are stored in SharePoint.

As you can see in the screen shot, fitting even four Web Parts into a 1024x768 window requires some extra scrolling to see all of the information. However, the point of this layout is to present a summary of information. You can consult views like those shown previously in this section to drill down on details. Also, reports that are expected to be shown on top-level portal screens like this one can be modified for display in a smaller area.

Figure 4: Portal Page in Shared View

Personalizing a Portal Page with Embedded Reports

SharePoint allows Web Part designers to restrict configuration options based on how a user accesses the page. You can see one example of this using the portal page shown above. If you click Modify Shared Page, and then click Personal View, the page switches to the view that a user might see. Next, click the Report Viewer Web Part menu, and click Modify My Web Part. Notice that the menu label has changed from Modify Shared Web Part to indicate that you are personalizing the page for one user, not for everyone who visits the page. In Figure 5, notice that the Tool Pane only shows three categories – Configuration, Appearance, and Layout – and that the Configuration category only has one configuration option, Toolbar Size. The Shared View Tool Pane also had an Advanced category, and the Configuration category also allowed the page designer to set the Report Server URL and Report Path. So the Personal View user can modify the toolbar size, but cannot point the Viewer to another server or report.

Figure 5: Portal Page in Personal View

Switching to another report in the Viewer Web Part

Figure 6 shows the process for switching from one report to another in a standalone Viewer. The first screen shot (top left) shows the Variance Analysis report. Click Modify Shared Web Part to open the Tool Pane. Click in the Report Path box, and then click the Build button (…) to open the Text Entry dialog. Enter the new report path, being sure to use a leading slash (/). Click OK in the Text Entry dialog, and OK in the Tool Pane. The Tool Pane closes, and the Viewer displays your new report.

Figure 6: Switching reports in the Viewer

Modifying Report Layout within the Viewer Web Part

All of the layout options that are available in Report Manager's report viewer are also available in the Viewer Web Part. Figure 7 shows the Income Statement with some categories expanded, and the zoom level set to 75%.

Figure 7: Layout options in the Viewer

Using the Start Path Property

The Explorer Web Part includes a configuration property called Start Path that defines the top level folder on the report server that you can access through the Explorer. Using the Report Packs example, you could set the Start Path to /Microsoft SQL Server Report Pack for Financial Reports. This restricts users to the Financial Reports section of the report server, preventing them from accessing the CRM or Exchange reports. Of course, this assumes that users don't have access to the regular Report Manager interface.

Figure 8 illustrates this example. In the Report Explorer, notice that the only entry in the toolbar is Home. This shows that you are at the current home folder, and you cannot move up in the folder tree. Also notice the Modify Shared Page indicator in the top right corner of the screen. A user who views the page in personal mode would not be able to modify the Start Path.

Figure 8: The Start Path property

Installing the Web Parts

System Requirements

The Web Parts consist of two components: enhancements to the Report Manager, and the SharePoint Web Parts themselves. The Report Manager enhancements are installed on the computer running SQL Server Reporting Services, and the Web Parts are installed on the computer running SharePoint. These can be separate computers or the same computer. However, the Report Manager component must be installed in conjunction with the SharePoint component. If you point the SP2 Web Parts to a pre-SP2 report server, or a SQL Server 2005 report server, the user interface will not work correctly. Also, see the Troubleshooting section if you are considering installing SharePoint and Reporting Services on the same computer.

The Web Parts will work with either SharePoint Portal Server 2003 or Windows SharePoint Services. In this document, the term SharePoint refers to either of those products. The Web Parts only uses the subset of SharePoint features found in Windows SharePoint Services. They are not compatible with SharePoint Team Services or SharePoint Portal Server 2001 (the previous SharePoint products).

Minimum system requirements for the Web Parts are the same as the minimum requirements for the underlying technologies. Table 1 summarizes the requirements.

Computer	Report Server	Windows SharePoint Services	SharePoint Portal Server	Client (IE 6.0 SP1 or later)
Processor	500 MHz Pentium II	Pentium III	700 MHz Pentium	Intel 486/66 MHz
Operating System	Windows 2000 SP4; Windows XP SP1	Windows Server 2003	Windows Server 2003	Windows 98 or later
Database	SQL Server 2000 SP3	SQL Server 2000 SP3	SQL Server 2000 SP3	N/A
Memory	256 MB	512 MB	512 MB	16 or 32 MB
Hard Disk	325 MB free	550 MB free	575 MB free	8.7-12.7 MB free

For more information on system requirements, see the following pages:

• Reporting Services: https://www.microsoft.com/sql/technologies/reporting/default.mspx

• Windows SharePoint Services: https://www.microsoft.com/windowsserver2003/techinfo/sharepoint/sysreqs.mspx

• SharePoint Portal Server: https://www.microsoft.com/office/sharepoint/prodinfo/sysreq.mspx

• Internet Explorer: https://www.microsoft.com/windows/ie/evaluation/sysreqs/default.mspx

Installation Process

This is a summary of the SP2 installation process. For more detailed instructions, see the readme file included with the SP2 setup.

On the report server, use this process:

1. Obtain and extract the Service Pack 2 self-extracting file. For instructions on how to obtain this file, see the Reporting Services Web site at https://www.microsoft.com/sql/reporting/.

2. Back up your reportserver and reportservertempdb databases and the database encryption keys.

3. Run SP2 setup from the location where you extracted the files, and follow the instructions.

4. Restart (if prompted).

On the SharePoint server, type the command shown below at the command prompt. Modify the directory names as needed if you have modified your default program files or installation directories. If your SharePoint server is a different computer from your report server, you can copy the RSWebParts.cab file from your report server to a location where your SharePoint computer can access it. Alternatively, you can download this file from the SharePoint Products and Technologies Web Component Directory at https://www.microsoft.com/downloads/details.aspx?FamilyID=38be67a5-2056-46a1-84b1-337ffb549c5c&DisplayLang=en.

"C:\Program Files\Common Files\Microsoft Shared\web server 
extensions\60\BIN\stsadm.exe"
-o addwppack -force –filename "C:\Program Files\Microsoft SQL 
Server\80\Tools\Reporting Services\SharePoint\RSWebParts.cab"

Stsadm.exe is an administration tool for SharePoint. The addwppack operation adds a Web Part Pack to a SharePoint site. The –force flag tells stsadm to add the specified Web Part Pack even if one with the same name already exists, so you can run this command multiple times. The –filename flag specifies the path to a cabinet file containing the Web Part Pack files. The RSWebParts.cab file is installed into the specified directory by the SP2 setup program.

Add and configure the Web Parts on a SharePoint site as follows:

• From an existing site in SharePoint, click the Create button in the SharePoint toolbar.

• Scroll down to the Web Pages section, and click Web Part Page.

• Enter a name, and select a layout and location (Document Library). You may need to create a Document Library first if none are available. The Full Page, Vertical layout is a good choice to provide the maximum amount of screen real estate for the Web Parts.

• Click the Create button.

• In the Add Web Parts Tool Pane, click Virtual Server Gallery. This is the default location where Web Parts are installed by stsadm. See Figure 9 for an example of how this should look. Your Web Part List may contain different Web Parts depending on what you have installed on your SharePoint computer.

• The Web Parts appear in the Web Part List as Report Explorer and Report Viewer. Drag and drop each Web Part onto the page in the desired locations. For example, if you chose the Full Page, Vertical layout, you might want to place the Report Explorer at the top of the page and the Report Viewer directly under it.

  Note: If you get an error message when you try to add a Web Part to the page, see the Troubleshooting section at the end of this document.

• If you have Reporting Services and SharePoint installed on the same computer, then the Report Explorer should already show a view of the objects on the server. If your report server is a different computer, then identify it as follows:

  • On the Report Explorer Web Part menu, click Modify Shared Web Part.

  • In the Report Explorer Tool Pane, in the Configuration section, enter your Report Manager URL. This value is set to https://localhost/Reports by default. If your SharePoint computer is also running Reporting Services, this will point to the default Report Manager page. Otherwise, you will need to modify it to point to the desired report server.

  • Click OK.

• In general, you want to adjust the size of the Report Viewer because the default Web Part size does not provide much room to see a report. Here is the process:

  • On the Report Viewer Web Part menu, click Modify Shared Web Part.

  • In the Tool Pane, expand the Appearance category.

  • In the Height section, enter a height. A reasonable value is 400 pixels.

• With the Report Explorer Tool Pane still open, connect the Explorer and the Viewer as follows: On the Report Explorer Web Part menu, point to Connections, point to Show report in, and click Report Viewer.

• In the Tool Pane, click OK.

• On the Modify Shared Page menu, click Design this Page to cancel the selection. You should now be able to click on a report in the Report Explorer and see it displayed in the Report Viewer.

Figure 9: The Virtual Server Gallery

Other Installation Issues

Installing to the GAC

The stsadm command shown above installs the RS Web Part package to the bin directory of all Windows SharePoint Services-enabled virtual servers on the local computer. If you want to install the Web Parts on a specific virtual server, specify the URL of this virtual server using the –url flag. If you want to install the Web Parts on all SharePoint-enabled virtual servers, you can also use the –globalinstall flag. Instead of installing the Web Part package to the bin directory of each virtual server, stsadm will install it to the Global Assembly Cache (GAC). The GAC stores assemblies that are intended to be used by multiple applications on the same computer. The MSDN article "Packaging and Deploying Web Parts for Microsoft Windows SharePoint Services" (https://msdn2.microsoft.com/library/ms950404.aspx) recommends that a Web Part package should meet the following two conditions in order to be installed in the GAC:

• You want it to be available to all virtual servers on the computer;

• You trust the assemblies and resources of the package completely.

• Furthermore, the "Global Assembly Cache" topic (https://msdn2.microsoft.com/library/yf1d93sz(vs.71).aspx) in the .NET Framework Developer's Guide recommends that you should "locate assemblies in the application directory unless sharing an assembly is explicitly required." Also, it points out that installing assemblies in the GAC can make it more complicated to move applications from one computer to another using xcopy.

  Note: that the term virtual server in this context refers to a Microsoft Internet Information Services (IIS) virtual server, not the Microsoft Virtual Server 2005 virtual machine product. IIS supports multiple virtual servers on one computer. To the user, each virtual server appears to be a separate HTTP server, and may have its own domain name and IP address. SharePoint may be enabled on some virtual servers and not others on the same computer, and the RS Web Parts may be installed on some SharePoint-enabled virtual servers and not others.

Registering Web Parts as Safe

If you install the Web Parts on one virtual server and then try to add them to a page on another virtual server, you will receive the following error message:

A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as safe.

The easiest way to fix this problem is to install the Web Parts to the desired virtual server using stsadm. If you want to fix the problem manually, use Notepad to edit the web.config file under the target virtual server's home directory, and add the following element to the <SafeControls> section:

<SafeControl Assembly="RSWebParts, Version=8.0.242.0, Culture=neutral,
PublicKeyToken=89845dcd8080cc91"
Namespace="Microsoft.ReportingServices.SharePoint.UI.WebParts"
TypeName="*" Safe="True" />

If you have the .NET Framework Strong Name Utility installed (for example, as part of a Visual Studio installation), you can verify that the PublicKeyToken attribute is accurate by running the following command from the directory containing RSWebParts.dll.

C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\sn –T 
RSWebParts.dll

If adding the <SafeControl> element doesn't fix the problem, see the Troubleshooting section in this paper.

Features

This section describes all of the features of the Web Parts.

Overview

Figure 10 shows the Explorer and Viewer Web Parts on a SharePoint page.

Figure 10: Explorer and Viewer with Subscription icons

Each of the Web Parts has the following three areas:

• Standard Web Part controls: the title bar and tool pane. All SharePoint Web Parts have these, though they all use them differently. The title bar contains a menu and a caption that you can customize. The menu allows you to open the tool pane, which is a window that usually appears on the right side of the Web Part. The tool pane contains parameters such as Report Server URL and Report Path. These parameters are saved with the Web Part, so they persist after you close the browser or open a new Web page.

• Toolbar: controls just below the title bar. The toolbar contains controls that act on the current Viewer report or Explorer element, but are not saved with the Web Part. For example, if you change the Zoom percentage for a report and then close the browser window, it will revert back to 100% next time you open the report. The Report Viewer toolbar is identical to the report toolbar in Report Manager. The Report Explorer toolbar contains only a breadcrumb, which works like the breadcrumb at the top of the Report Manager interface.

• Content area: the area below the toolbar. This is where the Viewer displays the actual report content, and the Explorer displays the contents of the report server. The toolbar and content area are inside an IFrame (Inline Frame). An IFrame is an HTML construct that allows content from a remote Web page to be embedded in a local Web page. In the case of the Web Parts, the remote page is generated by Report Manager SP2, and the local page is generated by SharePoint. As always, Reporting Services and SharePoint may be on the same computer, so "remote" may not be any different from "local."

Report Explorer

Overview

Figure 11 shows the Report Explorer in Detail mode.

Figure 11: Explorer in Detail mode

This Web Part allows you to navigate and subscribe to the reports on the report server. If it is connected to a Viewer Web Part on the same SharePoint page, then clicking on a report link displays the selected report in the viewer, otherwise the selected report is displayed in a separate page. The title bar contains a user-defined string, which defaults to "Report Explorer."

Feature Summary

• The breadcrumb shows the path from the Start Folder specified by the Web Part to the current folder. You can click on any folder in the hierarchy to navigate to that folder.

• The Explorer can either display in details or list view, depending on the Web Part property.

• Clicking on a column header sorts the grid by the selected column.

• Only reports, resources, and folders are shown in the Explorer grid. Other Report Manager objects such as data sources are not shown.

• If the Explorer Web Part is not connected to a Viewer, then selecting a report causes it to open in a new browser window.

• A Subscription column indicates whether you have subscribed to the report. To add a subscription or modify the existing subscription, click on the icon in that column for the desired report. If subscriptions are not available for a report (credentials used to run the report are not stored, the report is using user-specific parameter values, the report is a linked report, and the link is no longer valid, you don't have permission to create a subscription, or e-mail is not set up in server configuration file), the subscription icon is not displayed.

Tool Pane

The Explorer Tool Pane contains the Appearance, Layout, and Advanced sections found on standard SharePoint Tool Panes. The behavior of the items in these sections has not been modified for the Explorer Web Part. An additional section called Configuration has been added. This section contains items that are specific to the Explorer Web Part. Table 2 explains these new items.

Table 2 Explorer Tool Pane

Tool Pane Item (Configuration Section)	Shared or Personal	Description
Report Manager URL (text box)	Shared	The URL to the report manager on the desired server. Can be prefixed with https:// or https:// The URL defaults to https://localhost/reports. If the indicated report server is not running RS Service Pack 2, the standard Report Manager interface is displayed inside the Web Part. This doesn't provide a good user experience.
Start Path (text box)	Shared	The path of the top level folder on the report server that is exposed by this control. The user may not navigate above this folder in the hierarchy. If the Start Path is blank, it defaults to the root (/). Also, a slash is prepended to any paths that do not start with one (i.e., relative paths are not allowed).
View Mode (Drop Down)	Personal	Details (default) and List.

Subscriptions

When you click on the subscription icon for a report, a subscription page then opens in a new browser window (not inside the Web Part). This page is similar in functionality to the subscription page in Report Manager, with one exception: only the Report Server E-Mail delivery option is available.

Only one subscription is available per report, so if a subscription has already been set up for a given report, then the properties for that subscription are shown. You may then edit the properties for the existing subscription or delete it entirely.

The Explorer Web Part uses the subscription’s Description field to identify the subscription as an RS Web Part subscription. If you manually edit this description through the Report Manager’s subscription interface, then the subscription may no longer be accessible through the Explorer Web Part.

Folders cannot be subscribed to, so there is nothing in the Subscription column for a folder.

Report Viewer

Overview

Figure 12 shows a standalone Report Viewer.

Figure 12: Standalone Viewer

Feature Summary

The title bar contains a user-defined string, which defaults to "Report Viewer." The Web Part menu (currently closed) is available on the right side of the title bar. It contains the standard menu items for a SharePoint Web Part. The content area shows the report. Note that only part of the report is visible within the Viewer. The rest is cropped, and accessible through scroll bars. The size of the Web Part on the SharePoint page, which you can adjust in the Tool Pane, determines how much of the report is visible.

You can interact with the report (drill down, show/hide, etc.) as you would in Report Manager. If you drill through to another report, the target report is shown in a new browser window. Drilling down, however, takes place within the same Viewer. If the report has parameters, they are displayed at the top of the viewing area. The parameters area expands as necessary to accommodate all of the report’s parameters. The standard report server toolbar is available below the parameters.

Tool Pane

The Web Part Tool Pane opens when you select Modify Shared Web Part from the Web Part menu. The Tool Pane allows you to set properties that are saved with the Web Part and persisted across browser sessions. It contains the Appearance, Layout, and Advanced sections that are found on the standard SharePoint Tool Pane. The behavior of the items in these sections has not been modified for the Viewer Web Part. An additional section called Configuration is specific to the Viewer Web Part. Table 3 explains these new items.

Table 3 Viewer Tool Pane

Tool Pane Item (Configuration Section)	Shared or Personal	Description
Report Manager URL (text box)	Shared	Path to the Report Manager
Report Path (text box)	Shared	The path to the report. The path must conform to the conventions used by the report server. This text box is used on a Viewer that is not connected to an Explorer.
Toolbar (Drop Down List)	Personal	3 choices: Full, None, Small

Viewer Web Parts on the same or different SharePoint pages are independent of each other. They may be configured to point to the same report or different reports, but they do not affect each other.

Technical Details

This section explains the technology behind the Reporting Services Web Parts.

General Approach

As discussed in the Features section, the Web Parts work by embedding an IFrame in each Web Part, and displaying content generated by the report server inside each IFrame. For the Viewer, this is easy as report view page that comes with Report Manager actually uses an IFrame to display the report content. So the same HTML Viewer on the report server is used to display the report in the Web Part version of the viewer. For the Explorer Web Part, it was necessary to modify the default Report Manager interface so that it made more sense in a Web Part context. In general this meant removing some features to conserve screen real estate while leaving enough of them to be useful to the SharePoint user.

Query String Variables

The Report Manager uses query string variables to control a number of options, including which folder to display in the Explorer (ItemPath), and whether to use list or detail view (ViewMode). This last one was expanded in SP2 to include two new view modes, WebPartList and WebPartDetail. When Report Manager sees one of these modes, it knows to use the Web Part user interface. Of course, because these values are in the query string, they could be passed in by other hosts besides the Web Parts. You can try this by navigating to a folder in Report Manager, and adding &ViewMode=WebPartList to the end of the query string (or editing the ViewMode value if it is already there). Although the Web Part changes are optimized for the SharePoint environment, they don't have to be used inside a Web Part.

Style Sheets

Report Manager uses style sheets (CSS files) to define look and feel. Because the Web Parts are designed for use in SharePoint, they have their own style sheets that give them the default SharePoint look and feel. If you are using a customized SharePoint page, you may want to modify your Web Parts to match. Here are the default locations of all of the style sheets:

• Client

  • Standard: C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportManager\Styles\ReportingServices.css

  • Web Part: C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportManager\Styles\RSWebParts.css

• Server

  • Standard: C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer\styles\htmlviewer.css

  • Web Part (full toolbar): C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer\styles\SP_Full.css

  • Web Part (small toolbar): C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer\styles\SP_Small.cssThere is an extra Web Part style sheet on the server because the style sheet is used to indicate which buttons should appear on the Viewer toolbar. If you want to create a custom version of the Small toolbar, you can modify SP_Small.css to add or remove toolbar buttons. To see how to do this, compare the .ToolbarZoom selector in SP_Small.css and SP_Full.css.

Connecting the Explorer and Viewer

Displaying a report in the Viewer given the correct URL is a simple matter because the Web Part Viewer can use the same process as the Report Manager's viewer does. The question then becomes how to get the URL to the Viewer. The Explorer knows the URL when you click on it. But Web Parts in SharePoint are independent entities, so they don't automatically share information. In general, this is handled using the technique described in the article "Creating a Connectable Web Part" on MSDN (see https://msdn2.microsoft.com/library/ms948913.aspx). However, a problem occurs when the report server and the SharePoint server are in different domains. The issue is the client-side scripting that is used to move the report URL that you click on from the report server (inside the Explorer IFrame) to the Explorer Web Part, where it can be passed to the Viewer. If what is inside the IFrame (the report server) is on a different domain from the IFrame's parent (the SharePoint page) then Internet Explorer detects a security violation and will not allow the script to execute. To work around this issue, when the Report Explorer part is processed on the server, it uses the name of the linked viewer part to generate links that point directly to the connected Viewer frame.

Troubleshooting

Here are some common problems you may run into when using the Reporting Services Web Parts.

I installed Reporting Services on my SharePoint computer, but I got the following error message: "The report server installation is not initialized. Check the documentation for more information. (rsReportServerNotActivated)"

Follow the instructions at "Troubleshooting a Side-by-Side Installation of Reporting Services and Windows SharePoint Services" (https://msdn2.microsoft.com/library/aa179370.aspx).

 

Report Manager is no longer remembering the state of list view vs. page view

This occurs when you are running Reporting Services and SharePoint on the same server and have not enabled ASP.NET session state on the report server virtual directory. See the referenced troubleshooting article above.

 

I installed the Web Parts on my SharePoint computer, pointed the Explorer to my report server (on a different computer), and connected it to a Viewer. But when I click on a report, it shows up in the Explorer instead of the Viewer.

The report server to which you point the Explorer Web Part must be running Reporting Services Service Pack 2 in order for the Web Part functionality to work. Follow the report server instructions in the Installing the Web Parts section, Installation Process subsection of this paper. If your report server is not running SP2, you will also notice that the Explorer will use the standard Report Manager interface instead of the new Web Part interface. For example, the toolbar in the standard Report Manager has a gray background, while the one in the Web Part interface has a blue background.

 

When I try to add a Web Part to a SharePoint page, I get the following error message: "A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as safe."

Make sure you have followed all of the steps in the Installing the Web Parts section, Installation Process subsection of this paper, including using the –url option to stsadm. If you used the –globalinstall option, try leaving it out so the Web Part package is installed to the bin directory of the virtual server. Manually verify that the bin directory under your SharePoint Web root contains a file called RSWebParts.dll. If you installed SharePoint in the default Web root, this directory would be C:\Inetpub\wwwroot\bin. A copy of this DLL may be found in C:\Program Files\Microsoft SQL Server\80\Tools\Reporting Services\SharePoint\RSWebParts.cab (assuming that Reporting Services is installed in the default location).

 

In the Report Explorer, none of my reports show an Add Subscription icon

Reporting Services has a number of rules that restrict which reports can be subscribed to. The Report Explorer only displays the Add Subscription icon for reports that meet all of the appropriate conditions. The easiest way to troubleshoot this issue is to attempt to subscribe to the report through Report Manager. To do this, open https://computername/reports, click on a report that you are having trouble subscribing to, and click the Subscriptions tab. The New Subscription button will probably look like this:

Figure 13: New Subscription button with warning

Despite the caution sign, you can still click on the button, and receive the following error message:

Figure 14: Subscription error message

Often the problem is the first one listed: the credentials used to run the report are not stored. To fix this, click OK on the error message, click the Properties tab, click the Data Sources link, and click Credentials stored securely in the report server in the Connect Using section. Enter the required information, and click Apply. Note that this can all be done using a shared data source, which can facilitate making this change for multiple reports.

References

This section lists places on the Web to find more information about the topics discussed in this paper.

• SQL Server Reporting Services home page
  https://www.microsoft.com/sql/technologies/reporting/default.mspx

• SQL Server Reporting Services Report Packs
  https://www.microsoft.com/sql/technologies/reporting/default.mspx

• SQL Server Reporting Services Books Online:
  https://msdn2.microsoft.com/library/

• SharePoint Products and Technologies on MSDN
  https://msdn2.microsoft.com/library/aa286490.aspx

• SharePoint Products and TechnologiesDeveloperCenter on MSDN
  https://msdn2.microsoft.com/sharepoint/default.aspx
  Authoritative whitepapers, tools, and samples from the WSS and SPS teams. Target audience is developers looking for the SDK and supplemental documentation-quality information from Microsoft.

• SharePoint Products and Technologies Team Pages on GotDotNet
  https://gotdotnet.com/team/sharepoint
  Community-submitted resources for developers, plus informal content from Microsoft employees and key partners. Target audience is developers looking for projects, examples, references to valuable information.

• SharePoint Products and Technologies Web Component Directory
  https://www.microsoft.com/downloads/details.aspx?FamilyID=38be67a5-2056-46a1-84b1-337ffb549c5c&DisplayLang=en&displaylang=en
  "White pages" of Web Parts from Microsoft and a variety of third parties. Target audience is administrators and power users looking for what they can add to their deployments.

• Bryant Likes' Blog
  https://blogs.sqlxml.org/bryantlikes
  Bryant is a Microsoft MVP (Most Valuable Professional), and author of a suite of open source Reporting Services Web Parts. His blog is a good place to look for discussion of Reporting Services Web Parts and other issues around accessing data on the Web.

• MSDN Webcast: New Features in Reporting Services Service Pack 2 (Level 400)
  https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032266510
  This webcast by Geoff Snowman, MSDN Developer Community Champion, covers all of the new features and fixes in Reporting Services Service Pack 2. In the Web Parts section, Geoff demonstrates how to install and use the Explorer and Viewer.

Acknowledgements

Thanks to Brian Hartman, Lukasz Pawlowski, Daniel Reib, Brian Welcker, Jonathan Tom and the other members of the SQL Server Reporting Services team at Microsoft. Lukasz wrote the original draft for the RS Web Parts Functional Specification, which this document draws some content from.