Oracle Reports 11g Services Runtime Process

Oracle Reports Services Runtime Process

The various components of Oracle Reports Services contribute to the process of running a report as follows:

1. 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 or rwservlet, both associated with the Oracle HTTP Server. The requests go to mod_weblogic. (For jobs that run as JSPs,mod_weblogic uses OJSP to translate the JSP into a servlet.)
     The URL may contain runtime parameters or a keyword that refers to a runtime parameter configuration section within the cgicmd.dat key map file file (for more information, see Section 18.13, "Using a Key Map File"), 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 therwclient command along with a string of parameters.
2. The rwservlet component translates and delivers information between either a Web server or a Java EE Container (for example, Oracle WebLogic Server) and the Reports Server:
   Server requests from Reports JSP or rwservlet can be run by the in-process Reports Server or as a standalone Reports Server process (recommended), whichever is specified in the Oracle Reports Servlet (rwservlet) configuration file (DOMAIN_HOME/config/fmwconfig/servers/<WLS_SERVER_NAME>/applications/reports_<version>/configuration//rwservlet.properties). An in-process Reports 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 Reports 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 WebLogic Server instance. For information about specifying an in-process Reports Server and default naming, see Section 8.3, "Oracle Reports Servlet Configuration File".
3. 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 a TOLERANCE 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. AnEXPIRATION option defines the point in time when the report output should be deleted from the cache (for example, EXPIRATIONmight equal a specific date and time for when the output should expire). For more information, see Section A.8.22, "TOLERANCE"and Section A.6.6, "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:
   
   1. If Oracle Reports Servlet (rwservlet) is SSO-enabled, it checks for authentication. A secure Reports Server then authorizes the user using Oracle Internet Directory. If Oracle Reports Servlet (rwservlet) is not SSO-enabled, a secure Reports Server authorizes and authenticates the user.
   2. 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.
      
      Note:

      When you configure the Reports Server (in rwserver.conf), you can specify the maximum number of the Report Engines it can use. If the 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 Oracle Reports Engines completes its current job.
   3. At runtime, the Reports Server spawns a Reports Engine and sends the request to that engine to be run.
4. The Reports Engine retrieves and formats the data.
5. The Reports Engine populates the Reports Server cache.
6. The Reports Engine notifies the Reports Server that the report is ready.
7. 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 21, "Using Event-Driven Publishing".

For information about running reports with Oracle BPEL Process Manager, refer to Section 8.10, "Configuring Oracle Reports to Communicate with Oracle BPEL Process Manager".