Introducing Microsoft Reporting Services, Part 2, Page 4
Task: Test the Report
Let's make some cosmetic changes to enhance our report.
- Click on the Report Designer Preview tab to see the HTML representation of the report. Notice the report toolbar at the top, which allows you to zoom, print, and save the report in different formats. The Sales field needs some formatting work.
- Click the Layout tab again to go back to design mode.
- Right-click on the Sales text box and choose Properties. Specify the format settings, as shown in figure 1.16. Click OK to close the Textbox Properties dialog box.
- Increase the width of the Territory and Product Category columns; stretch them out as far as there is space within the report width.
- Right-click again on the Territory text box and go to the field properties.
- Click the Advanced button and, in the Font tab, change the font weight to bold and style to Italic. Click OK.
- Back to the Textbox Properties dialog box, hide the repeating territory names by selecting the Hide Duplicates check box, as shown in figure 1.17.
Preview the report again. Now it should look like the report shown in figure 1.9. Still not very pleasing to the eye, but not bad for a few minutes of work!
Click here for a larger image.
Figure 1.16 Use the Textbox properties page to set up format settings.
Figure 1.17 Select the Hide Duplicates check box to hide the territory name duplicates.
Once you are satisfied with the report, you will probably need to deploy it to make it available to all users. This is a report management task that you can accomplish by using the Report Manager. However, if your Windows account has local administrator rights on the computer where the Report Server is installed, you can deploy the report straight from within Visual Studio .NET. Let's do just that.
Task: Deploy the Report
- Save your changes.
- From the Solution Explorer, select the Sales by Territory.rdl node, right-click, and select View Code. Visual Studio .NET shows you the report definition of the report. Note that the report RDL includes the report query and layout information. Since we chose to create a shared data source, the data source information is not included in the report RDL.
- In the Solution Explorer, right-click on Sales by Territory.rdl and choose Deploy. This compiles the report and uploads the report to the report catalog.
Once the report has been promoted to a managed report, it can be delivered to your end users. Let's see how users can request the report on-demand by using the Report Manager as a quick-and-easy report-delivery tool.
Task: On-Demand Report Delivery
- Open the browser and navigate to the Report Manager URL, which by default is http://<reportservername>/reports. Notice that below the Report Manager Home folder there is a new folder, AWReporter, and that its name matches the TargetFolder setting you specified in the report project settings.
- Click on the AWReporter folder link to see its content. You should find the AW2000 Shared DS data source and Sales by Territory report links.
- Click on the Sales by Territory report link to request the report with the Report Manager.
As you can see, authoring, managing, and delivering reports with RS is straightforward. At this point, you may decide to compare RS at a high level with other reporting tools you've used in the past. The next section discusses how RS stacks up against the competition.
1.8 EVALUATING RS
By the time you read this book, comparison charts will probably be available from Microsoft and other sources to show how RS compares with other popular reporting tools. For example, the Resource section at the end of this chapter lists a link to a detailed feature comparison document between RS and Crystal Reports.
Based on my experience with integrating applications with third-party reporting packages, I think that as a first iteration, RS is surprisingly feature-rich. My favorite top ten features, where I believe RS excels, are as follows:
- Natively exposed as a Web service—The RS reports are widely accessible, and you don't have to do anything special to publish your reports as web services because they are hosted under the Report Server, which provides a web service façade.
- Support of plethora of export formats—You may be delighted to learn that the ability to export reports to PDF and Excel is provided out the box. In addition, reports can be delivered in many other popular formats, including web formats (HTML), popular image formats (such as TIFF and JPEG), and data formats (Excel, XML, CSV).
- On-demand and subscribed report delivery—Another huge plus is the subscribed report delivery option, which allows developers to implement opt-in report features in their applications.
- Documented report definition format—Developers can create reports to be published to the Report Server using Microsoft or third-party design tools that support the RS XML RDL.
- .NET Framework integration—In the extensibility area, you'll appreciate the fact that you are not locked from a programmability standpoint. As we mentioned earlier, when built-in features are not enough, you can reach out and borrow from the power of the .NET Framework by integrating your reports with .NET code. In addition, the Report Services programming model is 100 percent .NET-based.
- Extensible architecture—The RS architecture is fully extensible and allows developers to plug in their own security, data, delivery, and rendering extensions.
- Zero deployment—Thanks to its service-oriented architecture, RS has no client footprint and offers true zero deployment for all application types.
- Scalability—RS can scale better, since it is designed from the ground up to scale in web farm environments.
- Visual Studio .NET integrationReport authors will enjoy the familiar IDE environment when designing and testing reports.
- CostFrom a cost perspective, it is hard to beat the bundled with the SQL Server RS pricing model, especially if you compare it with the five-digit price tag of third-party reporting tools.
Of course, nothing is perfect, and Report Services has its own shortcomings, some of which I would like to mention here. As a .NET developer, I would like to see a future version of RS bring a tighter integration with Visual Studio .NET. Ideally, working with BI projects should not be much different than working with .NET code projects, for example, Windows Forms. In the future, I would expect RS to evolve and add the following features:
- Allow developers to add code-behind files to their reports.
- Instead of Visual Basic .NET only, support all .NET-compatible languages for writing expressions and report-specific code.
- Use the Visual Studio .NET code editor instead of the Notepad-like Custom Code Editor.
- Support events; currently, developers cannot write event handlers to respond to runtime conditions. Microsoft Access, for example, has been enjoying a report object model with events since its first release. Since the RS generation process is not event-driven, the only option for implementing runtime code customization with Report Services is to use expressions.
- Include more flexible object model, for example, creating report elements dynamically, and referencing and changing report items from custom code.
- Convert reports from reporting tools other than Microsoft Access.
I hope that the above shortcomings will be addressed in future releases of RS to make this tool an even more compelling choice for enterprise reporting.
This chapter took you on a whirlwind tour of the RS platform. We've discussed its role in the Microsoft BI initiative, as well as its features and high-level architecture. You have even had a chance to use RS and create a simple report based on the AdventureWorks2000 sample database. Now that you have a good high-level understanding of its features, you can begin using RS to report-enable your own applications.
By now, you should understand the major components of RS and their role in the report lifecycle. In addition, you should see the advantages that the service-oriented and web-enabled RS architecture has to offer.
Perhaps most important, you should be familiar with the three stages of the report lifecycle: report authoring, management, and delivery. The remaining chapters explore each of these stages in this order. In the next chapter, we discuss different ways to create RS reports.
Microsoft RS website (www.microsoft.com/sql/reporting/)—First stop for the latest on RS.
Microsoft Business Intelligence Platform website (www.microsoft.com/sql/evaluation/BI/default.asp)—The Microsoft BI portal home page.
A feature comparison between RS vs. Crystal Reports (http://certia.ramblainf.com/pdf/RSvsBO_En_v1.pdf)—Ceria's Business Intelligence Team has developed a detailed feature comparison document that outlines how Microsoft RS stacks against Crystal Enterprise.
A Guide to Developing and Running Connected Systems with Indigo (http://msdn.microsoft.com/msdnmag/issues/04/01/Indigo/)—In section 1.3 I emphasized the role of the RS service-oriented programming model. Read Don Box's article for more information about SOA.
About the Author
Teo Lachev has more than 11 years of experience designing and developing Microsoft-centered solutions. He is currently working as a technology consultant with the Enterprise Application Services practice of Hewlett-Packard. Teo is a Microsoft Certified Solution Developer and Microsoft Certified Trainer. He lives in Atlanta, GA.
About the BookMicrosoft Reporting Services in Action
By Teo Lachev
Published July 2004, Softbound, 656 pages
Published by Manning Publications Co.
ISBN ISBN 1932394222
Retail price: $49.95
Ebook price: $25.00. To purchase the ebook go to http://www.manning.com/lachev.
This material is from Chapter 1 of the book.
Page 4 of 4