Introducing Servers

Crystal Enterprise is built on the Crystal Enterprise Framework. At a high level, the Framework provides a communications bus between the various services or daemons that make up Crystal Enterprise.

Services or daemons, in the Windows or Unix environments respectively, are compartmentalized processes that perform a specific task. The use of individual services affords fault-tolerance (service redundancy), load-balancing, scalability, and greater system reliability. Crystal Enterprise uses the generic term "server" to refer to these services or daemons; for instance "Job Server." For simplicity, this book uses the product nomenclature: that is, server. The reader should realize that servers in this case are not physical machines. Please see Chapter 24 for additional discussion on this topic.

Configuring Servers

Managing Crystal Enterprise servers is straightforward with the CMC. You can use the CMC to stop, start, restart, and manage various services from almost any location on the network.

To manage servers, select Servers from the CMC drop-down menu. Figure 27.35 shows a standard list of Crystal Enterprise servers in the CMC. Buttons in the upper-right corner enable you to start, stop, restart, delete, disable, or enable any server on the framework. Additionally, the Crystal Enterprise administrator can specify the order of the servers list by clicking on the column heading to specify a sort order.

NOTE

A disabled server cannot be started until it is enabled, even if the machine is rebooted. Disabling a server can be useful for, among other things, temporarily interrupting the servers availability while maintenance tasks or hardware repairs are performed.

Clicking on each server navigates to the server settings area. The Properties tab provides server-specific management controls. The metrics tab shows a wide range of information about the performance of the server and the physical machine on which it resides (see Figure 27.36). The Rights tab again provides a way for delegated administration to take place because the system administrator can allow area administrators to have access to certain servers but not others. Finally the Auditing tab, when available, determines which features on each server are audited (see Chapter 24 for a complete discussion of auditing capabilities).

Managing the Web Component Server

The Web Component Server (WCS) has several configuration options available from the Properties tab shown in Figure 27.37. To access this tab, click the WCS name on the main Servers page.

Various logging options for recording WCS activity are also displayed. Generally these should be left unchanged except for specific troubleshooting purposes. Excessive logging consumes system resources unnecessarily.

NOTE

The WCS logs can be an excellent source of data for system auditing, such as which users are viewing certain reports. Consider building a Crystal Report from the WCS logs. Business Objects provides some prebuilt WCS log reports as well.

Options for managing report viewer availability and behavior are located at the bottom of the Web Component Server Properties page. These options enable a Crystal Enterprise administrator to specify which actions (drill-down, print, zoom, export, search, and so on) users can perform in the different report viewers.

Remember to click either Update or Apply to commit the changes. Changes to the WCS configuration do not take effect until the WCS service is restarted.

Managing the Cache Server

To adjust the settings for the Cache Server, click the Cache Server name from the main Servers screen. The Properties tab shown in Figure 27.38 appears for the Cache Server. The Location of Cache Files field contains the path to the actual cached report files. This path is local to the Cache Server machine. The Maximum Cache Size Allowed field specifies the maximum size of the cache directory. When the threshold has been exceeded, Crystal Enterprise deletes the oldest, least-used cache files first. Preserving old cache files is not critical because missing cache files can be rebuilt on-the-fly, transparent to the user.

The Maximum Simultaneous option restricts the number of application threads that can be spawned concurrently by the cache server. A processing thread is responsible for converting .rpt pages into cache pages. In most cases, its not necessary to adjust the automatic setting.

The Minutes Before an Idle Connection option causes the cache server to release a stale cache page from RAM to make room for other cache pages. The cache page is still physically stored on the disk, but its no longer kept in RAM. By default, cached pages that have not been requested for 20 minutes are released from RAM and will have to be reloaded from the disk if they are requested again.

Oldest On-Demand Data controls the persistence of cached pages for on-demand reports. For example, assume that John requests an on-demand copy of the World Sales Report at 3:00 p.m. A few minutes later, at 3:04 p.m., Jane requests an on-demand copy of the World Sales Report with exactly the same parameters and record selection formula as John specifiedan identical report in every way. In this case Crystal Enterprise serves Jane the same cached pages that John loaded only moments before. This has the benefit of giving Jane the fastest possible response time while relieving the database and Page Server of additional processing work. By default, on-demand cached pages expire after 20 minutes.

Keep in mind that users have the option to hit the database and rerun the report by clicking the Refresh button within the report viewer. The Viewer Refresh Always Yields option causes the report to be rerun against the database, not the cached data, if the user clicks the Refresh button within the report viewer. Normally, this option should remain enabled to give users the flexibility to "freshen" the report data at their convenience.

Managing the Event Server

The Event Server, as explained in Chapter 24, is designed to allow Crystal Enterprise to interact with events external to the system. Events are conditions that trigger report processing to occur. The Crystal Event Server polls the system at set intervals to determine whether any configured events have been triggered. This is shown in Figure 27.39.

The File Polling Interval in Seconds option enables you to control the frequency of the Event Servers polling process. A lower value results in faster recognition of triggered events, but it also expends CPU cycles that might otherwise be devoted to more important tasks. A value of 1060 seconds between system polls is generally acceptable.

Managing the Page Server

The Crystal Page Server handles on-demand report requests. The Properties tab of the Page Server has several options for controlling Page Server performance, as shown in Figure 27.40. The Maximum Simultaneous Processing Threads setting controls the maximum number of concurrent application threads allowed. On-demand reports consume a minimum of one processing thread; if all available threads are busy, Crystal Enterprise queues any excess threads for processing on a first-come, first-served basis.

