After a report has been developed, it is time to share that report with our users. This is when our report moves from its safe, childhood life inside a report project to its adult life on a Report Server. This is known as deploying the report. Let me assure you, reports pass through deployment much easier than you and I passed through adolescence!
The Report Server is the piece of the puzzle that makes Reporting Services the product it is. This is the software environment that enables us to share our report with the masses, at least those masses who have rights to the server. Figure 15-2 shows the functional structure of the Report Server.
Figure 15-2: Report Server functional structure
When a report is deployed to a Report Server, a copy of the report's RDL definition is put in that server's Report Catalog. The Report Catalog is a set of databases used to store the definitions for all the reports available on a particular Report Server. It also stores the configuration, security, and caching information necessary for the operation of that Report Server.
Even though we may use any ODBC- or OLE DB—compliant data source to supply data to our reports, the Report Catalog database can only exist in SQL Server 2000 or SQL Server 2005. The Report Catalog database is created as part of the Reporting Services installation process.
When a report needs to be executed, the report processor component of the Report Server directs the show. The report processor retrieves the RDL for the report from the Report Catalog. It then reads through this RDL to determine what is needed for the report.
The report processor orchestrates the operation of the other components of the Report Server as the report is produced. It takes the output from each of the other components and combines them to create the completed report.
As the report processor encounters dataset definitions in the report RDL, it retrieves the data to populate that dataset. It does this by first following the instructions in the report's data source for connecting to the database server or file that contains the data. The report processor selects a data provider that knows how to retrieve information from this type of data source.
The data provider then connects to the source of the data and selects the information required for the report. The data provider returns this information to the report processor, where it is turned into a dataset for use by the report.
Once all the data for the report has been collected, the report processor is ready to begin processing the report's layout. To do this, the report processor looks at the format requested. This might be HTML, PDF, TIFF, or one of several other possible formats. The report processor then uses the renderer that knows how to produce that format.
The renderer works with the report processor to read through the report layout. The report layout is combined with the dataset, and any repeating sections of the report are duplicated for each row in the dataset. This expanded report layout is then translated into the requested output format. The result is a report ready to be sent to the user.
The request handler is responsible for receiving requests for reports and passing those requests on to the report processor. Once the report processor has created the requested report, the report handler is also responsible for delivering the completed report.
Reporting Services is not a single program that runs on a computer to produce reports. Instead, it is a series of services, web applications, and databases that work together to create a report management environment. As you plan your Reporting Services installation, it is important that you understand a little bit about each piece of the puzzle and how all these pieces work together to create a complete system.
Figure 15-3 shows all the parts that make up a complete Reporting Services installation. Each part has a specific role to play in the development, management, and delivery of reports or in the management of the Reporting Services environment itself. Let's take a look at each part and see how it fits into the whole.
Figure 15-3: Reporting Services component parts
The Report Server service is the heart of Reporting Services. As is shown in Figure 15-2, the Report Server is responsible for processing any report requests. This includes fetching the report definition, retrieving the data used in the report, and rendering the report in the desired format.
The Report Server is a Windows service, and it makes its functionality available as web services. This means the Report Server does not directly interact with the user. Instead, the Report Server Windows service runs in the background and handles requests made by other programs through the web services.
The Report Server service needs to have a valid user name and password that it can use to access the Report Catalog. This login information, along with other information that determines how the Report Server operates, is stored in the RSReportServer.config file. Most of the information in the RSReportServer.config file is stored as plain text and can be modified using Notepad or a similar text editor. The login information, however, is encrypted when it is stored in this file. It cannot be changed except through the administration utilities.
The administration utilities are tools for managing the Report Server service and for making changes to its configuration. These utilities take care of tasks such as manually starting the Report Server service if it fails to start automatically. The utilities can also be used to change the login information used by the service.
Most of these utility programs are run in a command window. The one administration utility that does have a Windows user interface is the Report Server Configuration Manager, which provides a convenient method for examining and modifying the configuration settings of a Reporting Services installation.
The administration utilities can be run on the computer that is hosting the Report Server service to manage the configuration on that computer. Most of the administrative utilities can also be used to manage a Report Server service that is running on another computer. This is called remote administration.
SQL Server 2000 or SQL Server 2005 is required to hold the database where Reporting Services stores its Report Catalog database. Reporting Services also uses the SQL Server Agent as its task scheduler. When a user creates a subscription, Reporting Services creates a SQL Server Agent job to handle that subscription.
Reporting Services uses two databases within SQL Server: the Report Server and the Report Server Temp DB. The Report Server database is used to store the Report Catalog. The Report Server database also holds information about the Report Manager website. This includes such things as the folder structure of the website, and the security settings for each folder and report.
As the name implies, the Report Server Temp DB database is used as temporary storage for Reporting Services operations. Information can be stored here to track the current users on the Report Manager website. Short-term copies of some of the most recently executed reports are also stored here in what is known as the execution cache.
Internet Information Services (IIS) serves as the host for the Reporting Services web service. When Reporting Services is installed, it creates a website and a web service in IIS. Therefore, IIS is required for Reporting Services.
The Reporting Services installation creates a website called Reports. The Reports website is what provides the Report Manager interface for Reporting Services. If Reporting Services is installed on a server named www.MyRSServer.com, then when you surf to www.MyRSServer.com/Reports, you see the Report Manager home page.
The Reports website is built using ASP.NET. This means ASP.NET support has to be enabled on IIS for the website to function.
A web service called Report Server is also created by the Reporting Services installation. The Report Server web service allows other programs to interact with, and even administer, Reporting Services. In addition, it allows other programs to request reports without having to go through the Report Manager interface. In short, the Report Server web service allows Reporting Services to be tightly integrated into other applications. Because web services work across an intranet or across the Internet, the web service interface allows Reporting Services to be integrated with applications running in the next room or in the next country.
The Report Server web service is also built using ASP.NET, so once again, ASP.NET support must be enabled on IIS for this feature to function.
As previously discussed, Reporting Services reports are created using the Report Designer either in the Business Intelligence Development Studio or in Visual Studio 2005. The Report Designer functions exactly the same in either development tool. No difference exists between a report created in the Business Intelligence Development Studio and in Visual Studio 2005.
The final piece of Reporting Services is the documentation. The bulk of this documentation is found in the SQL Server Books Online. After Reporting Services is installed, you can view the SQL Server Books Online through your Start menu. You can find it under Programs | Microsoft SQL Server 2005 | Documentation and Tutorials | SQL Server Books Online. In addition to this is a set of help screens for the Report Manager interface that can be accessed through the Reports website.
We may install both the Reporting Services Windows service and the Reporting Services website and web service on the same server. However, some organizations may choose to place these items on separate servers. This can be done through either a distributed installation or a web farm installation.
In a distributed installation, the Reporting Services items discussed are not installed on a single computer. Instead, they are split between two computers that work together to create a complete Reporting Services system. One computer runs SQL Server 2000 or SQL Server 2005 and hosts the Report Server database. This is the database server. The other computer runs the Report Server service and IIS. This is the report server.
Figure 15-4 shows a distributed installation. Note, Figure 15-4 shows the servers and the report designer workstations. It does not show computers used for viewing reports.
Figure 15-4: A distributed installation of Reporting Services
The distributed installation has advantages when it comes to scalability. Because the workload of the three server applications—IIS, SQL Server, and the Report Server—is divided between two servers, it can serve reports to a larger number of simultaneous users. The disadvantage of this type of installation is that it is more complex to install and administer. However, if we need a high-volume solution, it is certainly worth the effort to obtain a solution that can provide satisfactory response times under a heavy workload.
The web farm installation is a specialized form of the distributed installation, as shown in Figure 15-5. In a web farm, a single database server interacts with several report servers. Each of the report servers uses the same Report Server database for its information. By using additional report servers, we can handle even more simultaneous users with the web farm installation than we could with the distributed installation.
Figure 15-5: A web farm installation of Reporting Services
Again, note that Figure 15-5 shows only the servers and the report designer workstations. It does not show computers used for viewing reports.
When report designers create reports, they can deploy them to any of the report servers. No matter which server is used, the reports end up in the single Report Server database. Once the reports are in the Report Server database, they can be delivered by any of the report servers. In addition, because all information about the Report Manager is stored in the Report Server database, any changes to the Report Manager made on one server take effect on all the servers.
For example, suppose an administrator uses the Reports website to access the Report Manager through Report Server A. The administrator creates a new folder in Report Manager—called Sales Forecasts 2006—sets the security, so the sales staff can access this folder, and places the Sales Forecast report in the folder. Immediately after the administrator is finished, a salesperson brings up Report Manager through Report Server C. The salesperson can browse the contents of the Sales Forecasts 2006 folder and can run the Sales Forecast report.
As with the distributed installation, the web farm installation provides a way to handle a large number of simultaneous requests for reports. Even though the web farm uses a number of servers to deliver reports, it allows the Report Manager interface to be administered without duplication of effort. The web farm installation may take additional effort to get up and running, but once it is ready to go, it provides an efficient means of serving a large number of users.