- Exploring the System Architecture
- Crystal Enterprise Architecture Overview
- Introduction to the Crystal Enterprise Framework
- Overview of the Crystal Enterprise Servers
- The Crystal Enterprise Architecture in Action
- Taking Advantage of the Crystal Enterprise Distributed Architecture
- Extending Crystal Enterprise
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
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 CSP 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 .CSP request to the Crystal Web connector. The Web connector then passes this request to the Web Component Server 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 Web Component Server. The Web Component Server now takes this information and attempts to log on to the APS using the security service. After the user is logged on to Crystal Enterprise, the APS 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 3.4.
NOTE
The numbered flow in Figures 3.4, 3.5, 3.6, and 3.7 represent 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.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
Figure 3.4 The login process for a user validated by Crystal Enterprise.
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 Web Component Server 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 Web Component Server 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 3.5 shows, when the Page Server receives the request, it loads the report from the output File Repository Server. After the report is loaded by the Page Server, 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 Web Component Server to be given to the report viewer.
Figure 3.5 The report-loading process in Crystal Enterprise.
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 3.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 3.6 shows the extra steps required for on-demand viewing. The Page Server queries the input File Repository Server for the report and loads it. After it has the report loaded, 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 Web Component Server and then to the report viewers.
Figure 3.6 The report loading process for on-demand viewing.
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 File Repository Server. 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 3.7 depicts a typical scenario where an end user schedules a report with the appropriate criteria set. This information is passed to the Web Component Server, which in turn forwards the information to be stored in the APS. The schedule is set to run at a particular point in the future. When the schedule time occurs, the APS loads the information from the repository and submits the request to a Job Server. The Job Server asks the input File Repository Server for the report and then loads it into the report Job Server plug-in.
Figure 3.7 The process for scheduling reports.
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 File Repository Server as a report instance object. Regardless of where the user decides to distribute the object, a copy is always stored in the output File Repository Server so that it can be shared between users.
Requesting a Crystal Analysis Professional 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 Professional report starts by the user clicking on a link to the report in a Web browser.
The request is delivered to the Web Component Server, and it asks the APS for the object that was asked for. The object is returned to the Web Component Server and then is loaded by the Crystal Analysis Professional engine. The reports created in Crystal Analysis Professional are dynamic queries to a multidimensional cube of data—the 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 Web Component Server to the Web browser along with the Crystal Analysis Professional DHTML viewer. The viewer will make additional requests for data from the cube via the Web Component Server as it is needed to populate the view of the report.