The BusinessObjects Enterprise Architecture in Action

This section takes a look at how all the BusinessObjects 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 BusinessObjects Enterprise system. The user has provided proper login credentials and is logged into BusinessObjects 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 with a request for BusinessObjects Enterprise. The request, assuming it does not require WCA processing, is passed from the Application server to BusinessObjects Enterprise Framework via the BOE SDK. For example, if the page is written in JSP, the Java application server passes a request to the BusinessObjects Enterprise Framework via the BOE SDK classes loaded on that application server. The continued interaction between the user and BusinessObjects Enterprise Framework occurs through the facility of the BOE SDK on the application server.

If you are using the CSP pages provided in a COM environment, the request is passed to the WCA 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 WCA. The WCA now takes this information and relays it to the CMS via the BOE SDK. After the user is logged on to BusinessObjects 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 25.4.

Figure 25.4. The login process for a user validated by BusinessObjects Enterprise.

If you are connecting to the BusinessObjects Enterprise via the Web Component Adapter or directly through the SDK, the general process flow remains the same. For simplicity, the following examples will use the .Net and Java environments without pointing out when the Web Component Adapter is invoked.

Note

The numbered flow in Figures 25.4, 25.5, 25.6, and 25.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 25.5. The report-loading process in BusinessObjects Enterprise.

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

Figure 25.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 Cache Server is interrogated to see 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 Application 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 25.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 Application Server 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 25.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 25.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 Application Server 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, BusinessObjects Enterprise requires the appropriate information so that the scheduling service knows what tasks are to be performed. Figure 25.7 depicts a typical scenario where an end user schedules a report with the appropriate criteria set. This information is passed to the Application Server, 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 BusinessObjects Enterprise format, including Crystal Reports, Microsoft Word, Excel, Adobe Acrobat, Rich Text Format, Editable Rich Text format, or text.

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 BusinessObjects Enterprise environment by distributing it to the output FRS as a general report instance object or inbox 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 further shared between users.

Requesting a OLAP Intelligence Report

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

The request is delivered to the Application Server, and it asks the CMS for the object that was asked for. The object is returned to the Application Server and then is loaded by the OLAP Intelligence engine. The reports created in OLAP Intelligence are dynamic queries to a multidimensional cube of datathe OLAP Intelligence 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 Application Server to the Web browser along with the OLAP Intelligence DHTML viewer. The viewer makes additional requests for data from the cube via the Application Server as it is needed to populate the view of the report.