|
Oracle® Application Server Reports Services Publishing Reports to the Web
10g Release 2 (10.1.2) B14048-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Reports Services Publishing Reports to the Web
10g Release 2 (10.1.2) B14048-02 |
|
|
Previous |
Next |
This chapter describes the architecture of relevant Oracle Reports components in combination with its reports publishing component, OracleAS Reports Services. It also provides an overview of Reports Runtime processing and outlines considerations when setting up your Reports Server environment.
This chapter includes the following sections:
OracleAS Reports Services is the reports publishing component of Oracle Application Server. 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 OracleAS Reports Services to publish in both Web-based and non-Web-based environments.
OracleAS 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 output for reuse on similar requests. It integrates into standard Web environments with JSPs, Java servlets, Web Services, and CGI (maintained for backward compatibility). It enables you to run reports on both local and remote application servers and to implement a multitiered architecture for running your reports.
When used in conjunction with JSPs, Java servlets, Web Services, or CGI (maintained for backward compatibility), OracleAS 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 shortens response times.
OracleAS 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 OracleAS Reports Services").
OracleAS Reports Services keeps track of all jobs submitted to the server, including jobs that are running, scheduled to run, finished, or failed. The showjobs command (Web through rwservlet), the Web Services interface, the OracleAS Reports Services pages in Oracle Enterprise Manager 10g, the Reports Queue Manager (Windows), and the Reports Queue Viewer (UNIX) 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 OracleAS Reports Services, job information is persistent. This means that if the Reports Server is shut down then restarted, all jobs are recovered,Foot 1 not just scheduled jobs.
When used in a Web environment, the OracleAS Reports Services architecture consists of four tiers:
|
Note: The term tier refers to the logical location of the components that comprise the OracleAS Reports Services architecture. Each of the tiers, though, can reside on the same machine or on different machines. |
The client tier (a Web browser)
The Web server tier
The OracleAS Reports Services tier
The data tier, including databases and all other data sources
When used in a non-Web environment, there are three tiers (a Web server being unnecessary):
The client tier (a small, proprietary application on each client machine)
OracleAS Reports Services tier
The data tier, including databases and pluggable data sources
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. Refer to the Oracle Application Server Installation Guide for more information on sample topologies.
If you choose to have your Web server on multiple machines, you can cluster and load balance multiple Oracle Application Server instances for a highly available, fail-safe environment. Refer to the Oracle Application Server Installation Guide for information on load balancing. Refer to the Oracle Application Server Enterprise Deployment Guide and Oracle Application Server High Availability Guide for information on enterprise deployment architectures and high availability.
OracleAS 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 17, "Using Event-Driven Publishing".
OracleAS 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 15, "Creating Advanced Distributions".
Figure 1-1 OracleAS Reports Services Components
Figure 1-1 illustrates the components of a working OracleAS Reports Services environment. This includes:
The Oracle HTTP Server, a Web server provided by Oracle Application 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.
The module mod_oc4j, used by the Oracle HTTP Server to redirect requests from servlets and JSPs to Oracle Application Server Containers for J2EE (OC4J). OC4J provides a complete J2EE environment that includes a JSP translator, a JSP servlet engine (OJSP), and an Enterprise JavaBeans (EJB) container. It provides a fast, lightweight, highly scalable, easy-to-use, complete J2EE environment. It is written entirely in Java and executes on the standard Java Development Kit (JDK) Virtual Machine (JVM).
The Reports Servlet (rwservlet), a component of OracleAS Reports Services that runs inside the Web server's servlet engine. The Reports Servlet translates and delivers information between HTTP and Reports Server. It includes:
The Custom Tag Handler, which processes custom Oracle Reports tags included in a JSP file. In a JSP file, Oracle Reports-related custom tags are identified by the prefix rw:; other custom tags using other prefixes may also be present.
The Reports CGI (rwcgi), a component of the Web server that translates and delivers information between either a Web server and the Reports Server, enabling you to run a report dynamically from your Web browser.
|
Note: With Oracle Reports 10g, the Reports CGI (rwcgi) is deprecated (maintained only for backward compatibility); instead, use Reports JSPs, rwservlet (Reports Servlet), or Reports Web Services.
|
The Reports Server (rwserver), which processes client requests, including ushering them through its various services, such as authentication and authorization checking, scheduling, caching, and distribution (including distribution to custom—or pluggable—output destinations). The Reports Server also spawns runtime engines for generating requested reports, fetches completed reports from the Reports Server cache, and notifies the client that the job is ready.
The Reports Server Cache, which securely stores completed job outputs.
The Reports Engine, which includes components for running SQL-based and pluggable data source-based reports. It fetches requested data from the data source, formats the report, sends the output to cache, and notifies the Reports Server that the job is complete.
The pluggable engines, which are custom engines that use Java APIs to pass jobs to the Reports Server, as well as leverage the server's other features, such as scheduling, distribution, notification, and caching. OracleAS Reports Services provides an out-of-the-box pluggable engine called the URL engine. The URL engine enables you to distribute content from any publicly available URL to destinations such as e-mail, OracleAS Portal, and WebDAV.
Additionally, the Oracle Reports bridge provides functionality for discovering a Reports Server across subnets. The Oracle Reports bridge acts as a gateway for packets that are broadcast by Reports Server/Reports Client across subnets. The bridge mechanism is not shown in Figure 1-1; for more information, see Section 1.4.1.2, "Server Discovery Across Subnets".
The various components of OracleAS Reports Services contribute to the process of running a report as follows:
The client requests a report by contacting a server through either a URL (Web) or a non-Web, Oracle Reports-related command, such as rwclient.
The URL goes to JSP, rwservlet, or rwcgi, all associated with the Oracle HTTP Server. The JSP and rwservlet requests go to mod_oc4j. (For jobs that run as JSPs, mod_oc4j uses OJSP to translate the JSP into a servlet.) The rwcgi requests go to a CGI component.
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.
rwclient goes directly to the Reports Server.
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.
The rwservlet (or rwcgi, maintained only for backward compatibility) component translates and delivers information between either a Web server or a J2EE Container (for example, OC4J) and the Reports Server:
Server requests from Reports JSP or rwservlet can be run by the in-process server or as a standalone Reports Server process (recommended), whichever is specified in the servlet configuration file (ORACLE_HOME\reports\conf\rwservlet.properties). An in-process server requires less maintenance than a standalone Reports Server because, unlike the standalone Reports Server, it starts automatically in response to requests from the client. An in-process server cuts down on the communication between processes. A standalone server, on other hand, provides better control outside the rwservlet process with the ability to separate out server process from the OC4J instance. For information about specifying an in-process server and default naming, see Section 3.4.10, "Specifying an In-process Server" and Section 3.4.11, "Identifying the In-process Server".
Server requests using rwcgi go to the standalone server.
The Reports Server processes the request:
If the request includes a TOLERANCE option, 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.
|
Note: For any job request that you send to the Reports Server, you can include aTOLERANCE option. 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 option 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 Section A.3.113, "TOLERANCE" and Section A.3.35, "EXPIRATION".
|
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, then:
If Reports Servlet is SSO-enabled, it checks for authentication. A secure Reports Server then authorizes the user using Oracle Internet Directory. If Reports Servlet is not SSO-enabled, a secure Reports Server authorizes and authenticates the user.
If the report is scheduled, the Reports Server stores the request in the scheduled job queue, and the report is run according to schedule. If the report is not scheduled, it is queued in the current job queue for execution when a Reports Engine becomes available.
At runtime, the Reports Server spawns a Reports Engine and sends the request to that engine to be run.
The Reports Engine retrieves and formats the data.
The Reports Engine populates the Reports Server cache.
The Reports Engine notifies the Reports Server that the report is ready.
The Reports Server accesses the cache and sends the report to output according to the runtime parameters specified in either the URL, the command line, or the keyword section in the cgicmd.dat file (URL requests only).
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 17, "Using Event-Driven Publishing".
For information about running reports from Oracle Workflow, refer to Section 3.8, "Configuring Oracle Reports to Communicate with Oracle Workflow", which points to the Integrating Oracle Workflow with Oracle Reports white paper on OTN (http://www.oracle.com/technology/products/reports/features/workflow) for complete information.
Oracle9i Reports and Oracle Reports 10g Release 1 (9.0.4) use Borland VisiBroker's osagent executable to dynamically discover Reports Servers in the network.
Oracle Reports 10g Release 2 (10.1.2) replaces the use of Borland's VisiBroker with Sun Microsystems' industry-standard Java Developer's Kit Object Request Broker (JDK ORB), providing support for Reports Server requests from clients across subnets, and using the broadcast mechanism for dynamic Reports Server discovery both within a subnet and across subnets.With Oracle Reports 10g Release 2 (10.1.2), you can use the built-in broadcast mechanism, available out-of-the-box, for dynamic discovery of Reports Servers. You can also choose to use the Common Object Service (COS) naming service orbd, provided by Sun Microsystem's JDK ORB, for Reports Server discovery.
This section discusses the two methods of Reports Server discovery:
|
Note: Oracle Reports 10g Release 2 (10.1.2) also introduces therwdiag executable to provide diagnosis for the JDK ORB implementation. Using rwdiag, you can replace the functionality of osfind available in the prior VisiBroker implementation, providing information about which ORB applications are running and options for logging ORB-related network traffic. For more information on rwdiag, see Appendix E, "Reports Server and Bridge Diagnostic Utility".
|
With the broadcast mechanism, Reports Server discovery can occur within a subnet or across subnets:
|
Note: The Oracle Reports built-in broadcast mechanism requires the host machine to be inside a network. Thus, following are two scenarios in which the broadcast mechanism may not work, including the solutions for each scenario:
|
Within a subnet, the client broadcasts a packet with the name of the Reports Server to which it wants to connect. A Reports Server with that name will respond if it exists in the network. The client then connects to the Reports Server to run the report request.
Figure 1-2 Server Discovery within a Subnet
Using the example of running a report request with server=rep_server, the following numbered steps map to the numbers in Figure 1-2:
getServerRef
The Oracle Reports client (for example, rwclient, rwservlet, or rwrqm) broadcasts a packet containing the name of the server to which it wants to connect. In this case, the packet contains the name rep_server.
The server with name rep_server in the network responds back with its Interoperable Object Reference (IOR).
The client converts the IOR to an object reference.
runReport
The Oracle Reports client sends a request to the remote object reference to run the report (IIOP call).
executeReport
Reports Server executes the report and returns either report or status.
Oracle Reports provides the bridge mechanism for connecting two or more non-secured subnets. An Oracle Reports bridge running in one subnet will contact the Oracle Reports bridge running in another subnet to obtain Reports Server references. For configuration details, refer to Section 3.3.2, "Bridge Configuration Elements (bridgeconf.dtd)".
For troubleshooting scenarios and diagnosis, see Section D.8, "Diagnosing Oracle Reports Bridge Problems".
Figure 1-3 Server Discovery Across Subnets
Using the example of running a report request with server=rep_server, the following numbered steps map to the numbers in Figure 1-3:
getServerRef
The Oracle Reports client (for example, rwclient, rwservlet, or rwrqm) broadcasts a packet containing the name of the server to which it wants to connect. In this case, the packet contains the name rep_server.
bridge1 intercepts the packet and passes it to bridge2.
registerServerRef
bridge2 broadcasts the packet in dom2, and rep_server in dom2 responds back with the Interoperable Object Reference (IOR).
bridge2 passes the IOR back to bridge1, and bridge1 passes it to the client using the broadcast mechanism.
The Oracle Reports client converts the IOR to an object reference.
runReport
The Oracle Reports client sends a request to the remote object reference to run the report (IIOP call).
executeReport
Reports Server executes the report and returns either report or status.
|
Note: Numbers in blue color in Figure 1-3 are shown for the case where the Oracle Reports client is indom2 and Reports Server is in dom1.
|
Alternatively, you can use the JDK-provided Common Object Service (COS) naming service to access a Reports Server in the same subnet, as well as across a non-secured subnet. To configure the naming service, refer to Section 3.3.1, "Network Configuration Elements (rwnetworkconf.dtd)".
|
Note: It is recommended that you use the built-in broadcast mechanism for dynamic discovery of Reports Servers. Use the Common Object Service (COS) naming service for Reports Server discovery only when the built-in broadcast mechanism is not suitable for your environment, as in the following scenarios:
|
To control the COS naming service through OPMN, refer to Section 3.7.1.5, "COS Naming Service Specification".
Figure 1-4 Server Discovery Using the COS Naming Service
Using the example of running a report request with server=rep_server, the following numbered steps map to the numbers in Figure 1-4:
registerServer
When rep_server is started, it registers itself with the naming service, which must be up and running for the server to start. Now a request is run with server=rep_server.
getServerRef
The Oracle Reports client contacts the naming service and requests a reference to server rep_server.
The naming service returns the reference to server rep_server.
runReport
The Oracle Reports client sends a request to the remote object reference to run the report (IIOP call).
executeReport
Reports Server executes the report and returns either report or status.
|
Note: Numbers in blue color in Figure 1-4 are shown for the case where the Oracle Reports client is indom2 and Reports Server is in dom1.
|
The way you set up OracleAS Reports Services can vary widely depending upon the requirements of your system. Before you set up OracleAS Reports Services, you must make some decisions based upon your requirements. By making these decisions beforehand, you can greatly simplify the setup process.
The following subsections discuss some of the decisions involved in:
OracleAS 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 Reports Servlet, a JSP, or 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 OracleAS Reports Services and to enable the processing of report requests from Web clients.
|
Note: For more information, refer to Section 1.5.2, "Choosing Reports Servlet, JSP, Web Services, or CGI". |
In non-Web cases, 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:
Enabling Web requests requires that you choose between Reports Servlet, JSP, or Reports CGI (maintained only for backward compatibility) for the server side, but eliminates the need to install any client software beyond a standard Web browser.
|
Note: With Oracle Reports 10g, the Reports CGI (rwcgi) is deprecated (maintained only for backward compatibility); instead, use Reports JSPs, rwservlet (Reports Servlet), or Reports Web Services.
|
Enabling non-Web requests requires that you install client software on each machine that will be used to run requests. This introduces the need to administer client software on each client machine.
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. OracleAS Reports Services supports the implementation of both Web and non-Web requests in a single deployment environment.
To use OracleAS Reports Services in a Web environment, you must use a servlet, JSP, or CGI implementation. We strongly recommend that you choose rwservlet (Reports Servlet), Reports Web Services, or Reports JSP. The reason is that Reports CGI internally starts a new process for each request. Each process initializes a JVM, which results in a slow performance when running a large number of report requests. Whereas, Reports Servlet is deployed on an OC4J instance and leverages the servlet functionalities, thereby providing higher performance than Reports CGI.
Between Reports Servlet and Reports JSP there are additional considerations. A JSP-only implementation means that you can publish a layout that is optimized for Web delivery (that is, the Oracle Reports Web Layout). The servlet enables you to include paper layouts in your report publishing solution and fully leverage the distribution features of OracleAS Reports Services.
Using Reports 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 option report=myreport.jsp. In this case, report output is created based on the paper layout.
For more information on running reports, see Chapter 13, "Running Report Requests".
You can place OracleAS 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 OracleAS 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 Reports 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 OracleAS Reports Services components. We recommend that you use the in-process server unless you will not use 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 OracleAS 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 enables you to implement load balancing on the Web server.
By using the environment switching feature it is possible to spawn Reports Engines with different environment settings, including language, in the same Reports Server. Refer to Section 3.2.2, "Dynamic Environment Switching" for more information.
This section discusses the following aspects in choosing a high availability environment:
Oracle Application Server consists of many components that can be deployed in distributed topologies. The underlying paradigm used to enable high availability for Oracle Application Server is clustering, which unites various Oracle Application Server components in certain permutations to offer scalable and unified functionality, and redundancy should any of the individual components fail.
|
Note: Refer to the Oracle Application Server Enterprise Deployment Guide and Oracle Application Server High Availability Guide for more information on the various solutions and techniques to achieve high availability in Oracle Application Server. |
Before you continue, we recommend that you read the book Oracle Application Server Concepts to gain an understanding of the different components in Oracle Application Server. Implementing the solutions and techniques for high availability enables you to achieve the following goals:
Redundancy
A highly available system requires its sub-systems to be redundant. All Oracle Application Server components can be deployed redundantly using the procedures and solutions described in the Oracle Application Server High Availability Guide. Depending on the type of components, they can be deployed in an active-active configuration or active-passive configuration.
In an active-active configuration, multiple instances of a component service client requests at the same time. If one instance fails, the requests being serviced by that instance can be fulfilled by other active instances; the failure and failover of that instance is transparent to clients. An active-active configuration can usually be achieved by clustering instances of components together.
In an active-passive configuration, requests are usually serviced by one instance of a component. Upon failure of that component, another instance is made active to respond to the request workload.
Death Detection and Auto Restart
Software processes belonging to Oracle Application Server components, local or distributed, are managed by a central process management system. This system is able to detect the death of processes and restart them even if they are distributed over multiple machines. The system allows customization of parameter values that define process death and restart (such as number of heartbeats). The processes implementing the process management system are themselves redundant as each has a shadow process.
Clustering
Clustering components of a system together allows the components to be viewed functionally as a single entity from the perspective of a client. A cluster increases the scalability, availability, and manageability of the components.
Several types of clusters can exist with Oracle Application Server components. Procedures to create and configure these clusters are comprehensively documented in the Oracle Application Server High Availability Guide. The Oracle Application Server Enterprise Deployment Guide also contains information about setting up a clustered environment.
State Replication and Routing
For stateful client requests, Oracle Application Server can replicate client state in order to enable stateful failover of requests in the event that processes servicing these requests fail. For J2EE requests, replicating client state for J2EE applications can be done declaratively or programmatically, depending on the mechanism being used. For most other components, state-based routing using cookies is available.
Connection Failure Management
Clients often connect to services on the server and reuse these connections. When a process implementing one of these services on the server is restarted, the connection may need to be reestablished.
Oracle Application Server components ensure that if a reused connection fails, the connection is retried before a failure condition is propagated to the rest of the system. This allows clients to be transparent to any failures.
Backup and Recovery
Oracle Application Server provides facilities for backing up system state and using this backup to recover from failures. In certain circumstances, a component or system failure may not be repairable. The Oracle Application Server Backup and Recovery Tool can be used to back up the system at certain intervals and restore a backup when an unrepairable failure occurs.
For specific problems localized to the HTTP listener and J2EE container, a runtime configuration management system allows these components to be check pointed quickly and also allows for undo operations for configuration errors.
Disaster Recovery
Natural and physical disasters can happen to areas where an Oracle Application Server site hosting critical applications is physically located. A solution for recovering from such disasters is documented in the Oracle Application Server High Availability Guide. This solution is a site-to-site recovery solution that allows the backing up of the state of an entire Oracle Application Server site and recovering it to another site that is physically distant from the first.
Oracle Application Server provides a number of high availability features to keep its middle tier running even when particular servers or components fail. We strongly recommend that you use the Oracle Application Server high availability.
|
Note: Refer to the Oracle Application Server High Availability Guide for more information on the high availability features in Oracle Application Server. |
To take advantage of the Oracle Application Server high availability features, OracleAS Reports Services takes the following actions when its infrastructure dependencies fail:
Retrying the OracleAS Portal database connection. If the connection from the Reports Server to the OracleAS Portal database schema is dropped for some reason, then the Reports Server tries to reestablish the connection before generating an error. First, it retrieves the OracleAS Portal connection string from the repository. With the OracleAS Portal connection string, the Reports Server can attempt to reconnect. If a reconnection is successful, you need not restart the Reports Server. OracleAS Reports Services also supports cold failover and RAC on the infrastructure and disaster recovery on the middle tier.
Retrying the Oracle Internet Directory connection. If the Oracle Internet Directory connection becomes stale for some reason, the Reports Servlet and the Reports Server try to reestablish the connection before generating errors. If a reconnection is successful, you need not restart the Reports Server.
Footnote Legend
Footnote 1: Only synchronous jobs and jobs that are currently running are lost in this case.