For example:

let's say that a user would like the report test.rpt downloaded to his browser in Microsoft Word format. The URL (ISO - Latin encoded) would be the following:

http://mycomputer/test.rpt?cmd=EXPORT&EXPORT_FMT=U2FWORDW%3A0

Refreshing Web Report Data

When a report contains saved data, the report does not need to access any databases when retrieved from the Crystal Web Reports Server. This can greatly reduce network traffic and the use of network server resources when many people are frequently requesting reports. For this reason, you may want to design most of your reports so that they contain saved data. Additionally, reports containing saved data can be easily cached by the Web Reports Server for optimized job sharing, serving more users with the same information simultaneously. However, if a report contains saved data, and changes are made in the original database, the report will no longer reflect accurate information. To update the report, you can open it in Seagate Crystal Reports, refresh the data, and save the report again. However, the Crystal Web Reports Server also provides a means to dynamically refresh report data.

As a web system administrator, you must decide if you want to allow users to refresh report data themselves, or if you want to control how and how often they can refresh report data. Each of the Crystal Smart Viewers, for instance, includes a button to refresh the data while it is viewed. However, sites with several users refreshing report data can result in network and system slow downs since every refresh requires connecting to a database and gathering data.

You can override or even disable the users capability for refreshing and create other means for keeping up to date data in reports. One method is to set automatic refreshes using the Database Refresh Time, Page 19, setting in the Advanced Settings, Page 18, of the Web Reports Server Configuration application.

When deciding how data will be refreshed at your web site, keep in mind that frequent refreshes of report data limits report caching capabilities of the Web Reports Server. Every time the report is refreshed, any cached version of that report becomes obsolete. Thus, too many refreshes eliminate the ability to serve cached versions of frequently requested reports.

Web Reports Server Architecture

An understanding of the architecture of the Web Reports Server can improve your deployment of web sites and assist with major troubleshooting tasks. In fact, the Web Reports Server consists of three separate components: the Web Reports Server extension, the Image Server, and the Page Server. The interaction of these three systems has been designed to optimize the handling of requests and the delivery of reports at runtime.

The following topics are discussed in this section.

The Web Reports Server Extension, Page 38

The Seagate Crystal Web Image Server, Page 39

The Seagate Crystal Web Page Server, Page 39

Report Processing, Page 40

Job Manager Overview, Page 41

The following diagram illustrates the components of the Web Reports Server.

The Web Reports Server Extension

The server extension for Crystal Web Reports communicates directly with your web server. When you install the Crystal Web Reports Server, two new file extensions are established on your system: .rpt and .cri. When your web server receives a request for either of these file types, it directs the request toward the Web Reports Server extension (CRWeb). The Web Reports Server extension then determines what application should be used to process the request, the Image Server (.cri) or the Page Server (.rpt). Once a request is processed, the server extension also handles returning the data to the web server for delivery to the client’s browser. This is the main point of contact between the web server and the back-end report processing servers.

There are actually two versions of the Web Reports Server. One has been designed specifically for Microsoft and Netscape web servers, while the other can run on most CGI compliant Windows based web servers.

ISAPI/NSAPI

The Web Reports Server extension implemented in CRWEB.DLL is both an ISAPI and NSAPI extension. By utilizing the API extensions exposed by Microsoft and Netscape web servers, CRWEB.DLL produces a faster, more robust system for report delivery to the web server.

The ISAPI extension is supported by Microsoft Internet Information Server (IIS) versions 2.0 and later. Additionally, the Personal Web Server available for Windows NT Workstation, Windows 95, and Windows 98 also supports ISAPI extensions.

The NSAPI programming interface is available on all Netscape web servers.

CGI

A second implementation of the Web Reports Server extension exists in the file CRWEB.EXE. This application conforms to the CGI standard. If you are using a web server other than a Microsoft or Netscape server, the CGI version of the Web Reports Server can easily be installed with your existing web server software.

The Seagate Crystal Web Image Server

When a report is rendered in HTML, graphic images, maps, graphs, charts, and OLE objects are rendered as Crystal Image (.CRI) files and stored by the Page Server module. When the Web Reports Server encounters a Crystal Image inside of the HTML report, it asks the Image Server to interpret it. The Image Server translates the image into a form that can be displayed by browsers (such as JPEG format), and sends the image back to the Web Reports Server for distribution through the web server.

