| Oracle9iAS Reports Services Publishing Reports to the Web
Release 2 (9.0.2)
Part Number A92102-01
When you're ready to publish your reports, all the Web server and application server tools you'll need are available in the Oracle9i Application Server (Oracle9iAS). This chapter describes the architecture of relevant Oracle9iAS components in combination with its reports publishing component: Oracle9iAS Reports Services. It also provides an overview of reports runtime processing and offers some things to consider when you set up your server environment.
This chapter includes the following sections:
Oracle9iAS is a comprehensive and integrated application server that runs any Web site, portal, or Internet application. It enables you to make applications available from Web browsers, mobile devices, and command lines. Oracle9iAS Reports Services is the reports publishing component of Oracle9iAS. It is an enterprise reporting service for producing high quality production reports that dynamically retrieve, format, and distribute any data, in any format, anywhere. You can use Oracle9iAS Reports Services to publish in both Web-based and non-Web-based environments.
Oracle9iAS Reports Services provides a scalable, flexible architecture for the distribution and automated management of report generation engines on the same server and across multiple servers. Additionally, it caches report outputs for reuse on similar requests. It integrates into standard Web environments with JSPs, Java Servlets, and CGI. It enables you to run reports on both local and remote application servers and to implement a multi-tiered architecture for running your reports.
When used in conjunction with servlet, JSP, or CGI (maintained only for backward compatibility), Oracle9iAS Reports Services enables you to run reports on any platform from a Web browser using a standard URL syntax. For servlet implementations, the in-process server is available for faster response and easier administration. The in-process server cuts down on the communication expense between processes and consequently increases response times.
Oracle9iAS Reports Services handles client requests to run reports by entering all requests into a job queue. When one of the server's 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 engines until it reaches the maximum limit specified in your server configuration. Similarly, engines are shut down automatically after having been idle for a period of time that you specify (see Chapter 3, "Configuring Oracle9iAS Reports Services").
Oracle9iAS Reports Services keeps track of all jobs submitted to the server, including jobs that are running, scheduled to run, finished, or failed. The Reports Queue Manager (Windows), the Reports Queue Viewer (UNIX), the
showjobs command (Web), and the Reports Services pages in Oracle Enterprise Manager (OEM) enable you to view information on when jobs are scheduled, queued, started, finished, and failed, as well as the job output and the final status of the report.
With Oracle9iAS Reports Services, job objects are persistent. This means that if the server is shut down then restarted, all jobs are recovered, Foot 1 not just scheduled jobs.
When used in a Web environment, the Oracle9iAS Reports Services architecture consists of four tiers:
The term tier refers to the logical location of the components that comprise the Oracle9iAS Reports Services architecture. Each of the tiers, though, could reside on the same or different machines.
When used in a non-Web environment, there are three tiers (a Web server being unnecessary):
The way you set up these tiers can range from having all of them on one machine to having each of them on a separate machine. Additionally, you can have multiple Web servers on multiple machines as well as multiple application servers on multiple machines.
If you choose to have your Web server on multiple machines, the Oracle9iAS HTTP Server provides a load balancing feature to allow sharing of the Web server load across multiple machines. If you choose to have your application server on multiple machines, Oracle9iAS Reports Services provides peer-level clustering to allow sharing of the Reports Server load among multiple machines.
The difference between load balancing and peer clustering is that with load balancing, one machine manages the traffic across all machines; while with peer clustering, all machines are aware of the traffic on each machine, and each machine shares the task of monitoring and responding to requests. The advantage of peer-level clustering is the elimination of a single point of failure, further supporting the possibility of a fail-safe environment.
Reports Server clustering is discussed in detail in Chapter 6, "Reports Server Clusters".
Oracle9iAS Reports Services provides event-based reporting. This uses database events to trigger the generation of a report. For example, you can define an event that signals a change in revenue levels above or below a particular watermark. If the change occurs in the database (the event), a report is automatically generated. This feature is discussed in detail in Chapter 11, "Event-Driven Publishing".
Oracle9iAS Reports Services includes a distribution module that uses XML to define unique configurations for the distribution of reports. Call the desired XML file from the runtime command line or URL to generate one report, and let the server handle diverse outputs and destinations. Processing time is significantly reduced and configuration changes can all be handled within the XML file. This feature is discussed in detail in Chapter 9, "Creating Advanced Distributions".
Figure 1-1 illustrates the components of a working Oracle9iAS Reports Services environment. This includes:
Oracle9iAS provides a Web server called the Oracle9iAS HTTP Server. It incorporates an OpenSSL module to provide support for Secure Sockets Layer (SSL) and HTTP Secure Sockets Layer (HTTPS). It also provides a servlet engine to support the running of Java Servlet applications.
Here is how the various components of Oracle9iAS Reports Services contribute to the process of running a report:
The URL may contain runtime parameters or a keyword that refers to a runtime parameter configuration section within cgicmd.dat, or it may contain both, though parameters explicitly named in the URL must not also be present in the relevant keyword section of cgicmd.dat.
The command line may contain runtime parameters. If you have a lot of runtime parameters, you can create a batch file or shell script that contains the
rwclient command along with a string of parameters.
\reports\conf\). An in-process server requires less maintenance than a stand-alone server because, unlike the stand-alone server, it starts automatically in response to requests from the client. Additionally, an in-process server cuts down on the communication between processes, increasing the potential for faster performance.
If the request includes a TOLERANCE argument, then the Reports Server checks its cache to determine whether it already has output that satisfies the request. If it finds acceptable output in its cache, then it immediately returns that output rather than rerunning the report.
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 five minutes as the tolerance, the Reports Server would check its cache for the last duplicate report output that had been generated within the last five minutes. An expiration argument defines the point in time when the report output should be deleted from the cache (for example, expiration might equal a specific date and time for when the output should expire). For more information, see Appendix A, "Command Line Arguments".
If the request is the same as a currently running job, then the request will reuse the output from the current job rather than rerunning the report.
If neither of these conditions is met, the Reports Server processes the request:
When you configure the Reports Server (in < server_name>.conf), you can specify the maximum number of Oracle9iAS Reports Engines it can use. If the Oracle9iAS Reports Server is under this maximum, then it can send the job to an idle engine or start a new engine to handle the request. Otherwise, the request must wait until one of the current Oracle9iAS Reports Engines completes its current job.
Another way to create a report is through event-driven publishing. With event-driven publishing, the client is the database (rather than the end user). Events are defined through the Event-Driven Publishing API. The event invokes a database trigger, an advanced queuing application, or a PL/SQL package that calls the Event-Driven Publishing API to submit jobs to the Reports Server. Event-Driven Publishing is discussed in detail in Chapter 11, "Event-Driven Publishing".
The way you set up Oracle9iAS Reports Services can vary widely depending upon the requirements of your system. Before you set up Oracle9iAS Reports Services, you must make some decisions based upon your requirements. By making these decisions beforehand, you can greatly simplify the set-up process.
The following subsections discuss some of the decisions involved in:
Oracle9iAS Reports Services can be configured to accept both Web and non-Web job requests.
In the Web case, you can run reports by clicking or typing a URL in a Web browser. Depending on the URL, the report output is then served back to you in your browser or sent to a specified destination (for example, a printer). To enable users to launch reports from a browser, you will use either the Oracle9iAS Reports Servlet, a JSP, or Oracle9iAS Reports CGI components with your Web server. One or the other of these components must be present on the Web server to enable communications between it and the Oracle9iAS Reports Server and to enable the processing of report requests from Web clients.
For more information, refer to the Section 1.4.2, "Choosing Servlet, JSP, or CGI".
In the non-Web case, you can send job requests using the rwclient executable, installed on each of your user's machines.
From the perspective of configuration, these are the key differences between enabling Web and non-Web requests:
The Web case is clearly the most cost effective because it reduces client maintenance costs. But there might be cases where launching non-Web requests is a necessity. Oracle9iAS Reports Services supports the implementation of both Web and non-Web requests in a single deployment environment.
To use Oracle9iAS Reports Services in a Web environment, you must use a servlet, JSP, or CGI implementation. Our recommendation is that you choose servlet or JSP. The CGI implementation in Oracle9iAS Reports Services is being maintained only for backward compatibility.
Between servlet and JSP there are additional considerations. A JSP-only implementation means that you can publish a layout that is optimized for Web delivery. The servlet enables you to include paper layouts in your report publishing solution and fully leverage the distribution features of Oracle9iAS Reports Services.
Using the servlet does not imply that you cannot also use JSP files because JSP files can contain both Web and paper layouts. When you run a report stored in a JSP, you specify the servlet in the URL and call the JSP with the command line argument:
For more information on running reports, see Chapter 8, "Running Report Requests".
You can place Oracle9iAS Reports Services on the same machine as your Web server or on a different machine. Both scenarios have pros and cons.
For example, while it's true that having Oracle9iAS Reports Services and the Web server on the same machine requires more of the machine's memory and disk space, it's also true that such an implementation reduces network traffic. This is because requests traveling between the Web server and the application server do not have to travel across a network, only incoming requests must do so.
If you are using the in-process server (available only with servlet implementations) you can further amplify the performance advantages of a single machine. The in-process server speeds up processing time by allowing for faster and more efficient communication between Oracle9iAS Reports Services components. We recommend that you use the in-process server unless you will not use the Reports Servlet to deploy reports.
On the other hand, if you have a single machine configuration and that machine fails, everything fails.
While there is a greater amount of network traffic when the Web server and the application server are on different machines, you also benefit from the increase in system resources, in the form of additional CPUs, more disk space, and more available memory. Even in a multiple machine configuration, the in-process server will aid performance by speeding communication between Oracle9iAS Reports Services components
Another possibility is placing your Web server and your application server each on multiple machines. This will require additional configuration, but it allows you to implement load balancing on the Web server.
If you will be deploying reports in multiple languages, you'll want to set up multiple Reports Servers: one or more for each language.
A cluster is a virtual grouping of servers into a community for the purpose of sharing request processing efficiently across members of the cluster. Unlike in previous versions, clustering in Oracle9iAS Reports Services is peer-level, rather than master/slave. Peer-level clustering means that all members of the cluster take equal responsibility for sharing and processing incoming requests. Incoming requests are sent to the cluster as a whole rather than any one Reports Server in the cluster. Thus, if one member is shut down, the other members carry on managing the request load. There is no single-point-of-failure, where one machine's malfunction brings the whole system down.
Each cluster member machine must be configured in more or less the same way to allow a report to run on each server member in the same way. This means that configuration files should have most of the same settings: a distinction can be drawn between job-related settings and machine-related settings. Job-related settings must be the same from cluster member to cluster member. Job-related settings include settings related to security, data sources, and destination types. Machine-related settings include such attributes as maxEngine, minEngine, maxIdle, initEngine, and the like--these can be different from member to member.
Additionally, for cluster members:
For servers to be members of the same cluster, they must share a cluster name (appended to each server's server name) and have the same public and private keys.
If your machines require different job-related configuration settings, you will not benefit from clustering.
If you must set your servers up for different languages, you'll want to set up multiple clusters: one or more for each language.