The Minutes Before an Idle Connection Is Closed option affects the persistence of open Page Server jobs. For example, if a user starts to view an on-demand report and walks away from her desk without closing the report viewer, the job is left open until the specified period of inactivity has passed. If the user does not request any new pages within the default 20-minute window, the job is closed. New page or drill-down requests reset the 20-minute job expiration timer.

Managing the Job Servers

The Maximum Jobs Allowed setting in Figure 27.41 affects the maximum number of reports that the Job Server can execute simultaneously. A setting of five concurrent report jobs is generally considered a harmonious balance between report throughput and server resources. Each concurrent report thread consumes significant system resources, not only in CPU cycles, but also in temporary disk space use, RAM overhead, and database resources. A robust multiprocessor machine with 2GB of RAM can comfortably process 10 jobs simultaneously. However, most servers run best with five or fewer concurrent jobs.

Managing the Crystal Management Server

The Crystal Management Server (CMS) is responsible for object and user security as well as scheduling of jobs. The CMS is the brain of Crystal Enterprise.

In addition to its role in enforcing object permissions, the CMS monitors and records the processing status of every scheduled job. The Properties tab of the CMS displays a listing of all currently connected users, as well as the number of sessions opened by each user ID (see Figure 27.42). Note that most of the time, a user ID has only one session open. However, its possible for two people to log in with the same user ID from different computers, in which case the user ID would reflect two concurrent sessions. Each session consumes a license until the user logs off, or the session is released after 20 minutes of inactivity.

Possibly the most critical feature of the CMS is clustering. Crystal Enterprise includes out-of-the-box clustering capability for the CMS. This means that without any special hardware, two physical CMS servers can be clustered together. If one becomes unavailable, the other CMS supports authentication requests and scheduling tasks. CMS clustering is reviewed in the "Managing Crystal Enterprise System Settings" section of this chapter.

Managing the Input/Output File Repository Servers

File Repository Servers (FRS) are services that manage the storage and retrieval of report files from the file system. Crystal Enterprise has an Input FRS and an Output FRS. Both FRS systems store report files using a proprietary naming convention. For example, the report template for the World Sales Report might be named 73422e16f293d0.rpt by the Input FRS. Any instances of the World Sales Report would be assigned a similarly cryptic name by the Output FRS. Both FRS servers store name translation information in the CMS system database, enabling users to see the true English name of a report instead of the cryptic file system name.

The Properties tab in Figure 27.43 for the Input and Output FRS has two configuration options. The Root Directory field stores the path of the physical file repository on the servers file system. This path is local to the FRS server. The Input FRS stores .rpt templates in one folder, whereas the Output FRS stores .rpt instances in another folder. Both servers also have a Maximum Idle Time option that controls the amount of time that an idle .rpt file remains cached in the FRS memory. When the idle time expires, the .rpt files are dropped from the memory cache and must be loaded from disk if required again.

Managing Server Groups

A large Crystal Enterprise deployment can have several physical Page and Job Servers spread over a wide area network. Some of the servers might have more processing power than others, and some might be located in specific regions such as San Francisco and New York. In multiple-server environments, its often advantageous to categorize servers into specific groups. Server groups are helpful for managing processing just as user groups help manage permissions.

After a server group has been created, the Crystal Enterprise administrator can configure reports to process on specific server groups. For example, the CEOs personal reports could be configured to execute on a server group that contains one or more high-powered Job/Page Servers. This would ensure that the CEOs reports always process on the most powerful servers available, and thereby finish running as quickly as possible. Without server groups, the CEOs reports might get routed to a slower Job/Page Server, and the CEO would end up spending more time than necessary waiting for critical information. Server groups are also useful for forcing reports to execute on a Job/Page Server that is in close proximity to the reports database server.

To create a server group, select Server Groups from the drop-down menu in the CMC. Click New Server Group, and then type the name of the server group in the Server Group Name field. An optional Description for the server group can also be entered. Click the OK button to add the new server group to Crystal Enterprise. Figure 27.44 shows a server group.

Managing Calendars

The predecessor to Crystal Enterprise included a very popular feature for scheduled processing: business calendars. Simply put, this feature allows processing to take place based on specific calendars. Calendars can be configured by administrators and then selected by users for scheduling purposes.

Click on the Calendars icon from the home page of the CMC to enter the Calendars area.

NOTE

The Calendars area has a rights button at the upper right to set delegated administration privileges. Setting permissions here controls access to this area in the CMC.

You can add new calendars or manage current calendars here. Like most objects in Crystal Enterprise, you see a simple Properties tab and Rights tab, which operate like the other tabs of those titles. The Dates tab, however, provides the heart of the functionality by allowing the administrator to configure a calendar. By clicking on months to enter that month, then clicking on days to select/de-select a day, the administrator sets days on which processing should occur. By simply clicking on a day you change the current setting, clicking on a row or column header selects that area. The drop-down at the top also exposes other calendar configuration types to allow tailoring to another calendaring optionfor instance, a quarterly fiscal calendar with a set alternating number of weeks in a "fiscal month" that does not align with calendar months. That way you could configure a financial report to run on the first day of every quarter or fiscal month, for instance.

After calendars are configured, the administrator or end users would schedule reports using the Calendar option from the scheduling page.

Managing Events

Although I touch on Events in the discussion of servers, the administrator must set up events before they can schedule against them. The Events link from the home page navigates to the Events area, where you can add new events. There are three types of events. The File event polls for a certain file in a certain location to appear. The Schedule event polls for success or failure of another scheduled object. The custom event provides a programmatic hook that can be triggered by a program written against the SDK to provide a programmatic interface into the scheduling system. Once created, events can be used for scheduling as per the previous section.