NOTE: Crystal Image files are not used if the report is rendered as an Encapsulated Page File (EPF) for display inside the Crystal Smart Viewers for ActiveX, Java, or Java Beans.

Running Image Server as an NT Service

On Windows NT systems, the Image Server can be set up to run as an NT service. It is installed under a system account by default. NT services run in the background and do not require a user or administrator to be logged on to the web server machine. Most web server systems should run the Image Server as an NT service for best performance.

The Image Server appears as Crystal Web Image Server in the Windows NT Services control panel.

The Seagate Crystal Web Page Server

NOTE: This section refers to the Job Manger which is the component responsible for implementing report sharing and page caching among other thing. Refer to the section titled Job Manager overview for a general description of how page caching and report sharing are implemented.

The Page Server is the most complex piece of the Crystal Web Reports Server system. It is actually made up of several smaller components each responsible for handling specific parts of the report processing task. It’s primary job, though, is to receive a request for an .RPT report file from the Web Reports Server, generate the report, and return it in a form that can be viewed by a web browser.

NOTE: The Web Reports Server limits report caching features with reports based on SQL stored procedures or that include parameter fields. Such reports may generate a different set of data every time they are requested, due to the dynamic values passed to the parameter field or stored procedure. Thus, multiple requests for the same report may actually produce separate report jobs.

Report Formats

When the Page Server generates a report, it will translate it into either HTML pages or Encapsulated Page File (EPF) pages. The output depends on how the report will be viewed in the browser. If the browser requests viewing a report as HTML or HTML frames, the Page Server will generate HTML pages containing Crystal Images where appropriate. (Crystal Images are, in turn, interpreted by the Image Server. See The Seagate Crystal Web Image Server, Page 39.) If the browser requests to view a report inside the Java viewer or the ActiveX viewer, then the Page Server generates EPF pages.

HTML and HTML frames can be viewed inside any browser that supports the HTML 3.02 standard. This general standard makes HTML reports ideal for sites that may use a wide range of browsers or in secure sites that do not allow ActiveX controls or Java applets. However, HTML is a limited display format, and reports may lose some of the design features available in Seagate Crystal Reports.

EPF is a Seagate format based on the Encapsulated Postscript format (EPS). As a result, EPF reports can handle complex layout and design descriptions. When viewed inside the browser, EPF reports retain most if not all of the design and layout elements of the report originally created in Seagate Crystal Reports, providing a cleaner, more accurate display of the information. As a proprietary format, though, EPF reports can only be displayed inside the ActiveX or Java based Smart Viewers.

NOTE: EPF files do not retain formatting information set by printer drivers. Examples of such formatting include page size and page orientation.

Report Processing

When the Page Server gets a request for a new report, it must obtain a new request Id from the Job Manager and determine if the Job Manager needs to obtain a new job Id from the Report Engine. If a new job Id is required, the Report Engine must actually generate a new report. The interaction between the Page Server, the Job Manager, and the Report Engine has been designed to maximize performance in intranet and extranet environments.

The Crystal Reports Job Manager must generate new request Ids for every request the Web Reports Server receives. If the Page Server determines that the requested report already exists in the cache, it will simply obtain a new request Id from the Job Manager, then match that request to the job Id of the existing report. If the report has not been cached, the Page Server must obtain a new job Id from the Job Manager, as well as a new request Id.

If the Page Server demands a new report job Id from the Job Manager, the Job Manager will start the Report Engine and have it generate the new report. The Report Engine creates a job Id for the new report and returns it to the Job Manager which, in turn, returns both the job Id and the request Id to the Page Server.

Report Engine

The Report Engine is the component which actually generates reports. The Report Engine opens a requested RPT file, locates the necessary data, and produces a complete report file. If you are an application developer, this is the same Report Engine that you can add to your own applications (see Crystal Report Engine, Page 63 for more information). Every report produced by the Report Engine has a unique job Id to identify that report. The Page Server uses the job Id to determine what actual report must be used for a specific client request.