Crystal Enterprise Architecture

Crystal Enterprise s multitier architecture lends itself to a much more flexible, higher-capacity system for web reporting. It also lends itself to more complexity when it comes to initial setup, operation, and administration. This increased complexity comes, in large part, from the increased number of components that make up the server portion (or back end ) of Crystal Enterprise. While an Enterprise end user simply sees web pages that allow scheduling and viewing of reports , there are many separate server components working together to provide this capability to the user. These various server components that make up CE share its overall processing requirements, passing information among themselves as required.

Administrators of the CE predecessor, Crystal/Seagate Info, will see many similarities between Crystal Enterprise server architecture and Info server architecture ”Crystal Enterprise architecture was borrowed from Info . However, if you are in charge of administering Enterprise and this is your first experience with a multiserver configuration, there is much to learn about how all these different server components work together and pass information back and forth.

In order for Crystal Enterprise to potentially support up to thousands of web users, a great deal of processing power must be available for peak processing loads. The idea behind the Enterprise multiserver architecture is to spread that processing load around. Different server components have limited functionality ”some are designed to run reports against a corporate database, and others have as their sole purpose to keep track of already viewed report pages, while others keep track of security and report scheduling. Determining how many different computers to use for back-end processing and which components to place on those computers is largely dependent on your individual system and where you think the largest processing loads will be. By studying the remainder of this chapter, by consulting documentation accompanying Crystal Enterprise, and by pure experimentation, you ll eventually be able to determine the proper delineation of server resources. And, you may always move components around or scale out if you need to ”you may initially start with all components running on one physical computer, but later split servers out to multiple processors as your capacity needs increase.

Note  

This chapter is largely aimed at those administering Crystal Enterprise Professional and Premium Editions. While Crystal Enterprise Express includes all the same components, they must be run on a single hardware platform and cannot be scaled across multiple computers (the Web Connector being the single exception). Crystal Enterprise Embedded Edition merely consists of the Report Application Server component of the overall CE architecture. Accordingly, most of the topics in the chapter do not apply to CE Embedded Edition. Also, although back-end servers can run on Windows, Sun Solaris, or IBM AIX, this chapter concentrates almost entirely on the Windows implementation of Crystal Enterprise.

Crystal Enterprise consists of ten back end servers, along with a small component that must be placed on every web server used to access a CE system. Each server (except the web server piece) acts as an individual Windows NT service. In the case of Windows NT, 2000, or 2003 Server, you can see each CE server by displaying the Windows Control Panel Services applet from the Administrative Tools folder. You can also launch CE s own Crystal Configuration Manager from the Crystal Enterprise 10 program group to see only services related to CE (including the web server).

CMS

The Crystal Management Server, or CMS, is the heart of Crystal Enterprise 10. This component (known as the Automated Process Scheduler, or APS, in previous CE and Info versions) is the heart of Crystal Enterprise. Every other component communicates through the CMS (the CMS acts as a name server, keeping track of the locations and statuses of the other server components). The CMS also acts as the central security point for Crystal Enterprise login ” all user IDs, passwords, and rights lists are maintained on the CMS. And, the CMS also keeps track of report scheduling. If a report is scheduled to automatically run every day at midnight, the CMS sets the report processing cycle in motion at the prescribed time.

Because the CMS is so critical to the operation of Crystal Enterprise (the entire system is completely dead in the water without it), Enterprise provides for fault tolerance and increased processing capacity with CMS clustering. With CMS clustering, multiple physical computers can run as CMS servers. Sharing a common system database hosted on a standard server platform, such as Microsoft SQL Server or Oracle, all CMS machines appear as one logical CMS to the entire Crystal Enterprise system. They share processing load, sending processing requests to the least-busy machine in the cluster. If one machine should fail, the remaining CMS machines pick up the load and continue to operate ”the end user will not even know that one of the CMS machines has failed.

Web Component Server/Web Connector

The Web Component Server, or WCS, is the front line component of Crystal Enterprise, intercepting all initial requests for Enterprise web pages and reports from the Web Connector and web server. The WCS also processes the Crystal Server Page scripting language to allow complete customization of the Crystal Enterprise user interface in a web browser.

