Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Building Report-enabled Applications with the New ReportViewer Controls (Part 2 of 2) : Page 2

Organizations can use Reporting Services to make data easily accessible to internal users, customers, and partners. The second part of this article shows you how you can leverage the Web version of the ReportViewer control to integrate Reporting Services 2005 with your intranet and Internet applications—without compromising security.


advertisement
Remote Mode
As you may recall from the Part 1 of this article, in remote mode, the ReportViewer control acts as a presentation layer to the Report Server. Figure 2 shows the architectural view of the remote processing mode with Web applications. The important point here is that the Web ReportViewer submits the report request on the server side of the application. The client (Web browser) never accesses the server directly. Instead, report processing follows these steps:

 
Figure 2. Remote Mode: In remote mode, the Web Report Viewer submits report requests to the Report Server.
  1. Server-side ASP.NET code configures the control to request a given report.
  2. The Web ReportViewer calls the Report Server to generate the report.
  3. The Web ReportViewer streams the report payload to the browser that renders the report.
Developers who have implemented server-side report generation with RS 2000 are aware of the complexities surrounding this integration scenario. For example, extra steps were required to handle report images and correlate report requests with Report Server sessions. In addition, the report interactive features didn't work. These limitations simply disappear with the Web ReportViewer. How is this possible?

The ReportViewer HttpHandler
When you add the ReportViewer control to your form, it automatically registers a special ASP.NET HttpHandler (Reserved.ReportViewerWebControl.axd), as you can see by examining the application Web.config file. The HttpHandler is an integral part of the Web ReportViewer control. You must not remove or unregister it even if the report doesn't require images or interactive features. In addition, ASP.NET session state must be turned on. If this conflicts with the operational requirements of your application, note that the HttpHandler supports a certain degree of customization (see the MSDN document "Web.config Settings for ReportViewer" for more details).

The main responsibilities of the HttpHandler include handling images, exporting reports to other report formats, supporting report sessions and interactive features. For example, if a report uses an embedded image, the browser submits an HTTP-GET request to the HttpHandler to fetch the image. The ReportViewer HttpHandler interfaces are not documented and are for internal use only. However, rest assured that the Web ReportViewer doesn't send the report path or report parameters. The only Report Server-specific parameter is the session identifier used to correlate the report request with the client.

 
Figure 3. Requesting Reports: The Web Report Viewer demonstrates requesting reports in remote and local processing modes.
The Web Report Viewer Demo
Similar to its WinForms counterpart, the Web Report Viewer sample application demonstrates the remote and local processing modes (see Figure 3). When the end user clicks on the "Run Report" button, the page posts back to itself and invokes the RunRemote function.

private void RunRemote() { reportViewer.ProcessingMode = Microsoft.Reporting.WebForms.ProcessingMode.Remote; // Get the Report Server endpoint from // the config file reportViewer.ServerReport.ReportServerUrl = new Uri( ConfigurationManager.AppSettings[ "ReportServerEndPoint"]); reportViewer.ServerReport.ReportPath = "/Prologika/Customer Orders"; }

The code configures the Web ReportViewer in remote mode. Then, it sets the ServerReport.ReportServerUrl property to the Report Server URL. Finally, it tells the Web ReportViewer which report to render by setting its ReportPath property. As with the WinForms ReportViewer, the Web ReportViewer automatically generates a toolbar to handle common reporting tasks. This is the same toolbar you will see when running a report in the Report Manager, which uses the Web ReportViewer behind the scenes.

Author's Note: There is an annoying bug with the initial release of the Web ReportViewer when using absolute positioning and multi-value parameters. Because multi-value parameters use absolute positioning, placing the Web ReportViewer at absolute CSS coordinates upsets the parameter handling logic—specifically, trying to expand the parameter results in a page postback instead of showing the parameter values. As of the time of this writing, the only workaround is to use flow positioning for the control.

Handling Report Parameters
Report parameters are handled automatically by the control. If a parameter is required, the end user can enter the parameter value and click the "View Report" button. This causes the page to post pack. If your requirements call for more involved parameter handling logic, the application can collect and pass the parameters to the control just like you can do so with the WinForms ReportViewer.

private void SetParameters() { ReportParameter[] parameters = new ReportParameter[2]; parameters[0] = new ReportParameter("Date", "1/1/2003"); parameters[1] = new ReportParameter("CustomerID", new string[] { "14335", "15094" }); reportViewer.ServerReport.SetParameters(parameters); }

One welcome feature is the ability to export the report inline and bypass the Internet Explorer standard conformation dialog to save the file. To try this feature, set the ExportContentDisposition control property to AlwaysInline and export a report to a format of your choice. Another frequently requested feature was the ability to target a specific frame with URL navigation (Hyperlink action). Use the HyperlinkTarget property to specify the target window (e.g. _top or enter the frame name). Finally, the Web ReportViewer supports a cornucopia of properties to change its appearance (check the Appearance category in the VS.NET Properties window) or apply an ASP.NET skin (SkinID property).

Handling Security
Report-enabling Web applications brings additional challenges, the first and foremost being security. From a deployment standpoint, most Web applications can be categorized as intranet or Internet applications. You can secure the Web ReportViewer to address either of these deployment scenarios.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap