The Crystal Enterprise Architecture in Action

This section takes a look at how all the Crystal Enterprise services come together and which of the services are used when a user requests objects. Each scenario is based on the following situation: Over a corporate intranet site, a user is browsing a Web page that connects him to a Crystal Enterprise system. The user has provided proper login credentials and is logged into Crystal Enterprise. He has been presented with a list of report objects that he has rights to access.

For this scenario to occur, a browser has connected to a Web server, and in turn the Web server passes the processes the Web page. For instance, if the page is written in JSP, the Java application server passes a request to the Crystal Enterprise Framework via the CE-SDK classes loaded on that application server. The continued interaction between the user and Crystal Enterprise Framework occurs through the facility of the CE-SDK on the application server.

If you are using the CSP pages provided in a COM environment, the Web Connector running on the Web server intercepts the file request because it has a .csp extension, and passes this request to the WCS for processing. The .csp is processed and in this scenario, the page asks the user for logon credentials and is returned to the user to complete. The credentials are submitted and passed to the WCS. The WCS now takes this information and attempts to log on to the CMS using the security service. After the user is logged on to Crystal Enterprise, the CMS is queried to present a list of folders and reports to the user. (The query is generated within the CSP page as well.) This scenario diagram can be seen in Figure 24.4.

Figure 24.4. The login process for a user validated by Crystal Enterprise.

For simplicity, the following examples will use the COM environment. To determine how this would relate to the Java or .Net environments, the role of the WCS and Web Connector would be replaced with the CE-SDK running on the appropriate server. The CE-SDK, loaded into the server, communicates directly with the Crystal Enterprise Framework.

NOTE

The numbered flow in Figures 24.4, 24.5, 24.6, and 24.7 represents the flow of information and requests to get a report processed and delivered to the end user. Dashed lines in the figures represent optional steps.

Figure 24.5. The report-loading process in Crystal Enterprise.

Figure 24.6. The report loading process for on-demand viewing.

Figure 24.7. The process for scheduling reports.

 

Requesting a Crystal Report

The user in the preceding scenario has two methods of viewing a report.

The first method is to view an instance of a previously scheduled job. If an instance is chosen, the report contains cached data from when the job was run. When the request to view the report is received, the WCS asks the Cache Server if the first page of this report is available in cache. If the first page is available, the Cache Server returns the page to the WCS so it can be delivered to the report viewer. The report viewer then displays the report for the user. If the page is not in the cache, the request is forwarded onto the Page Server to generate the page.

As Figure 24.5 shows, when the Page Server receives the request, it loads the report from the output File Repository Server. After the Page Server loads the report, it generates the page that has been requested and then passes it back to the Cache Server. The Cache Server sends the page onto the WCS to be given to the report viewer.

The second method for viewing a report is to view the report itself, which is also known as on-demand viewing. If a user selects the report itself, she must first have the "view on demand" access level. When the report is requested it goes through the same process as shown in Figure 24.5; however, because the report does not have any cached data within the report like the instance has, the Cache Server passes the request directly onto the Page Server.

Figure 24.6 shows the extra steps required for on-demand viewing. The Page Server queries the input FRS for the report and loads it. After the report loads, the user will be asked to enter the database logon information and any parameters for the report to run. The Page Server then passes this information to the Crystal Reports engine through the report plug-in. The Crystal Reports engine connects to the database and queries for the necessary data. After the data has been returned to the report engine, the report is recalculated and page information is determined. The Page Server now generates the first page of this report and sends it to the Cache Server, which in turn passes it to the WCS and then to the report viewers.

In both scenarios of viewing a Crystal Report, if a processing extension is being used with this report, the cache is then not sharable. The Cache Server will pass the request directly to the Page Server. The Page Server will load the report from the FRS. During the time that the report is being loaded, the processing extension is engaged to determine the proper row-level restrictions that need to be applied to the cached data within the report. The cached data is then filtered and the page is generated with information that is viewable by that user only.

Scheduling a Crystal Report

When a report is scheduled, Crystal Enterprise requires the appropriate information so that the scheduling service knows what tasks are to be performed. Figure 24.7 depicts a typical scenario where an end user schedules a report with the appropriate criteria set. This information is passed to the WCS, which in turn forwards the information to be stored in the CMS. The schedule is set to run at a particular point in the future. When the schedule time occurs, the CMS loads the information from the repository and submits the request to a Job Server. The Job Server asks the input FRS for the report and then loads it into the report Job Server plug-in.

With the report loaded, the Job Server applies any of the parameters set when the user scheduled the report earlier. These parameters might be filters that affect the overall data query. If a processing extension is in use, the report would be further manipulated. After the processing extension is finished with the report, the Job Server connects to the database and completes the processing of the report.

When the job has completed, the Job Server checks two remaining pieces of information the user would have set when scheduling the report; the format in which the report is to be delivered and where it will be delivered. At this stage, the Job Server would output the report into a supported Crystal Enterprise format, including Crystal Reports, Microsoft Word, Excel, Adobe Acrobat, Rich Text Format, or text.

NOTE

The default output format for all Crystal Enterprise servers is Crystal Reports.

Next, the Job Server needs to distribute the report to the desired location. As previously mentioned, these locations can be a location on disk, an FTP server, or an e-mail address, or remain in the managed Crystal Enterprise environment by distributing it to the output FRS as a report instance object. Regardless of where the user decides to distribute the object, a copy is always stored in the output FRS so that it can be shared between users.

Requesting a Crystal Analysis Report

If an organization is using Crystal Analysis Professional, it's important to note that report viewing is handled differently from a Crystal Report. Requesting a Crystal Analysis report starts by the user clicking on a link to the report in a Web browser.

The request is delivered to the WCS, and it asks the CMS for the object that was asked for. The object is returned to the WCS and then is loaded by the Crystal Analysis engine. The reports created in Crystal Analysis are dynamic queries to a multidimensional cube of datathe CA engine must connect to the cube referenced in the report.

After a connection to the cube is made, data is retrieved and populated into the .car file, which is an XML document. This XML document is transformed through a style sheet into DHTML and delivered as the first view of the report. This information is sent from the WCS to the Web browser along with the Crystal Analysis DHTML viewer. The viewer makes additional requests for data from the cube via the WCS as it is needed to populate the view of the report.