The Web Connector is the actual Crystal Enterprise component that resides on the web server (as mentioned earlier, this is the only CE piece that isn t exposed as an NT service). By moving other Crystal Enterprise components to their own servers and leaving the web server to its preferred task of communicating with web browsers, Crystal Enterprise can achieve much higher levels of performance without bogging down the web server. The Web Connector passes information to and from the WCS, which then communicates among other Enterprise servers to process web page display, Crystal Server Page script interpretation, report viewing, and other Enterprise functions. In particular, the Web Connector looks for web pages with CE-specific file extensions (such as .CSP, .CWR, .CRI, .RPT, and so forth) and passes them to the Web Component Server for further processing.

The other benefit Crystal Enterprise derives from placing a very small demand on the web server is cross-platform web server support. By minimizing the software footprint on the web server, CE supports many popular web servers running on both Windows NT, Unix, and Linux platforms. While the other back-end servers require Windows, Solaris, or AIX to run, there are many Web Connectors that expand web server support to other platforms.

Web Connector configuration with Microsoft IIS is a straightforward process. Simply install the Web Connector on the physical web server machine from the Crystal Enterprise program CD. All necessary path mappings and application extension configuration (.CWR, .CSP, and so forth) are handled automatically. However, other Windows-based, Unix, and Linux-based web servers have various installation and configuration options that are described in detail in the online or printed Installation Guide.

Tip  

In some cases, Web Connectors are not required. For example, if you are operating entirely within a Unix environment or are creating a completely customized CE system via custom ASP, ASPX, or JSP pages, you may not require Web Connector use.

File Repository Servers

As Crystal Enterprise reporting is based on Crystal Reports, procedures for handling the Crystal .RPT files that are published, scheduled, and viewed must be established. Also, new CE 10 program objects and third-party objects (.PDF files, .DOC and .XLS files, executables, Java programs, and script) must be managed for scheduling and viewing. This is where the file repository servers come in. These servers store .RPT files that can be viewed on demand and .RPT files that are to be scheduled on a regular basis (perhaps every night, every week, and so on), as well as the finished copies of scheduled reports ”the .RPT files with saved data that can be viewed after they ve successfully run. They also manage stored copies of third-party files, such as Word and Excel documents and PDF files, as well as script and program files.

There are actually two different file repository servers. The Input File Repository Server (or Input FRS) is where Crystal Report .RPT files, third-party files, and executable/script files are stored after they ve been published with Crystal Reports 10, the Crystal Publishing Wizard, the Crystal Management Console, or the Crystal Import Wizard. In the case of Crystal Reports, these not-yet-run reports are known as Crystal Enterprise report objects.

When a request is received to view a published report on demand, or when the CMS runs a scheduled report on a regular basis, the Input FRS is queried for a copy of the .RPT file to run. Also, when a shared third-party object, such as a Word document, Excel spreadsheet, or Adobe PDF file, is requested for viewing, the Input FRS provides access to the file. And, when program objects are scheduled to be executed, the object is supplied by the Input FRS.

The Output File Repository Server (or Output FRS) keeps all the finished .RPT files with saved data (known as report instances ) that result from reports that are scheduled by the CMS on a regular basis. When an end user wishes to view a report instance, the other Crystal Enterprise components query the CMS, which keeps track of report instances in the Output File Repository Server. The .RPT file with saved data is transferred from this server to other components for caching and HTML formatting, eventually appearing in the end user s web browser. The Output FRS also keeps track of the status of scheduled program objects, such as text files containing the output from the executable or script object that was run. These program instances can be viewed much the same way as report instances are.

Page Server

The Page Server is dedicated to two tasks : creating EPF files and running on-demand .RPT files. This first task comes into play whenever an end user requests to view a completed report. The Page Server communicates with the Cache Server and may be asked to create individual page image files (known as encapsulated page files, or EPF files) that are stored by the Cache Server and delivered to the end user one page at a time. This page-on- demand architecture has been a cornerstone of Crystal Reports performance for several versions. This way, if a report actually encompasses several hundred pages, only the page requested by the viewer will be sent across to the web browser.

The other task given to the Page Server is the processing of on-demand reports. On-demand reports differ from reports scheduled by the CMS on a regular basis, which are handled by the Report Job Server. While the automatic scheduling of reports is a very powerful feature of Crystal Enterprise, certain reporting environments require near-instantaneous access to a current set of data. In these situations, the Page Server is used to run reports against the database in real time whenever a user requests them. By utilizing both on-demand and scheduled reports (and by dedicating servers to each), Crystal Enterprise can satisfy a broad mix of regular production reporting needs versus on-demand ad hoc reporting needs.

