Distributing Enterprise-Wide Reports

You can deploy Crystal Reports for Visual Studio .NET as single-tiered or multitiered applications. As described in Chapter 1, "Introducing .NET and Enterprise Architecture," tiers are different application layers that specialize in a specific form of processing to maximize scalability.

Distributing Reporting-Enabled Applications

A Windows application that contains all report components locally, including the report file and reporting engine, represents either a one-tiered or two-tiered deployment; the presentation and logic exists on one tier , and the database exists on another. This type of deployment is best suited for applications that rely heavily on client-side processing. If any changes to a report are required, then the application needs to install an update.

A Web application that hosts a local report file for processing typically represents a three-tiered deployment: presentation on one tier, business logic on a second tier, and the database on the third tier. The Web server processes requests sent from the client side. Application users require only a browser to access the application. All report components reside on the server and can be updated centrally .

A report Web service is a report that has been published, or exposed, for consumption by a Web-enabled application. Applications connect over the Web to a report Web service existing on an application server, consume the exposed report, and display the report for users in a report viewer. Typically, users require only a thin client to view report Web services. All other report components reside with the report Web service on a remote application server. Changes made to the report Web service are reflected immediately in the application.

Distributing the Crystal Reports Runtime

You need to package and distribute Crystal Reports runtime files with the enterprise application. Deciding which runtime files to package depends upon the features used, such as charts and formula functions. Another variable is the data source used by the reports and the exporting options available to the application user . The Microsoft Installer (MSI) includes Microsoft Merge (MSM) modules for applications to use to simplify distribution. Chapter 14, "Installing .NET Applications," dives deeper into the details of building installation packages. This section highlights the components and modules relevant to reporting.

The Crystal Reports merge modules reside in the C:\Program Files\Common Files\Merge Modules directory. There are different merge modules, depending on the target components and languages. These modules come three categories: managed components, database access, and KeyCode.

The managed components handle the distribution of all the managed components, including the Windows form viewer, Web form viewer, and all of the Crystal Decisions namespace objects. The database access module handles the distribution of all the other files needed to get the reports to run, including database, export, and charting drivers. The KeyCode module handles the installation of the Crystal Decisions KeyCode so that your users are not asked to register their version of Crystal Reports when viewing reports.

Access to the Crystal Reports reporting engine packed with Visual Studio .NET does not limit the number of user connections. However, it is essentially a performance-limited version intended for development and small group use only. If a report is requested while the server is operating at its internal performance limit, the request will be delayed until the server load drops below this limit. In this case, the server writes a message in the event log. If the delay extends beyond a certain point of time, the server will throw an OutOfLicense exception.

Note	You can find Crystal Reports licensing information online at http://www.crystaldecisions.com/net/licensing .