Chapter 27. Report Rendering Controls and SharePoint Services Web Parts

Microsoft Visual Studio 2005 ReportViewer Web and Windows Controls ^{New in 2005}

Visual Studio 2005 includes the freely distributable ReportViewer Windows and web forms controls.

ReportViewer greatly simplifies embedding of reports in an application.

The ReportViewer Windows control is shown in Figure 27.1.

Figure 27.1.  ReportViewer Windows control.

ReportViewer can provide both standalone (local processing mode) and server-based (remote processing mode) rendering.

When ReportViewer is used in local processing mode:

• ReportViewer renders a report using built-in rendering capabilities of the control and then presents it to a user.

• SSRS is not used by ReportViewer to process a report in local processing mode.

• An application provides a client report definition (.rdlc) file, which has to be a part of the project and a data set for the control.

The process to design client reports (.rdlc files) is different from designing server-based (.rdl) reports. .rdlc and .rdl files have a slightly different structure, but can be converted into each other.

Assume that you have already created a Windows or web form project. To display a report in ReportViewer, using the local processing mode, first you need to add a new data set using the following steps:

1. In Solution Explorer, right-click on the project (not the solution), point to Add, and select New Item. In the Add New Item dialog box, click DataSet. Enter a name for the data set (call it DSEmployeeEmail), and click Add. This adds a new XSD file named DSEmployeeEmail.xsd to the project and opens the DataSet Designer.

2. In DataSet Designer mode, open the Toolbox, and drag a TableAdapter onto the DataSet design surface. This launches the TableAdapter Configuration Wizard.

3. On the Choose Your Data Connection page, click New Connection. In the Data Source dialog box, select Microsoft SQL Server. Create connection to AdventureWorks database. Accept the default name AdventureWorksConnectionString. Click Next.

4. On the Choose the Command Type page, select Use SQL Statements.

5. On the Enter a SQL Statement page, enter the following T-SQL query (or use Query Builder), and then click Finish:

SELECT Person.Contact.FirstName, Person.Contact.LastName,  Person.Contact.EmailAddress
FROM Person.Contact INNER JOIN HumanResources.Employee
ON Person.Contact.ContactID = HumanResources.Employee.ContactID

6. Click the Advanced Options button, deselect all check boxes in the Advanced Options dialog box, accept, and click Next.

7. On the Choose Methods to Generate page, accept the defaults Fill a DataTable with Method name Fill and Return a DataTable with Method name GetData. Click Next.

8. On the Wizard Results page, click Finish.

To create a client report that consumes the DSEmployeeEmail data set, complete the following steps:

1. In Solution Explorer, right-click Reports, point to Add, and click New Item.

2. In the Add New Item dialog box, click Report. In Name, type EmployeeEmails.rdlc and then click Add to open a graphical design surface. This is the Report Designer component of Visual Studio 2005.

3. Finish designing the report layout, using techniques learned previously in the book. From the Toolbox window, drag and drop a Table report item on the report. In the Data Sources window, expand the DSEmployeeEmail data set and drag FirstName, LastName, and EmailAddress fields to the detail row of the table.

Complete the third and final set of steps to consume the client report in the ReportViewer control:

1. From the Toolbox window, drag and drop a ReportViewer control to Form1. (It was created automatically as a part of a project; you can rename it as needed.)

2.A. Click on the ReportViewer control and click on the tag to launch the ReportViewer Task panel. Click Choose Report from the drop-down and select a report that you want to display. Report names are shown in the form <Project Name>.<Report Name>.rdlc.

2.B. Alternatively, you can set ReportViewer’s properties as follows:

• Set PProcessingMode to Local

• Expand LocalReport and set the ReportEmbeddedResource property to the name of the report form <Project Name>.<Report Name>.rdlc.

2.C. Alternatively, you can programmatically manipulate the ReportViewer control, as in the following code sample:

//To ensure that report is processed in the local processing mode
reportViewer.ProcessingMode = Microsoft.Reporting.WinForms.ProcessingMode.Local;

//Setup Report path
reportViewer.LocalReport.ReportEmbeddedResource=
                "ReportViewerControlSample_LocalProcessing.EmployeeEmails.rdlc";

//Render report
reportViewer.RefreshReport();

The ReportViewerControlSample-LocalProcessing project is included as a sample for this book and demonstrates ReportViewer in the local processing mode.

When used in the remote processing mode, ReportViewer performs the following tasks:

• First leverages SSRS to render a report

• Then retrieves a rendered report from SSRS and presents it to a user