Because the Page Server may need to connect to production databases in real time to run on-demand reports, the Page Server is one of the Crystal Enterprise back-end servers that may require special configuration. For example, you ll need to ensure that all possible ODBC data sources and necessary database client software is installed on the computer running the Page Server software. Also, the Page Server may need to be modified to use something other than the default NT System account in order to provide necessary network security credentials. If, for example, a file-based Microsoft Access database is contained on a network share somewhere in your network, the NT System account probably won t have rights to the shared folder where the Access database is located. You ll need to assign the Page Server NT Service an alternate account that exposes the desired network share.

Report Job Server and Report Application Server

While the Page Server can run on-demand reports, another set of servers may also end up running Crystal Reports, depending on how you want the report to run. These two servers, the Report Job Server and the Report Application Server, run reports that are scheduled or designed on the fly, respectively. Also, the choice of report viewer that you make in the CE 10 Web Desktop will sometimes determine which server is used.

The Report Job Server is dedicated to running reports that are scheduled by the CMS. Only reports that run on a regular basis (every day, every week, the first day of the month, and so forth) and create report instances are submitted to the Report Job Server. When the CMS needs to schedule a report to run, it passes the request on to the Report Job Server. The Report Job Server obtains the .RPT file to run from the Input FRS, actually connects to the database to run the report, and sends the completed report instance (an .RPT file with saved data) to the Output FRS.

The Report Application Server, or RAS (which is actually the main component that makes up CE Embedded Edition, discussed in Chapter 22), processes on-demand reports that are viewed in the Interactive DHTML Viewer (viewer choices are discussed in Chapter 25), as well as processing reports that are designed on the fly using the web-based report export, or Crystal Enterprise Ad Hoc. These on-the-fly reporting capabilities, provided with Crystal Enterprise Premium Edition or an extra license for Crystal Enterprise Professional Edition, make use of the RAS for report processing. And, the Interactive DHTML viewer s sub-query capabilities make use of the RAS s own caching capabilities, which are separate from the Page Server/Cache Server interaction discussed elsewhere in this chapter.

Because the Report Job Server and Report Application Server may need to connect to production databases to run reports, they may require special configuration. For example, you ll need to ensure that all possible ODBC data sources and necessary database client software are installed on the computers running the Report Job Server or Report Application Server. Also, these servers may need to be modified to use something other than the default NT System account in order to provide necessary network security credentials. If, for example, a file-based Microsoft Access database is contained on a network share somewhere in your network, the NT System account probably won t have rights to the shared folder where the Access database is located. You ll need to assign the Report Job Server or Report Application Server NT Service an alternate account that exposes the desired network share.

Tip  

Depending on how your Crystal Enterprise system will be used, you may find processing bottlenecks occuring on the various job servers or the Page Server. If you schedule a great number of large reports to run on a regular basis, and many of these scheduled reports run at the same time, you may find the need to add additional job servers to your Enterprise system. However, if your primary crunch is on-demand reports, or viewing a large number of reports (which requires a large amount of EPF generation), you ll want to consider adding additional Page Servers to your Enterprise system. If your primary reporting requirement is Interactive DHTML viewing or web-based report design, you may need to add additional Report Application Servers to your CE system.

Program Job Server

Crystal Enterprise 10 introduces the ability to schedule program objects, as well as report objects, on a regular basis (every day, the first day of the week, once a month, and so on). Program objects (consisting of executable programs, Java programs, and JScript or VBScript code) allow you to run maintenance tasks, data warehouse imports, or anything else that can be custom-coded, within the Crystal Enterprise environment.

The Program Job Server is responsible for running program objects that are scheduled by the CMS. Much as with the Report Job Server, the Program Job Server intercepts requests for program object schedules from the CMS. It then queries the Input FRS for the necessary program object files, runs the program object, and sends the standard and error output from the program object to the Output FRS, where it is stored as a program instance.

Cache Server

