Release 6i
A73173-01
 Contents |
 Index |
| Oracle Reports Publishing Reports Release 6i A73173-01 |
|
In today's fast-moving, competitive business world, clear and up-to-date information is needed for the accurate, expedient decision making requirements of an often geographically distributed workforce. The timely distribution of that information must be reliable, cost effective, and accessible to everyone who requires it. Oracle Reports provides an unbounded, easy-to-use, scalable, and manageable solution for high-quality database publishing and reporting.
Oracle Reports is a powerful Enterprise Reporting tool used by IS developers to create sophisticated dynamic reports for the Web and across the enterprise.
Oracle Reports Application Server based architecture means report consumers require only a Web browser to view reports in industry standard formats. The Oracle Reports Server supports on-demand delivery of high-quality reports over the Web through native generation of HTML with Cascading Style Sheets and Adobe's Portable Document Format (PDF). Maintenance overheads are cut as reports are administered and maintained centrally and there is no requirement to install complex software on every user's PC.
The Reports Server enables you to implement a multi-tiered architecture for running your reports. With the Reports Server, you can run reports on a remote application server.
When used in conjunction with the Reports Web CGI or Reports Servlet, the Reports Server also enables you to run reports from a Web browser using standard URL syntax. The Reports Server can be installed on Windows NT, Windows 95, or UNIX. It handles client requests to run reports by entering all requests into a job queue. When one of the server's runtime engines becomes available, the next job in the queue is dispatched to run. As the number of jobs in the queue increases, the server can start more runtime engines until it reaches the maximum limit specified when the server process was started. Similarly, idle engines are shut down after having been idle for longer than a specified period of time.
The Reports Server keeps track of a predefined maximum number of past jobs. Information on when the jobs are queued, started, and finished is kept, as well as the final status of the report. This information can be retrieved and reviewed on Windows from the Reports Queue Manager (RWRQM60) or via the API. The Reports Queue Manager may reside on the same machine as the Reports Server or on a client machine. On UNIX, you can use the Reports Queue Viewer (RWRQV60) to view the Reports Server's queue.
The Reports Server can be configured in a number of ways depending upon your requirements. When used in a Web environment, the Reports Server architecture consists of four tiers1:
The range of possible configurations runs from having all of these tiers on one machine to having each of these tiers on a separate machine. The most common configurations typically have the tiers spread across three or four machines. The graphics that follow provide a conceptual view of these common configurations.
Note: In the non-Web case, which will be discussed later, there are only three tiers because the Web server tier is not necessary.
The diagrams that follow illustrate two of the most common configurations for the Reports Server in a Web environment. The key difference between the two configurations is whether the Reports Server and Web server tiers are on the same or different machines. In the first case, the Web server and Reports Server reside on the same machine. In the second case, they are on different machines. The latter case requires a slightly different setup from the first.
The non-Web architecture differs from the Web architecture in that there is no Web browser or Web server. Report requests are sent to the Reports Server from a thin client such as the Reports Launcher or command line, RWCLI60. The non-Web architecture is useful to those who cannot use the Web to deploy their reports for some reason.
The configuration of the Reports Server can vary widely depending upon the requirements of your system. Before attempting to configure the Reports Server, you must make a number of important decisions based upon your requirements. By making these decisions beforehand, you can greatly simplify the configuration process. These decisions are discussed in the following sections.
As you saw in Section 2.2, "Reports Server architecture", the Reports Server can accept job requests from both Web and non-Web thin clients. In the Web case, users run reports by clicking or typing a URL in their Web browser and, depending on the URL, the report output is served back to them in their browser or sent to a specified destination (e.g., a printer). In the non-Web case, users launch job requests using client software installed on their machines (i.e., Net8 and the Reports Thin Client, which is comprised of the Reports Launcher, the Reports Queue Manager, and RWCLI60).
To enable users to launch reports from a Web client, you need to install either the Reports Web CGI or Servlet with your Web server to communicate between the Web server and the Reports Server. The Web CGI or Servlet is required for your Web server to process report requests from Web clients. For more information, refer to the Section 2.3.2, "Choose the Reports Web CGI or Servlet". To enable users to launch reports from a non-Web client, you need to install the required client software (i.e., Net8 and the Reports Thin Client) on each machine from which you plan to launch report requests.
From the perspective of configuration, the key differences between enabling Web and non-Web requests is as follows:
The Web case is clearly the most cost effective because it reduces client maintenance costs, but there may be cases where launching non-Web requests is a necessity for other reasons. The Reports Server supports both Web and non-Web requests and they are not mutually exclusive.
As discussed in Section 2.3.1, "Enable Web and non-Web requests", to use the Reports Server in a Web environment, you must install and configure the Reports Web CGI or Servlet to handle the transmission of job requests and output between your Web server and the Reports Server. The key consideration in this choice is the following:
As described in the Section 2.2, "Reports Server architecture", you can place the Reports Server on the same machine as your Web server or on a different machine. As you make this decision, you should consider the following:
Once you have made your configuration choices, you are ready to configure the Report Server. Section 3.2, "Configuring the Reports Server: Reports Web CGI example" provides a step-by-step configuration example using Web CGI.
Section 3.4, "Reports Servlet configuration guidelines" provides for guidelines configuring the Reports Server using the Reports Servlet.
1
The term tier refers to the logical location of the components that comprise the Reports Server architecture. Each of the tiers, though, could reside on the same or different machines.
2
The Reports Web Cartridge is another way to communicate with Reports Server when you are using the Oracle Application Server as the Web server.
3
The Reports Web Cartridge is another way to communicate with Reports Server when you are using the Oracle Application Server as the Web server.
4
For any job request that you send to the Reports Server, you can include a TOLERANCE argument. TOLERANCE defines the oldest output that the requester would consider acceptable. For example, if the requester specified 5 minutes as the TOLERANCE, the Reports Server would check its cache for duplicate report output that had been generated within the last five minutes.
5
When you configure the Reports Server, you can specify the maximum number of runtime engines it can use. If the Reports Server is under this maximum, it may start new runtime engines to handle requests. Otherwise, the request must wait until one of the current runtime engines completes its current job.
|
 Copyright © 1999 Oracle Corporation. All Rights Reserved. |
|