The tight product integration between Oracle Reports and Oracle Forms Services enables you to pass blocks of data between the two products and removes the need for subsequent queries. This technique, referred to as query partitioning, ensures that Oracle Reports is responsible for formatting data and ignores dynamic alteration of queries through triggers and lexical parameters.
Oracle Forms Services uses the shared Java Virtual Machine (JVM) controller for all report requests, reducing memory consumption.
Note:Unless data parameters are unreasonably large or the queries particularly complicated, the perceived performance improvements should be negligible. Additionally, only top level groups in a report can accept data parameters passed from forms.
A typical integration between Oracle Forms Services and Oracle Reports is an application that provides a form to fill in data, which is used to generate a report. The steps that occur during this process are similar to the following example:
The end user enters values in a form. Some or all of these values are parameter inputs to the associated report.
The end user clicks a button, which generates the report as follows:
Oracle Forms Services populates all the parameters to execute the report.
Oracle Forms Services calls the
RUN_REPORT_OBJECT built-in to send a request to Oracle Reports.
Oracle Reports returns the job id, and Oracle Forms Services queries on the status of this job id.
When the job status is
FINISHED, Oracle Forms Services calls the
WEB.SHOW_DOCUMENT built-in to submit a request to open the report output.
WEB.SHOW_DOCUMENT built-in opens the following URL in the browser:
Note:For secure mode, the URL will also include
For additional information on calling a report from an Oracle Forms Services application, refer to the Integrating Oracle Reports Services 11g in Oracle Forms Services 11g white paper on OTN (
Oracle Reports 11g Release 1 (11.1.1) communicates with Forms. If Forms and Reports are configured on different Oracle Instances, you must complete the following steps in Forms to facilitate communication with Reports Servers.
FORMS_ORACLE_INSTANCE refers to the Oracle Instance where Forms is configured.
From your present working directory, run the following command:
ReportsTools directory as follows:
mkdir -p ReportsToolsComponent/ReportsTools
tools-logging.xml file as follows:
cp $ORACLE_HOME/reports/conf/ReportsTools/tools-logging.xml $FORMS_ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/logging.xml
tools-log-template.xml file as follows:
cp $ORACLE_HOME/reports/conf/ReportsTools/tools-log-template.xml $FORMS_ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/component-logs.xml
rwnetwork.conf file as follows:
cp $ORACLE_HOME/reports/conf/rwnetwork.conf $FORMS_ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/rwnetwork.conf
Replace the following macros in the copied files:
$$Instance.oracle_home$$ with the path to the ORACLE_HOME directory
If Forms and Reports are configured on different OHS Servers, you must route the web requests from OHS instance where Forms is configured to the Reports Servlet as follows:
Copy the reports_ohs.conf file as follows:
cp $ORACLE_HOME/reports/conf/reports_ohs.conf $FORMS_ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/.
Replace the macros
$$managaerserverport$$ with host and port of the
WLS_REPORTS managed server.
Restart the OHS that is running in
With 11g Release 1 (11.1.1), Oracle Reports allows you to generate random and non-sequential job IDs to make it impossible to predict the job ID for a particular job. To generate random and non-sequential job IDs for in-process servers, you must pass
"-Djobid=random" via JVM options to Oracle WebLogic Server.
For standalone servers, you can generate random and non-sequential job IDs by passing the
"-Djobid=random" via JVM options in the command line or by setting the
REPORTS_JVM_OPTIONS variable. For more information, see Section B.1.53, "REPORTS_JVM_OPTIONS".
This prevents malicious users from viewing non-secure report output by typing the job id in a URL.