Catálogo de publicaciones - libros

Having created and deployed numerous projects with SSRS for SQL Server 2000, we have been anxiously awaiting, along with the rest of the SQL Server community, the release of SQL Server 2005 and the promised enhancements to SSRS. Though SQL Server 2005 has been a long time coming, SSRS was fortunately released ahead of its anticipated schedule, so it has been tested for more than a year. As you work through the book, we will point out enhancements where applicable, but our aim, as with the first edition of the book, is to show how to take advantage of advanced features, provide useful examples, and, mostly, put SSRS to work in a real-world environment where the user who will be working with the reports and applications that you deploy will have the final say on the solution’s success.

In this chapter, you began to design the essential part of a report: the query and stored procedure. By using stored procedures, you gain the benefits of central administration and security and also gain the ability to execute compiled code to return the dataset instead of a stand-alone query. You can develop queries in conjunction with the report, using the built-in query tools within SSRS. However, it’s best to deploy the report with a stored procedure.

A report request and the target audience are the deciding factors when determining the layout and default rendering of the report. However, even though reports are often designed to answer a specific need, if they’re based on the same tried-and-true stored procedures, with similar parameters and groupings, the data will be accurate across all reports. You can then focus the design time on the report itself and not on rewriting queries.

In this chapter, we covered a big chunk of the BIDS IDE and the tools you’ll use to build a reporting solution. You learned that each report consists of defined elements that are based on a defined schema in the RDL, which gives SSRS the advantage of standardization. We covered the report objects that make up reports and viewed their properties and functionality. You also saw for each object how the graphical design components are directly translated to RDL through the design process. Now that you’re more comfortable with the design environment, you’ll learn how to use it to design and deploy some real reports. In the next chapter, we’ll show how to take a step-by-step approach to adding these report items to a report that was designed as part of an SSRS migration for our health-care application.

It seems as if we have covered much ground in the actual design of a reporting solution with SSRS. However, at the same time, we have only scratched the surface of getting to the raw power and flexibility of SSRS. We have yet to show how to interweave custom assemblies to perform specific functions that go beyond basic expressions. You will also be working with other data regions in other parts of the book that we have not touched on here. Additionally, you have been working with only a small number of reports in this chapter; often in a business, especially when facing migrating existing reports to SSRS, you will be working with many reports simultaneously. Deploying, administering, and securing these reports are going to become critical next steps.

Luckily, a robust and flexible design environment is only one component of SSRS. In the upcoming chapters, you will deploy, secure, and analyze the performance of the reports you are designing here, using a variety of methods.

In this chapter, you learned how to use custom code with your reports, and we discussed some of the other programmatic aspects of dealing with SSRS 2005. Chapters 6, 7, and 8 will build on this as we show you how to write custom applications to render reports, deploy them to the report server, and schedule them to run using subscriptions.

In this chapter, we showed how to use the URL access capabilities of SSRS 2005 and the new ReportViewer controls to embed reports quickly into applications. Beyond the WebBrowser and ReportViewer controls used in this chapter, you can use other applications to render reports. For example, SSRS 2005 includes a new Report Viewer Web Part for Windows Share- Point Services and SharePoint Portal Server as well as a Report Explorer Web Part. We’ll discuss using these in greater detail in Chapter 10. By combining SharePoint and SSRS 2005, you can quickly build a portal that displays your reports without much code at all.

In this chapter, you also learned how to make Report Server Web service calls to augment your Windows Forms viewer application. The application you created allows you to type the URL of a server-based report you want to view. It then uses SSRS 2005’s GetReportParameters method to retrieve a list of report parameters and the ValidValues method to retrieve possible values. It then reads the values selected by the user and populates an array of ReportParamters, which is then used by the Report Viewer control to render your report with the selected parameters. In Chapter 8, we’ll expand on this example by using the Report Server Web service to allow the user to set the report to run on a schedule with the supplied parameters instead of rendering it immediately.

In this chapter, you used the SOAP APIs through the Report Server Web service to list the folders on the selected server and then allowed the user to select an RDL file and upload it to the user-specified folder on the selected report server. We also examined some of the additional features you could provide the application by using a few of the many methods and properties exposed by SSRS 2005.

SSRS 2005 provides many tools for management tasks, and we covered several of them in this chapter. Because SSRS 2005 is a full reporting solution, administrators may find it difficult to manage the entire site single-handedly without some level of automation or divided tasks, especially as the number of reports and other objects such as data sources, models, folders, and subscriptions grows. Maintaining these objects, whether it be to update the report via Report Manager or to mass deploy reports via a custom application, administrators will continually find themselves maintaining their SSRS report servers. Tools such as SSMS, Report Server Configuration Manager, and Report Manager go a long way to centralize the administrative tasks but do not necessarily reduce the potential rote tasks associated with managing a large installation. Fortunately, SSRS provides the flexibility to allow other professionals, department managers, and users to maintain their own reports using tools provided with SSRS 2005 or through your own custom applications. Of course, with this flexibility comes the need for tighter security. We will turn now, in the next chapter, to security and show how to make sure that you can lock down and monitor this flexible model.

In this chapter, you examined three of the security tasks essential to secure SSRS deployment: encrypting, authenticating, and auditing. You looked at how we chose to implement SSRS, both internally to intranet users and externally to Internet clients through a hosted application. In both models, the threat of confidential data falling into the wrong hands is real. When data is transmitted over a public network such as the Internet, you should make sure the three components are properly configured and thoroughly tested. Internally, only employees who need access to confidential data should have it, and you can ensure this by applying a special filter for a report deployment. As a software provider for health-care organizations that store confidential patient information, we are required to conform to the regulations imposed by HIPAA. However, in other industries, many similar regulations exist. Having security policies and procedures in place for any company is good practice, even when not working under stringent regulations. Fortunately, SSRS is designed to use the core-level security mechanisms that already exist in your organization through Windows authentication and can be extended, when required, to support other means of custom authentication.

In this chapter, we showed how to incorporate SSRS into a BI model, specifically covering the business model of a software development company and health-care agency deploying a custom BI portal. Understanding how to transform and analyze the data that drives your business will help you make important business decisions. Delivering that data to decision makers is a pivotal link in the BI chain. With SSRS, Microsoft has provided organizations with another tool that can easily tap into and extend the reach of crucial data. From business applications such as Microsoft CRM to custom project management solutions, SSRS easily utilizes many types of data and can deliver it in a variety of formats. Working with other applications and products in the Microsoft BI platform—such as SharePoint Portal Server, Analysis Services, and Office—SSRS will prove to be an invaluable BI tool now and in the future.