As discussed earlier in the chapter, one of the benefits of Crystal Enterprise (and of several versions of Crystal Reports before it) is page-on-demand architecture. This approach to delivering report pages to the end user s web browser significantly improves performance, especially with larger reports that comprise many pages. The page-on-demand process will deliver only the page of a report that a viewer currently needs to see. When a report is first viewed, only page 1 is delivered to the viewer. If, for example, the viewer then clicks an entry in the group tree that requires page 210 of the report to be delivered, only page 210 is sent to the browser ”pages 2 through 209 are ignored.

As discussed previously, part of this page-on-demand process is the creation of EPFs, which is handled by the Page Server. The other very important part of this process, however, is storing already viewed EPFs for later reuse (known as caching ). This process is handled by the Cache Server. The Cache Server and the Web Component Server communicate very closely with each other. The Cache Server keeps track of pages that may have already been viewed (and that are already cached). When the Web Component Server makes a page request of the Cache Server, the Cache Server checks to see if the page already exists in its cache. If the Cache Server can find an already-generated EPF, it simply sends it for viewing. If the Cache Server needs the EPF to be generated (a user, for example, has asked for a report page that hasn t been viewed previously), it asks the Page Server to generate the EPF, which it then caches and sends to the Web Component Server.

Note  

As discussed earlier, if a viewer uses the Interactive DHTML Viewer to view a report, the Cache Server/Page Server interaction discussed here does not apply. The Report Application Server, instead, handles the page-on-demand viewing procedures for the report viewer.

Event Server

When you schedule a report or program object to run, you may choose to base the schedule on an event. This event might consist of the successful completion or failure of another report or program object. Or, the event may simply consist of a specifically named placeholder that can be turned on or off by a completion or failure of a job. Or, the event may consist of the existence of a certain file somewhere on your network. While these first two types of events are managed entirely by the CMS, a separate server is used to manage file-based events.

The Event Server manages file-based events. When a job is scheduled on the basis of a file event, the Event Server is charged with looking on the network in a specified location for the existence of the file (the contents of the file are irrelevant ”the Event Server is only concerned with whether the file exists or not). If the file exists, the Event Server notifies the CMS and the dependent job is processed .

Because of the need to navigate various folders and file structures on your network, the Event Server may be required to use something other than the default NT System account. If, for example, a file that will be used as a trigger for a file event is contained on a network share somewhere in your network, the NT System account probably won t have rights to the shared folder where the file is located. You ll need to assign the Event Server NT Service an alternate account that exposes the desired network share.

Scaling Crystal Enterprise

In many situations (especially smaller to medium production installations, or initial test or proof-of-concept installations), a single-server hardware platform will be quite adequate to support all Crystal Enterprise servers. There is nothing to prevent a single, stand-alone installation of the entire Crystal Enterprise system to be performed on a Windows NT, 2000, or 2003 Server computer with IIS configured and running. In fact, if you insert the Crystal Enterprise CD and choose the New deployment option, that s typically what happens.

In more complex or advanced implementations , however, you may want to separate various software server components over several hardware platforms. For example, you may wish to mix Unix and Windows versions of certain server components, installing some servers on Solaris or AIX and others on Windows. Perhaps you wish to cluster multiple physical CMS servers to provide fault tolerance. Or, you may wish to set up multiple machines to take the load off an overtaxed single server and spread the load among several servers (perhaps installing multiple Page Servers or Job Servers on separate machines).

This involves more complex installation planning and additional administrative tasks. Keep in mind the following general points when expanding to multiple hardware platforms to make up a single CE implementation:

• All machines should be able to communicate with each other via TCP/IP. Machines must be able to communicate via IP address or machine name. Firewalls can cause difficulty if various CE servers need to communicate across them. Note configurable port assignments in the Crystal Configuration Manager (discussed later in the chapter) for each server and open up these ports in the firewall to allow servers to properly communicate with each other.

• If you will cluster CMS computers, they must all be able to communicate with one common SQL database server that stores the CMS database tables.

• Install a CMS as one of the first servers in a multiserver environment, as other servers will ask for a CMS name when installed. Use the Expand or Custom option from Crystal Enterprise Setup to choose which server components you want to install on individual computers.

• In CE environments that cross geographic boundaries or connect various components over wide area network (WAN) connections, consider carefully where components should be placed. For example, it s probably preferable to place Page Servers or Job Servers on the same local network segment as the production database, as opposed to another side of the WAN. Then, if necessary, other CE components can be placed across the WAN, as only .RPT files or other smaller-scale data chunks will need to be sent across the WAN between CE servers.