To display a report in ReportViewer, using the remote processing mode, set ReportViewer’s properties as follows:

• Set ProcessingMode to Remote

• Set ReportServerUrl to the URL of a Report Server, for example http://localhost/reportserver

• Set ReportPath to the path of the report on the server, for example /Part2/RelationalDBReports/Sales Order

Alternatively, you can programmatically set ReportViewer’s properties and render a report as needed in your application using the following code snippet:

//To ensure that report is processed in the remote processing mode
reportViewer.ProcessingMode = Microsoft.Reporting.WinForms.ProcessingMode.Remote;


//Setup Report Server Url and Report path
reportViewer.ServerReport.ReportServerUrl = new Uri(txtReportServerUrl.Text);
reportViewer.ServerReport.ReportPath = txtPath.Text;

//Render report
reportViewer.RefreshReport();

The ReportViewerControlSample-RemoteProcessing project is included as a sample for this book and demonstrates ReportViewer in the remote processing mode.

Microsoft SharePoint Web Parts

SSRS 2000 Service Pack 2 included two SharePoint web parts: SPExplorer and SPViewer. The same web parts are included in SSRS 2005. Web parts can be used on a SharePoint site (Microsoft SharePoint Portal Server or Microsoft Windows SharePoint Services site). As the names imply, SPExplorer is designed to browse reports deployed on the Report Server and SPViewer is designed to view reports. SPExplorer and SPViewer can be used as standalone controls or can be integrated with each other. When used as a standalone control, the SPExplorer web part opens a new browser window to display a selected report. The standalone viewer is used to show a single report. The Page Viewer web part (part of the default SharePoint web parts library) can supply much of the functionality of either a standalone viewer using URL Access or standalone SPExplorer by accessing Report Manager’s interface. SPViewer and SPExplorer web parts provide an additional SSRS-specific functionality that improves both the management and viewing experience. For example, SPViewer and SPExplorer can be connected with each other and as a user clicks through report links in SPExplorer, SPViewer displays the report. SPExplorer also provides a basic interface to create and manage subscriptions.

SSRS and Windows SharePoint services can be installed in any order. For SSRS to properly function, a SharePoint administrator needs to perform the following steps:

1. Add Report Server and Report Manager virtual directories to the list of exclusions:

STSADM.EXE -o addpath -url http://localhost/ReportServer -type exclusion
STSADM.EXE -o addpath -url http://localhost/Reports -type exclusion

2. Make sure that the Report Server and Report Manager are using an application pool that is different from the one used by SharePoint services.

By default, SQL Server setup places SSRS web parts in the following location:

C:Program FilesMicrosoft SQL Server90ToolsReporting ServicesSharePoint
RSWebParts.cab.

To deploy the web parts, a SharePoint administrator can use the following command:

STSADM.EXE -o addwppack -filename "C:Program FilesMicrosoft SQL
Server90ToolsReporting ServicesSharePointRSWebParts.cab"

Because we did not specify a virtual server in this example, the package should be installed on all Windows SharePoint Services-enabled virtual servers on the computer. To provide a specific virtual server for the package deployment, you can add an additional option: -url <Virtual Server URL>.

A site allows users to load only those web parts that are listed as safe in a Web.config file for a virtual server. The Stsadm.exe tool automatically adds the control to the <SafeControls> section for the virtual server specified on the command line.

After web parts are deployed, users (who have permissions to create websites and add content) can add SPExplorer and SPViewer web parts to a Web Part Page through the SharePoint window.

Summary

Visual Studio 2005 includes freely distributable ReportViewer Windows and web forms controls, which greatly simplify embedding of reports in Windows and web applications.

ReportViewer can be used in local and remote processing modes. When used in local processing mode, ReportViewer processes a report using internal rendering capabilities. When used in remote processing mode, ReportViewer retrieves rendered reports from the Report Server.

A special client report definition file with an extension of .rdlc is used by Report Viewer in local processing mode. Unlike .rdl reports, .rdlc does not embed data set information in the report, instead relying on data sets defined in a project.

Like SSRS 2000 Service Pack 2, SSRS 2005 includes two SharePoint web parts: SPExplorer and SPViewer. Web parts can be used on a SharePoint site (Microsoft SharePoint Portal Server or Microsoft Windows SharePoint Services site). As the names imply, SPExplorer is designed to browse reports deployed on the Report Server and SPViewer is designed to view reports. SPExplorer and SPViewer can be used as standalone controls or can be integrated with each other.

The next chapter discusses some ideas about programmatic modifications of a report’s RDL files and custom report generators, which can leverage .NET XML capabilities.