This chapter covers tasks you shoudl complete after upgrading to Oracle Forms and Reports 11g Release 2 (11.1.2).
This task involves completing the following component-specific upgrade steps:
Post-Upgrade Tasks Required When Using Single Sign-On Software
Post-Upgrade Tasks and Information for the Web Tier Components
Review the following list of manual tasks that you might have to perform after upgrading to Oracle Forms and Reports 11g Release 2 (11.1.2):
Post-Upgrade Steps After Upgrading from Oracle Forms Services 10g
Post-Upgrade Steps After Upgrading from 11g Release 1 (11.1.1)
Note:
For information on upgrading from Oracle Forms Release 6i , refer to "Upgrading to Oracle Forms Services" in the Oracle Fusion Middleware Forms Services Deployment Guide.
Review the following list of post-upgrade tasks you might have to perform after using the Upgrade Assistant to upgrade Oracle Forms Services 10g Release 2 (10.1.2) to Oracle Forms and Reports 11g Release 2 (11.1.2):
Regenerate the Forms application files: fmx's, mmx's, and plx's to run on Oracle Forms Services 11g.
If you deployed the Oracle Forms Services J2EE applications EAR file (formsapp.ear) on multiple OC4J instances for load balancing and high availability purposes, then you deploy them in a similar manner on Oracle WebLogic Server.
Specifically, you can create additional managed servers and deploy the Oracle Forms Services J2EE application ear file on each server.
The ear file is stored in the following location in Oracle Fusion Middleware 11g:
ORACLE_HOME/forms/j2ee/formsapp.ear
For more information, see "Expanding Forms Managed Server Clusters" in the Oracle Fusion Middleware Forms Services Deployment Guide.
If you deployed the Oracle Forms Services J2EE custom application ear file (formsapp.ear) file to override the context root or Forms servlet alias, then you should perform similar steps in the 11g Oracle WebLogic Server domain.
For more information, see "Custom Deployment of Forms Java EE Application" in the Oracle Fusion Middleware Forms Services Deployment Guide.
Manually copy any customizations to the shell scripts in the source Oracle home to the equivalent shell scripts that reside Oracle Fusion Middleware 11g Oracle instance directory.
The Upgrade Assistant copies the FMA utility configuration files (converter.properties and search_replace.properties) to the Oracle Fusion Middleware 11g destination Oracle instance and renames them so they have a .10.1.2 suffix.
You can then manually copy the required entries from the .10.1.2 configuration files into the Oracle Fusion Middleware 11g version of these files as needed.
Review the following list of manual tasks that you might have to perform after using the Upgrade Scripts to upgrade Oracle Forms Services in Oracle Fusion Middleware 11g Release 1 (11.1.1) to Oracle Fusion Middleware 11g Release 2 (11.1.2):
If you deployed the Oracle Forms Services J2EE applications EAR file (formsapp.ear) on multiple managed servers for load balancing and high availability purposes, then be sure to redeploy it in a similar manner after you upgrade from Oracle Fusion Middleware 11g Release 1 (11.1.1).
The ear file is stored in the following location in Oracle Fusion Middleware 11g:
ORACLE_INSTANCE/config/Formscomponent/forms/provision/formsapp.ear
For more information, see "Expanding Forms Managed Server Clusters" in the Oracle Fusion Middleware Forms Services Deployment Guide.
If you deployed the Oracle Forms Services J2EE custom application ear file (formsapp.ear) file to override the context root or Forms servlet alias, then you should perform similar steps in the 11g Oracle WebLogic Server domain.
For more information, see "Custom Deployment of Forms Java EE Application" in the Oracle Fusion Middleware Forms Services Deployment Guide.
If you made any customizations to the Forms Oracle HTTP Server configuration file, forms.conf, in the source instance, then you must manually add those customizations to the equivalent file in the destination instance.
In Oracle Forms and Reports 11g Release 2 (11.1.2), the configuration file is installed in the following location:
ORACLE_INSTANCE/config/OHS/ohs1/modulesconf/forms.conf
Note that you must restart the Oracle HTTP Server instance after you modify the forms.conf file.
When you upgrade from Oracle Fusion Middleware 11g Release 1 (11.1.1), you can choose to modify your new 11g Release 2 (11.1.2) installation to use the same ports as your 11g Release 1 (11.1.1) installation.
Alternatively, you can continue use the ports defined during the 11g Release 2 (11.1.2) installation.
In the latter case, you can run both the 11g Release 1 (11.1.1) environment and the newly upgraded 11g Release 2 (11.1.2) instance at the same time with no port conflicts.
However, in some cases, after upgrading to Oracle Forms and Reports 11g Release 2 (11.1.2), you might experience port conflicts when attempting to start the Oracle HTTP Server in both the 11g Release 1 (11.1.1) and 11g Release 2 (11.1.2) instances. This is because not all the paths in the Oracle HTTP Server configuration files were upgraded successfully.
This issue occurs if the paths to the admin.conf and ssl.conf files in the httpd.conf file are hard-coded, rather than defined using system variables. As a result, they continue to reference the configuration files in the 11g Release 1 (11.1.1) source Oracle instance, rather than the files in the 11g Release 2 (11.1.2) destination Oracle instance.
To work around this issue, perform the following task in the destination Oracle instance:
Locate the httpd.conf file for the destination Oracle HTTP Server.
The file is located in the following location in the destination Oracle instance:
(WINDOWS> DEST_ORACLE_INSTANCE\config\OHS\ohs1\httpd.conf
Edit the httpd.conf file with a text editor and replace all source paths with destination paths for all the directives in httpd.conf file.
For example, replace the following path:
"ServerRoot "<Source Oracle Instance>/config/OHS/ohs1"
with
"ServerRoot "<Destination Oracle Instance>/config/OHS/ohs1"
Save and close the httpd.conf file.
Edit the ssl.conf file located at <Destination Oracle Instance>/config/OHS/ohs1/ssl.conf by replacing the forward slash with the backward slash as shown in the following example:
Before workaround:
</Directory> BrowserMatch ".*MSIE.*" / nokeepalive ssl-unclean-shutdown / downgrade-1.0 force-response-1.0 </IfModule>
After workaround:
</Directory> BrowserMatch ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </IfModule> </VirtualHost>
Save and close the ssl.conf file.
Restart the Oracle HTTP Server instance.
After you upgrade from Oracle Reports 10g to Oracle Reports 11g, review the following sections, which provide information about typical post-upgrade tasks for OracleAS Reports Services users:
When you upgrade to Oracle Reports 11g, the security configuration is not upgraded. As a result, the security configuration of Oracle Reports 11g remains the same as it was before the upgrade.
For information about the security features available in Oracle Reports 11g and how to configure them, see "Securing Oracle Reports Services" in the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.
The following sections describe some other common post-upgrade tasks to complete after upgrading to OracleAS Reports Services 11g:
Any shell scripts that are stored in the bin directory of the Oracle Reports 10g Oracle home, such as reports.sh, rwrun.sh, and rwserver.sh are not upgraded automatically during the upgrade process. Instead, you must change these scripts manually, as needed. After the upgrade, you can find these scripts in the following Oracle Fusion Middleware 11g directory:
ORACLE_INSTANCE/config/reports/bin
OracleAS Reports Services DAT files are upgraded during the upgrade process. However, if job command entries in the DAT files contain references to old Oracle Home path names or invalid path names, then those jobs will fail. Therefore, you must reschedule any such report jobs.
In OracleAS Reports Services 10g, the in-process server target appears in Oracle Enterprise Manager Application Server Control as Reports Server.
However, after you upgrade to OracleAS Reports Services 11g, the in-process server appears in Oracle Enterprise Manager Fusion Middleware Control as an application, called reports, and you can manage the in-process server target and the Reports servlet on the Reports application page.
Cached Reports output files are not upgraded to Oracle Reports 11g.
If you are using single sign-on software for authentication, then in certain upgrade scenarios, you must re-register your Oracle Forms and Reports software with the single sign-on software.
Refer to the following sections for more information:
Scenarios That Require Regeneration of Single Sign-on Configuration Information
Product-Specific Instructions for Regenerating Single Sign-On Configuration Information
The following table describes the typical upgrade scenarios that require the re-generation of the single sign-on client access files after the upgrade to Oracle Forms and Reports 11g Release 2 (11.1.2).
Table 6-1 Upgrade Scenarios That Require Regeneration of Single Sign-On Configuration information
| Upgrade Scenario | Description |
|---|---|
|
Upgrading from Oracle Single Sign-On 10g to Oracle Access Manager 11g |
Oracle Forms and Reports 11g Release 2 (11.1.2) supports Oracle Access Manager 11g as a single sign-on alternative to your existing Oracle Single Sign-On 10g software. For more information, see Section 1.7, "About Using Identity Management and Single Sign-On With Oracle Forms and Reports 11g Release 2 (11.1.2)". If you install your target Oracle Forms and Reports 11g Release 2 (11.1.2) software against Oracle Access Manager 11g, then after you upgrade, you must generate new configuration information for the Oracle HTTP Server so the server can connect to Oracle Access Manager, instead of Oracle Single Sign-On 10g. Similarly, if you later upgrade from Oracle Single Sign-On 10g to Oracle Access Manager 11g, then you must perform the same procedure. |
|
Configuring Oracle HTTP Server to work with Oracle Web Cache |
Oracle Forms and Reports 11g Release 2 (11.1.2) does not include Oracle Web Cache. As a result, configuration data for connecting Oracle HTTP Server with your existing Oracle Web Cache instances is not preserved during upgrade. For more information, see Section 1.6, "About Using the Web Tier Components with Oracle Forms and Reports 11g Release 2 (11.1.2)". If--after upgrade--you configure your Oracle HTTP Server instance to work with your existing Oracle Web Cache instances, you must generate new configuration information for the Oracle HTTP Server so the server can connect to your single sign-on software. |
The procedure you use to regenerate your single sign-on configuration information varies depends on the single sign-on software you are using, as well as the way it was configured. See the following for more information:
If you are using Oracle Single Sign-On 10g, then you must regenerate the osso.conf file and copy it to the proper location where the Oracle HTTP Server can read it.
For more information, see "Generating the osso.conf file for the OracleAS Single Sign-On Server 10g" in the Oracle Fusion Middleware Forms Services Deployment Guide.
If you are using Oracle Access Manager 11g and you are not using the Oracle HTTP Server WebGate plugin, then you must regenerate the osso.conf file and copy it to the proper location where the Oracle HTTP Server can read it.
For more information, see "Generating the osso.conf file for Oracle Access Manager" in the Oracle Fusion Middleware Forms Services Deployment Guide.
If you are using Oracle Access Manager 11g and you are using the Oracle HTTP Server WebGate plugin, then you must register WebGate agent, copy the generated files to the proper location, and then restart the Oracle HTTP Server instance.
For more information, see:
"Installing and Configuring Webgate with OAM" in the Oracle Fusion Middleware Forms Services Deployment Guide.
"Getting Started with a New Oracle HTTP Server 11g Webgate Agent for Oracle Access Manager" in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Refer to the following sections for information about post-upgrade tasks you must perform for your Web Tier components after upgrading to Oracle Forms and Reports 11g Release 2 (11.1.2):
If you were using Oracle Web Cache prior to the Oracle Forms and Reports 11g Release 2 (11.1.2) upgrade, you can continue to use your existing Oracle Web Cache instance. However, you must reconfigure both Oracle Web Cache and Oracle HTTP Server after the upgrade is complete.
For more information, see "Basic Tasks for Configuring and Managing Oracle Web Cache" in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache.
If you are also using Oracle Single Sign-On 10g or Oracle Access Manager 11g, then after you reconfigure the ports and connections, you will likely need to re-register your installation with your single sign-on software. For more information, see Section 6.3, "Post-Upgrade Tasks Required When Using Single Sign-On Software".
In addition:
If you are currently using Oracle Web Cache 10g, then you can consider upgrading your Oracle Web Cache 10g installation to Oracle Web Cache 11g.
For information on upgrading from Oracle Web Cache 10g, see "Upgrading a Java EE and Web Server Environment" in the Oracle Fusion Middleware Upgrade Guide for Java EE.
If you are already running Oracle Web Cache 11g, consider applying the latest 11g patch set so you are running the very latest Oracle Web Cache software.
For information on applying the latest Oracle Fusion Middleware patch set, see the Oracle Fusion Middleware Patching Guide.
If you are using SSL to secure your Oracle HTTP Server, you must perform the following task after you complete the upgrade to Oracle Forms and Reports 11g Release 2 (11.1.2).
If you do not perform this step, you will receive an error message when attempting to access services or URLs via the Oracle HTTP Server instance. For example, if you are using a single sign-on server, then you might receive an error message similar to the following:
Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or OHS single sign-on is incorrectly configured. Please notify your administrator.
To address this problem:
Locate the following element in the httpd.conf file for the Oracle HTTP Server:
ServerName hostname:portValue
Update the portValue so it references the secure HTTPS listening port for the Oracle HTTP Server instance.
For example:
ServerName webhost1.example.com:8090
For more information, see "Modifying an Oracle HTTP Server Configuration File" in the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.
For more information about tasks and information for Oracle HTTP Server and Oracle Web Cache after you upgrade to Oracle Fusion Middleware 11g, see "Task 5: Perform Any Required Post-Upgrade Tasks for the Web Tier Components" in the Oracle Fusion Middleware Upgrade Guide for Java EE.