2 Prepare for the Release 12 Upgrade Before Downtime

This section describes the preparation steps for upgrading to Oracle Fusion Applications Release 12 (11.12.x.0.0), all of which can be performed before the scheduled downtime. The following topics are discussed:

2.1 Preliminary Steps

Before starting the upgrade, perform the following preliminary steps:

  1. Perform all steps listed in the Pre-Upgrade Known Issues in the latest Oracle Fusion Applications Technical Known Issues - Release 12 (Doc ID 2224140.1) found on My Oracle Support.
  2. If there are any installed languages in addition to US English, perform all steps list in the Pre-Upgrade Known Issues, if any, from the latest Oracle Fusion Applications NLS Known issues found on My Oracle Support.
  3. Ensure that the following update bundles have been applied on the environment prior to upgrading to the next release:
    • Oracle Fusion Middleware Update Bundles (P4FA) for Oracle Fusion Applications

      To find the latest technical patch bundle for the release being upgraded from, perform the following steps:
      1. Go to My Oracle Support, log in, and then navigate to Patches and Updates
      2. In the Patch Search panel, select Product or Family (Advanced) and enter "Oracle Fusion Applications Technology Patches" in the drop down labeled Product.
      3. Select the correct release and platform, and then click Search.
      4. In the search results, find the patches with the P4FA naming convention and select the most recent one.
    • Oracle Fusion Applications Update Bundles

      Refer to Oracle Fusion Applications Known Issues and Update Documents (Doc ID 1603154.1) on My Oracle Support. Then, click Oracle Fusion Applications Update Documents.

    For information about how to install update bundles, review the update bundle README file. To obtain additional information about update bundles, contact Oracle Support.

  4. Ensure sendmail is configured and working on all hosts where Upgrade Orchestrator runs by sending a test mail from the hosts. Sendmail must be working properly before running the upgrade to effectively monitor the upgrade status.
  5. If you are upgrading from Release 8 (11.1.8.0.0), you must upgrade the Fusion Applications and IDM databases from Oracle Database version 11.2.0.3 to 11.2.0.4. This is a prerequisite for upgrade to Fusion Applications Release 12 (11.12.x.0.0). You should upgrade the database before performing the tasks listed in Update the Oracle Fusion Applications and Oracle Identity Management Databases.
  6. The task Prepare to Register Database Schema Information requires a password which is referred to as the "Master Orchestration Password" in this documentation. Decide upon the master orchestration password at this time. This password must be a minimum of 8 characters long and it must contain at least one alphabetic character and at least one numeric or special character.

2.2 Pre-Upgrade Tasks for Release 8 to Release 12 Direct Upgrades

Before performing Release 8 to Release 12 direct upgrades, you must download the HCM bundle patch (26486308 FA HCM AOO 170719 11.1.8.0.0) from My Oracle Support and apply it to the environment as follows:
  1. Download the patch 26486308 from My Oracle Support and stage it into the environment where the patch needs to be applied.

  2. Unzip the patch content as shown in the following example:
    unzip /u01/p26486308_111800_Fusion_GENERIC.zip
    
     
  3. Validate the patch as follows:
    1. Copy the patch to the patch_stage location. For example:
      cd /u01
      
    2. Run the validate command as follows:
      <APPLTOP_LOC> /lcm/ad/bin/fapmgr.sh validate -patchtop <patch_num> -online
      
      For example:
      /u01/APPLTOP/fusionapps/applications/lcm/ad/bin/fapmgr.sh validate -patchtop 26486308 -online
      
  4. Apply the patch as follows:

    1. Copy the patch to the patch_stage location. For example:
      cd  /u01
      
    2. Run the apply command as follows:
      <APPLTOP_LOC>/lcm/ad/bin/fapmgr.sh apply -patchtop $patchnum -start_adpatch_opt force_branch_order=Patch_Is_Higher -end_adpatch_opt -workers=4 -stoponerror -online
      
      For example:
      /u01/APPLTOP/fusionapps/applications/lcm/ad/bin/fapmgr.sh apply -patchtop 26486308 -start_adpatch_opt force_branch_order=Patch_Is_Higher -end_adpatch_opt -workers=4 -stoponerror -online 
      
  5. Verify the patch application by running the following command:
    <APPLTOP_LOC> /lcm/ad/bin/fapmgr.sh report -isapplied -patch <patch_num>
    
    For example:
    /u01/APPLTOP/fusionapps/applications/lcm/ad/bin/fapmgr.sh report -isapplied -patch 26486308
    
This task will resolve upgrade issues during loading of DB components.

2.3 Pre-Upgrade Tasks for IDM for FA Upgrade to Release 12

Before you begin the upgrade of your IDM environment for Oracle Fusion Applications (FA) to Release 12, you must verify that your system meets the upgrade requirements and perform pre-upgrade tasks:

2.4 System Requirements

Ensure that the environment meets the following system requirements:

2.4.1 Verify Memory Requirements

If the environment does not meet the memory requirements, Health Checker reports an error during the pre-downtime phase. Verify that the memory configuration meets the requirement mentioned in the following table:

Table 2-1 Memory Requirements for Non-Oracle VM Environments

Memory Specifics Upgrade From Release 8, 9, 10 or 11 to Release 12

Memory per Managed Servers

2.75GB (2816MB) multiplied by the number of managed servers in the environment, plus 4GB

Memory Per Administration Servers

  • 1GB multiplied by the number of administration servers in the environment, if the WebLogic domain is not a product family of the product offerings that was selected

  • 2GB multiplied by the number of administration servers in the environment, if the WebLogic domain is a product family of the product offerings that was selected

Business Intelligence Cluster (bi_cluster / BIDomain)

7GB multiplied by the number of instances of managed servers of bi_clusters in the environment

Oracle Enterprise Data Quality Cluster (EDQCluster / CommonDomain)

16GB for two instances of the EDQ WebLogic managed server created out of the box if any of the following product offerings has been selected:

  • CRM: Sales, Marketing, Customer Data Management, Enterprise Contracts

  • Financials: Financials, Procurement

  • SCM: Product Management, Material Management and Logistics, Supply Chain Financial Orchestration

Workforce Reputation Cluster (WorkforceReputationCluster / HCMDomain)

8GB multiplied by the number of managed servers in the environment if any of the following product offerings is selected:

  • Workforce Development

  • Workforce Deployment

For Oracle Virtual Machine (VM) memory requirements, see Suggested Memory (in GB) and Number of vCPUs in Oracle Fusion Applications Installing and Managing in an Oracle VM Environment.

2.4.2 Verify Free Disk Space Requirements

The disk space requirements mentioned in the following table are recommendations on the disk space required on specific hosts. If the environment does not meet these requirements, Health Checker reports an error during the pre-downtime phase. The disk space check does not check for total space, as it checks only for usable disk space, which is defined as free space with respect to quotas and permissions.

All recommendations and requirements assume non-shared access to the disk space. Therefore, if there are multiple hosts or processes running against the same physical disk, the size of this disk needs to be determined with respect to all sharing tenants. The requirements in the following table do not consider disk sharing scenarios:

Table 2-2 Free Disk Space Requirements

Host Name Upgrade From Release 8, 9, 10 or 11 to Release 12

Primordial

100GB for /u01 + 4GB for /tmp

DB

36GB for tablespaces and redo logs + 4GB for flash recovery area (if configured). Use a higher value for estimated tablespaces as required. For example, calculate the consolidated total free space required for upgrade from multiple schemas for FUSION_TS_TOOLS tablespace (for example, 10GB free space in FUSION_TS_TOOLS)

APPOHS

10GB for /u01 + 4GB for /tmp

Midtier (Primary, Secondary, and BI Hosts)

5GB for /u01 + 4GB for /tmp

OID/OIM

30GB for /u01/IDMTOP + 10GB for /u02/local/IDMTOP + 4GB for /tmp

OHSAUTH

10GB for /u01/IDMTOP + 10GB for /u02/local/IDMTOP + 4GB for /tmp

OID/OIM/OHSAUTH

400MB for log directory. This is shared between the hosts. Log directory is the value configured for the LOG_LOCATION property in IDM.properties and the LOG_DIR property in upgradeOnPremise.properties. However, LOG_DIR is the location where IDM on-premise upgrade logs are placed.

2.4.3 Verify Reserved Ports Are Available

Ensure that the following reserved ports are not used for any customization or manual scale up activities to prevent port conflicts:

  • Ports 7000 through 13000 are reserved for creating WLS components across all domains

  • Ports starting from 17000 are used by internal scale out and external scale out

2.4.4 Verify OS Patch Requirements

For Solaris 10 Only

  • For Oracle Solaris on SPARC (64-bit) platforms, ensure that the Solaris Operating System patch 150400-xx is installed on the servers.

  • For Oracle Solaris on x86-64 (64-bit) platform, ensure that the Solaris x64 Operating System patch 150401-xx is installed on the servers.

These patches can be obtained from My Oracle Support.

For Solaris 11 Only

  • Ensure that the Solaris Package SUNWttf-bh-luxi is installed on the FA servers for both Oracle Solaris on SPARC (64-bit) and Oracle Solaris on x86-64 (64-bit) platforms.

  • The SRU 11.3.3.6.0 or later (mandatory patch) is required for the Solaris 11 Update 3 on SPARC or x86-64.

2.5 Set Up Upgrade Directories and Obtain Software

Perform the following steps to set up upgrade directories and obtain software required for the upgrade:

2.5.1 Create a Common User Group and Permissions for Shared Directories

The steps in this section outline the process for setting up permissions on directories that are shared across multiple hosts and are used by Oracle Fusion Applications Upgrade Orchestrator. These steps are required if different operating system (OS) users and groups are used to own Oracle Fusion Applications components (such as FA, FMW, and IDM) on the hosts in the Oracle Fusion Applications environment (such as Primordial, OHS, and IDM).

An OS user and group is considered to be the same across all hosts only if the corresponding IDs (User ID and Group ID) are also the same across the hosts. The minimum requirement for Upgrade Orchestrator is that the files in the SHARED_LOCATION must be owned by the same group. All OS users that own Oracle Fusion Applications components on various hosts must belong to the common group, in addition to other groups to which they already belong.

MANDATORY: The SHARED_LOCATION must be exported with the no_root_squash option, or its equivalent, to allow root user access to files in the SHARED_LOCATION that are owned by the applications user. For more information about the SHARED_LOCATION, see Create Directories in a Shared Location.

To set up permissions on directories that are shared across multiple hosts and are used by Oracle Fusion Applications Upgrade Orchestrator, perform the following steps:

  1. Determine the OS group and Group ID that needs to be used for owning the shared directories. As an example, it is possible to use orch as the common group to be used across the hosts.

  2. Perform the following steps as a privileged OS user, such as root, on all hosts that participate in orchestration:

    1. Create the common group as shown in the following example (if needed):

      (Linux) /usr/sbin/groupadd -g group_ID -f group_name
      
      (Solaris) /usr/sbin/groupadd -g group_ID group_name
      
    2. Add each distinct Oracle Fusion Applications component (FA, FMW, DB, IDM) OS owner on each host to the common group as shown in the following example:

      (Linux) /usr/sbin/usermod -a -G group_name component_OS_owner
      
      (Solaris) EXISTING_GROUPS=$(grep -w component_OS_owner /etc/group |awk -F: '{print $1}' |xargs echo | sed 's/ /,/g')
      /usr/sbin/usermod -G ${EXISTING_GROUPS},group_name component_OS_owner
      

      Log out of any sessions that were open prior to this change for OS users being modified, and then log in again so the changes take effect.

    3. Mount the file system to be used for the shared directories on all hosts.

    4. On one of the hosts, such as the primordial host, create a top-level directory that is passed to orchestration under which additional directories and files are created during orchestration. This directory is referred to as SHARED_LOCATION and is further described in Create Directories in a Shared Location.

    5. Before any additional content is created in the shared directories, change the group ownership of the top-level directory to the common group, such as orch as shown in the following example:

      (Linux and UNIX) chgrp common_group SHARED_LOCATION
      
    6. Set permissions on the directory so that the group has read, write, and access privileges as shown in the following example:

      (Linux and UNIX) chmod g+r,g+w,g+x SHARED_LOCATION
      
    7. Set the Directory group ID bit for the top-level shared directory. This allows for any subdirectories and files created under this shared directory to be owned by the same group, regardless of the host from where they are created. For example:

      (Linux and UNIX) chmod g+s SHARED_LOCATION
      
  3. Perform the following steps on all hosts that participate in orchestration. Make sure to be logged in as the OS user that owns the Oracle Fusion Applications content on the host when running these steps:

    1. Set the default mask for files so that the group has sufficient privileges on the files as follows:

      umask 0007
      
    2. Confirm that the group changes are effective. The groups command displays all groups that the current OS user belongs to. Confirm that the common group, orch, is one of them as follows:

      (Linux and UNIX) groups
      
    3. Confirm that the permissions are set up correctly on each host. To do this, create a temporary file in the shared directory and confirm that the file is owned by the common group and that its permissions are correct.
      • For directories, the group should have read, write, and execute privileges.
      • For files, the group should have at least read and write privileges.
      Run the following commands after creating the temporary file:

      The following command should show that the file is owned by the common group:

      (Linux and Unix)) ls -ls file_name
      

      The following command prints the group and group ID ownership for the file:

      (Linux) stat --printf="%G %g\n" file_name
      
      (Solaris) echo "group: `ls -ld file_name|awk '{print $4}'" "`"; echo "groupid:`ls -dn file_name | awk '{print $4}'" "`"
      

      Then, remove the temporary file.

    When unzipping the contents of a ZIP archive into the shared folder, the group ownership can be lost on some folders and files. This issue is specific to the unzip utility. To work around the issue, run the following commands when extracting contents to the shared folder:
    jar -xvf ZIP_archive
    unzip -q -o ZIP_archive
    
  4. Ensure file permissions are correct by performing the following steps, as a prerequisite to starting orchestration:

    1. Change directory to FA_ORACLE_HOME/hcm/hrc/bin.

    2. Run chmod -R 755 *.

    3. During the upgrade, patch_stage directories are created in a location which is parallel to the APPLICATIONS_BASE directory. If the user ID who is running the upgrade does not have write permissions, the Consolidating Repository and Downloaded Patches configuration assistant reports a failure. To avoid this failure during the upgrade, ensure that the user who runs Upgrade Orchestrator has write permissions on the top level directory parallel to the APPLICATIONS_BASE directory, which is typically /net/mount1.

2.5.2 Create Directories in a Shared Location

Create the directories required for the upgrade in a shared location that is accessible to all host types, including scaled out hosts, in the Oracle Fusion Applications environment. This location is referred to as SHARED_LOCATION in this guide.

If more than one environment are being upgraded, those environments can be configured to access this SHARED_LOCATION to avoid duplicating the software downloads. These directories must also be available to all users and if different users create any of the directories, the users must belong to the same shared group.

The directory names in this section are suggested names and are referenced throughout the upgrade steps. It is possible to choose to use other naming conventions. See Download Directories.

Create the following directories for Release 12 repositories:

  • SHARED_LOCATION/11.12.x.0.0/Repository

  • SHARED_LOCATION/11.12.x.0.0_post_repo_patches

  • SHARED_LOCATION/11.12.x.0.0/idmUpgrade

  • SHARED_LOCATION/11.12.x.0.0/LP (required only if languages other than US English have been installed)

  • SHARED_LOCATION/11.12.x.0.0/PCU. Stage post repo patch for the pcu_bundle.zip in this location. Leave this location empty if there is no post repo for pcu_bundle.zip.

2.5.3 Create Orchestration Checkpoint Locations

Create the following directories in a shared storage that is available to all users and all host types within the environment that is getting upgraded:

These directories can also optionally be configured to be shared across other environments.

  • ORCHESTRATION_CHECKPOINT_LOCATION

    This is a shared location available to all hosts in the environment where orchestration checkpoint related files are saved. Ensure a shared mount point that has high disk I/O performance is selected, especially for writing. Orchestration framework automatically creates POD_NAME under the specified directory. This location is stored in the ORCHESTRATION_CHECKPOINT_LOCATION property in the pod.properties file.

    It is a best practice not to use ORCH_LOCATION/config as a value for this property.

  • ORCHESTRATION_CHECKPOINT_ARCHIVE_LOCATION

    This is a shared location available to all hosts in the environment where orchestration checkpoint related files are archived. Ensure that a shared mount point that has high disk I/O performance is selected, especially for writing. Orchestration framework automatically archives the checkpoint file stored under the POD_NAME directory in the directory specified by the ORCHESTRATION_CHECKPOINT_LOCATION property. This location is stored in the ORCHESTRATION_CHECKPOINT_ARCHIVE_LOCATION property in the pod.properties file.

    It is a best practice not to use ORCH_LOCATION/config as a value for this property.

2.5.4 Create the Shared Upgrade Location Directory

Create a directory referred to as SHARED_UPGRADE_LOCATION in shared storage that is available to all users and all host types within the environment that is getting upgraded. This directory can also optionally be configured to be shared across other environments.

This is a temporary directory required by the upgrade to copy files and perform write operations. Ensure that a shared mount point that is shared across all hosts for a given environment that has high disk I/O performance is selected, especially for writing. This area can be cleaned up after all of the environments have been successfully upgraded to Release 12.

Additionally, create the following directory:

SHARED_UPGRADE_LOCATION/healthchecker/common

Grant write access to the group that was created in Create a Common User Group and Permissions for Shared Directories as well as the checkpoint location and shared upgrade directories that were created in this section.

2.5.5 Download and Unzip the Patch Rollback Automation Script

To download and unzip the Patch Rollback Automation script, perform the following steps:
  1. Download and unzip patch 22005049 from My Oracle Support into SHARED_LOCATION/11.12.x.0.0. Unzip this patch as the same user that runs the upgrade. Unzipping the file creates the PatchRollbackUtil directory with the relevant scripts under SHARED_LOCATION/11.12.x.0.0 that gets used during upgrade.

  2. Validate and correct the Oracle Homes and the JDK location properties found within the following properties files:

    These files can be found under their config folders respectively, where the PatchRollbackUtil patch is staged.
    • config/ADMIN-APPS/ADMIN-APPS.properties

    • config/APPOHS/APPOHS.properties

    • config/AUTHOHS/AUTHOHS.properties

    • config/OIDFA/OIDFA.properties

    • config/OIMFA/OIMFA.properties

2.5.6 Download and Unzip the Release 12 Repository

The Release 12 repository contains all patches that are required to upgrade to Release 12 in an existing Oracle Fusion Applications environment. To download the repository from the Oracle Fusion Applications Product Media Package, perform the following steps:

  1. Go to Oracle Software Delivery Cloud.
  2. Complete the Export Validation process by entering basic identification information using the online form.
  3. On the Media Pack Search page, select Oracle Fusion Applications as the product pack and then select the platform to identify the media pack to be downloaded.
  4. Choose the appropriate media pack from the search results, such as Release 12 (11.12.x.0.0) for your platform, and download the Release repository (in zipped format) to SHARED_LOCATION/11.12.x.0.0/Repository.
  5. Extract the contents of all zipped files to the same target directory, SHARED_LOCATION/11.12.x.0.0/Repository. This directory is referred to as REPOSITORY_LOCATION in this guide.

    To download the Oracle Fusion Applications 11g Media Pack, use the UnZip / 7-Zip utility to extract the Oracle software to REPOSITORY_LOCATION. UnZip is a freeware tool that is available at the Info-Zip website.

To see the options available to obtain the Oracle Fusion Applications software, see Obtain the Software in the Oracle Fusion Applications Installation Guide.

2.5.6.1 Download and Unzip the BI Patch 25499241 into the FA Repository (Solaris Only)

The BI patch 25499241 application fails in Fusion Applications (FA) upgrade in Release 11.12.x.0.0. To resolve this issue, perform the following steps:

  1. Download the patch 25499241 from My Oracle Support to any temporary directory (outside the FA repository) on the machine where the FA repository is present.
  2. Remove the patch 25499241 from the FA repository as follows:
    rm -rf <REPOSITORY_LOCATION>/installers/biappsshiphome/patch/25499241
    
  3. Extract the patch downloaded in Step 2 to the FA repository as shown in the following example:
    cd <REPOSITORY_LOCATION>/installers/biappsshiphome/patch 
    unzip <PATCH_LOCATION>/p25499241_111190_SOLARIS64.zip  (for Solaris Sparc)
    unzip <PATCH_LOCATION>/p25499241_111190_Solaris86-64.zip (for Soalrisx86-64) 
    

2.5.7 Stage Fusion Applications High-Water Mark Patch Bundles

It is mandatory to apply Fusion Applications High-Water Mark Patch Bundles after upgrade is completed. The patch bundles includes P4FA, BIPB, and FAPB patch bundles.

To get more information about high-water mark patch bundles, contact My Oracle Support.

2.5.7.1 Inject ASINST Patch into Repository

The ASINST Patch 25588435 requires injecting the fix into the repository directly. If you intend to install additional Languages, then you must complete the step Download and Unzip Release 12 Language Packs to stage the language packs into the repository, and then perform the instructions in this section.

To inject the fix, you must stage the new repository injection patch 25588435 to a temporary location, and then perform the following steps:

  1. Go to the temporary location.

  2. Invoke the following command:
    ./applyPatch.sh -repoDir SHARED_LOCATION/11.12.x.0.0/Repository
    
    This command will inject the patch in farup and fusionapps and it will also try to inject the patch assuming the langpack directory is one of following:
    • /fsnadmin/upgrade/fusionChangeOps/11.12.1.0.0/LP

    • /fsnadmin/fusionChangeOps/patches/lang/rel12.1

    If the langpack directory is different, then pass -langpackBaseDir <location> as shown in the following example:
    ./applyPatch.sh -repoDir SHARED_LOCATION/11.12.x.0.0/Repository [-langpackBaseDir <location>]
    

    If the patch apply is not successful, the exit code will be non-zero.

2.5.7.2 Inject OUI Patch 26243092 into Repository

If you are uptaking July 17 Post Repo or later and have not injected the OUI patch 26243092 into the repository, then you must perform the following steps:

The bug 26243092 requires injecting the fix into the repository directly. To inject the fix, you must stage the new repo injection patch to a temporary location, and then perform the following steps:
  1. Go to the temporary location.

  2. Invoke the following command:
    ./inject.sh [-repo_dir <Absolute path of repository directory>]
    
    For example:
    ./inject.sh -repo_dir /scratch/fa_repos
    
    Command for Solaris:
    bash inject.sh [-repo_dir <Absolute path of repository directory>]
    
    For example:
    bash inject.sh -repo_dir /scratch/fa_repos
    

    This command will inject the patch in the following shiphomes under the specified repository: faprovfarupfusionappsgopbhd/fusionbhd and oui_upgrade/cd.

    If the patch apply is not successful, the exit code will be non-zero.

2.5.8 Download and Unzip Mandatory Post-Release 12 Patches

After the repository is shipped for every release of Oracle Fusion Applications, additional required patches are staged in a "post repository" directory. The Upgrade Orchestrator can apply these mandatory post-release if the patches are downloaded from My Oracle Support before starting upgrade. The latest post-release patches are cumulative. You must always start by staging the latest post-release patches in a clean location that does not have any files or directories.

To download patches for Release 11.12.x.0.0, first unzip the /SHARED_LOCATION/11.12.x.0.0/Repository/installers/pre_install/PostRepoPatchDirs.zip file into the /SHARED_LOCATION/11.12.x.0.0_post_repo_patches directory to create the directory structure for the downloaded patches. Then, stage the patch bundles and post repo patches accordingly. The orchestration process automatically picks the patches from the SHARED_LOCATION/11.12.x.0.0_post_repo_patches directory when launching the Upgrade Orchestrator, and the upgrade process continues.

The following table shows the patches that must be installed when upgrading to Oracle Fusion Applications Release 12.

Note:

For information about the September 18 Post Repo onward, see the Oracle Fusion Applications Technical Known Issues - Release 12 (Doc ID 2224140.1).

Table 2-3 Mandatory Release 11.12.x.0.0 Patches

Patch Type Release Patch Number Action to be Taken

Installer

11.12.x.0.0

Patch 23012897

Perform the following steps:

  1. Download and unzip the contents of patch 23012897 based on the target release you are upgrading to. For example, if you are upgrading to 11.12.1.0.0 (from any release), you must download and stage the patch associated with the high watermark release you are upgrading to.

  2. Stage the downloaded content under SHARED_LOCATION/11.12.x.0.0_post_repo_patches/installer.

  3. After unzipping the patch, verify that the following folders and files are available directly under the SHARED_LOCATION/11.12.x.0.0_post_repo_patches/installer directory:

    • LatestUpdates (folder)

    • metadata (folder)

    • readme.txt (file)

    The readme.txt file contains the details of the patch.

Note: The patch delivers solutions to issues that were identified post release. If you do not find content under patch 23012897 associated with the high watermark release you are upgrading to, no new version of the installer patch is released for that release.

FMW/LCM

11.12.x.0.0

September 11 Post Repo:

Patch 26773421

Perform the following steps:
  1. Download patch 26773421 and unzip it into a temporary location. You should get a directory containing the patch and the readme files.

  2. From the temporary location, locate the post_repo_linux64.tar.gz under <patch number>/dist directory.

  3. Inspect post_repo_linux64.tar.gz to make sure there are top directories such asatgpf, biaapsshiphome, ecm_bucket2, fusionapps, fusionapps_opatch, oracle_common, etc., for example:
    tar tzf post_repo_linux64.tar.gz --exclude '*/*/*'
    
  4. Once confirmed, unzip post_repo_linux64.tar.gz into the SHARED_LOCATION/11.12.x.0.0_post_repo_patches directory.

    For Solaris platforms only: unzip the post repo patch tar file (post_repo_solarissparc64.tar.gz for Solaris Sparc and post_repo_solarisx64.tar.gz for Solaris x86-64) on a Linux host, then copy the extracted patches to SHARED_LOCATION/11.12.x.0.0_post_repo_patches.

  5. After the post repo patch is staged, you should have all the patch contents including directories such as atgpf, biaapsshiphome, ecm_bucket2, fusionapps, fusionapps_opatch, oracle_common, etc. under SHARED_LOCATION/11.12.x.0.0_post_repo_patches.

FA

11.12.x.0.0

Patch 26580880

Download and unzip the content of patch 26580880 into the SHARED_LOCATION/11.12.x.0.0_post_repo_patches directory. This will place the patch contents under the SHARED_LOCATION/11.12.x.0.0_post_repo_patches/fusionapps/upgrade directory.

To verify if the Installer (Auto Update Patch) post release patch is picked up correctly, check the following after the upgrade:
Installer Log
  • Ensure that the installer log has messages indicating that the updates from post-repo patch location are merged.

  • File: /u01/inventory/admin-apps.oracleoutsourcing.com/oraInventory/logs (look for the file that matches the timestamp of the operation).

  • Look for the following message:
    "Applying Updates and Restarting Installer"
    
OracleHomeProperties
  • File: fusionapps/applications/inventory/ContentXML/oraclehomeproperties.xml.

  • Ensure that the ARU_ID set to 226 and PATCHINGMODEL set to SNOWBALL as shown in the following example:
    <ARU_ID>226</ARU_ID>
    <PROPERTY NAME="PATCHING_MODEL" VAL="snowball"/>
    
  • Ensure that OracleHomeProperties has hard-links defined (must be > 1) as shown in the following example:
    ls -ls oraclehomeproperties.xml
    4 -rw-r----- 2 aime svrtech 483 Feb 13 12:20 oraclehomeproperties.xml
    

Language Installed Artifacts

This step is only applicable if language packs are installed.
  • Ensure that it has hard-links defined (must be > 1) as shown in the following example:
    ls -ls fin/deploy/jar_*.jar
    4 -rw-r----- 2 aime svrtech 1207 Feb 13 12:05 jar_FinPmtFDCoreSoaResource.jar
    

To create the directory structure for the downloaded patches, unzip the /SHARED_LOCATION/11.12.x.0.0/Repository/installers/pre_install/PostRepoPatchDirs.zip into the 11.12.x.0.0_post_repo_patches directory. Then, proceed with staging all the available Post Release Patch content. The post-repo structure looks like the following:

Default Post Repo: (Will only get used when FA PB is not applied within the upgrade window)
  • SHARED_LOCATION/11.12.1.0.0/11.12.1.0.0_post_repo_patches/<fa post repo content corresponding to GA level>

  • SHARED_LOCATION/11.12.1.0.0/11.12.1.0.0_post_repo_patches/<latest fmw post repo content>

  • SHARED_LOCATION/11.12.1.0.0/11.12.1.0.0_post_repo_patches/<Installer content>

2.5.9 Download and Unzip Release 12 Language Packs

For each language installed in your environment, download the Release 12 language pack from http://edelivery.oracle.com to the SHARED_LOCATION/11.12.x.0.0/LP directory. The location of the downloaded language packs is recorded in the REL12_LP_REPOSITORY_LOCATION property in the Primordial host properties file, as described in Table 10-2.

To find all installed languages in the environment, run the following query:

select LANGUAGE_TAG, ISO_LANGUAGE, ISO_TERRITORY from FND_LANGUAGES where INSTALLED_FLAG in ('I', 'B')

2.5.10 Download Patches for the Health Checker Exclusion List

Health Checker performs sets of validations at various stages of the upgrade. Download the following patches for Release 11.12.x.0.0 from My Oracle Support to have all the required information available for Health Checker:

Create the SHARED_UPGRADE_LOCATION/healthchecker/common directory if it does not yet exist.

  • Download patch 24623814 and extract its contents to the SHARED_UPGRADE_LOCATION/healthchecker/common directory. This patch defines Health Checker plug-ins that are to be disabled out-of-the-box. This patch will be updated with additional plug-in(s) to be excluded as short term solutions(s) when required.

    MANDATORY: This patch is mandatory and its latest version must be downloaded and staged before running Orchestration.

  • Verify whether the following patches are available from My Oracle Support. If one of the patches for the target release is not available, ignore the patch as no action is required:

    • Patch 17051994: If available, download and extract its contents, such as FA_invalid_overrides.xml, from the patch to the SHARED_UPGRADE_LOCATION/healthchecker/common directory. This patch ensures that a set of objects that get into an invalid state during intermediate stages of the upgrade are safely ignored.

    • Patch 21196045: If available, download and extract its content, such as FA_file_permissions_template_overrides.xml, from the patch to the SHARED_UPGRADE_LOCATION/healthchecker/common directory. This patch defines the metadata that is used to check Fusion Applications file permissions. When filenames and folder names are added to the contents of this file, those files and folders are verified by the Health Checker File Permission check. This plug-in is disabled out-of-box. To re-enable this check, see Customization: Re-enable a Plug-in that is Disabled in all_overrides.xml.

    • Patch 21204921: If available, download and extract its content, such as FA_fmw_file_permissions_template_overrides.xml, from the patch to the SHARED_UPGRADE_LOCATION/healthchecker/common directory. This patch defines the metadata that is used to check Fusion Middleware file permissions. When filenames and folder names are added to the contents of this file, those files and folders are verified by the Health Checker File Permission check. This plug-in is disabled out-of-box. To re-enable this check, see Customization: Re-enable a Plug-in that is Disabled in all_overrides.xml.

2.5.11 Unzip Orchestration.zip

To download and unzip the latest versions of Orchestration.zip and the Health Checker framework, perform the following steps:

  1. The latest version of the Orchestration.zip file is uploaded to patch 23012894 on My Oracle Support after Release 12 is released. To ensure you have the latest version of Orchestration.zip, download patch 23012894 from My Oracle Support. The patch contains Orchestration.zip, readme.txt, and validateOrchVersion.py scripts. Extract the patch contents to a temporary location.
    Do not download the patch while Orchestration is running or while upgrade orchestration exits due to a pause point or a failure. This patch can be downloaded and used only in case of restoring the environments to the original state. For this case, the upgrade must be started from the beginning.

    The patch delivers solutions to issues that were identified post release. If content associated with the high watermark release being upgraded to is not found under patch 23012894, no new version of Orchestration.zip was released yet. Use the Orchestration.zip file that is delivered in the Release 11.12.x.0.0 repository, located at SHARED_LOCATION/11.12.x.0.0/Repository/installers/farup/Disk1/upgrade/orchestration.

  2. Unzip the Orchestration.zip file from the appropriate location, as described in Step 1, to SHARED_LOCATION/11.12.x.0.0. Unzip the Orchestration.zip file as the same operating system user that was used to set up the Oracle Fusion Applications environment. If the file is unzipped under a different user, see Create a Common User Group and Permissions for Shared Directories.

    When unzipping Orchestration.zip, a directory named orchestration is created. This directory is referred to as ORCH_LOCATION. See The ORCH_LOCATION Directory.

  3. If the patch was not downloaded in Step 1, proceed to Step 4. If the latest Orchestration.zip file was downloaded from the patch in Step 1, run the validate script given below to validate the version of Orchestration.zip. This confirms that the correct Orchestration.zip file was unzipped to the shared storage location.
    validateOrchVersion.py ORCH_LOCATION
    

    If the script finishes with errors, ensure that the ORCH_LOCATION argument passed to the command is correct and that it points to the location where the latest Orchestration.zip file was unzipped. If the argument is correct, contact Oracle Support for further assistance.

  4. After unzipping the Orchestration.zip file, which contains the Health Checker framework, ensure that the latest version of Health Checker is installed by checking the existence of patch 20845106 on My Oracle Support.
    • If there is no patch available, use the Health Checker packaged with Orchestration.zip downloaded in Step 1.

    • If the patch is available, view the creation date in the readme.txt file available with the Health Checker patch file and compare the file's creation date with the creation date of Orchestration.zip. To check which Orchestration.zip file is being used, see Step 1 of this procedure.

      • If the Health Checker patch is older than Orchestration.zip, no action is required. Use the same Health Checker embedded with the Orchestration.zip file.

      • If the Health Checker patch is newer than Orchestration.zip, unzip patch 20845106 from My Oracle Support. Then, copy the contents of the lcm/hc directory in this patch to the ORCH_LOCATION/fusionapps/applications/lcm/hc directory. Overwrite the contents in this directory.

2.5.12 Copy and Unzip idmUpgrade.zip

There are two different types of IDM upgrades for this release. In the following chapters you will choose your upgrade type and perform the steps and use the patches applicable to that type only. For more information see, IDM for FA Upgrade Roadmap.

To upgrade IDM for FA to Release 12, you must download the following patches:
  • Patch 25734394: This patch contains the idmUpgrade.zip file. It is a common patch used for both type 1 and type 2 IDM upgrade scenarios.

  • Patch 26504255: This patch contains true-up tars and is needed only for the type 2 IDM upgrade scenario.

After you download all the patches listed above, stage the latest idmUpgrade.zip file only if the environment meets all of the following requirements:

  • Runs on a Linux or Solaris platform

  • Supports the Type 1 or Type 2 IDM upgrade

To stage the latest idmUpgrade.zip file, perform the following steps:
  1. Always use the latest version of the idmUpgrade.zip file. This file is available in patch 25734394.

    To use a new version of the idmUpgrade.zip file downloaded from the patch, after having started the upgrade, terminate any running orchestration instances, perform Cancel and Restore steps, and start the upgrade from the beginning.

  2. Unzip idmUpgrade.zip, using the unzip -K option, into SHARED_LOCATION/11.12.x.0.0/.
  3. Create the SHARED_LOCATION/11.12.x.0.0/idmUpgrade/lib directory.
  4. Include SHARED_LOCATION/11.12.x.0.0/idmUpgrade/lib in the LD_LIBRARY_PATH by running the following command on all IDM terminals of IDM hosts before starting orchestration:
    export LD_LIBRARY_PATH= SHARED_LOCATION/11.12.x.0.0/idmUpgrade/lib:$LD_LIBRARY_PATH
    

2.6 Set Up Upgrade Orchestrator

To set up Upgrade Orchestrator, perform the following steps:

2.6.1 Set Up Upgrade Orchestrator on a Shared Location

To set up Upgrade Orchestrator on a shared location, perform the following steps:

  1. Unzip the jython zip file, located in REPOSITORY_LOCATION/installers/fusionapps/Disk1/stage/ext/jlib/ext_jlib_jars/oam, to a temporary location and use the jython jar to execute orchsetup.py in the next step.
  2. Run the orchsetup script on the primordial host. Note that the location for JYTHON_LOC is the temporary location from the previous step and the location of APPLICATIONS_BASE is described in Oracle Fusion Applications Shared Directories.
    (UNIX)
    cd ORCH_LOCATION/bin
    java -cp JYTHON_LOC/jython.jar org.python.util.jython orchsetup.py -r SHARED_LOCATION/11.12.x.0.0/Repository --appbase APPLICATIONS_BASE
    
    
  3. Create a subdirectory to contain setup files for the environment that is being upgraded, define a name for it, in the ORCH_LOCATION/config directory. This location can be configured to be shared across multiple environments that are being upgraded. In this case, this location is referred to as POD_NAME. For example, it is possible to use this location for the test, production, and development environments, if all three environments are being upgraded to Release 12.
    cd ORCH_LOCATION/config
    mkdir POD_NAME
    
    The term Pod is equivalent to environment.
  4. Copy the following template files to the directory that was created in Step 3, without using the template extension, as shown in the following example:
    cd ORCH_LOCATION/config/
    cp MIDTIER.properties.template POD_NAME/MIDTIER.properties
    cp PRIMORDIAL.properties.template POD_NAME/PRIMORDIAL.properties
    cp IDM.properties.template POD_NAME/IDM.properties
    cp OHS.properties.template POD_NAME/OHS.properties
    cp pod.properties.template POD_NAME/pod.properties
    
  5. Copy the silent.rsp.template file to APPLICATIONS_CONFIG/lcm/temp/orchestration/<version>/config/silent.rsp, where <version> is the value of orchestration property FA_TARGET_VERSION as shown in the following example:
    cp silent.rsp /APPTOP/instance/lcm/temp/orchestration/11.12.x.0.0/config/silent.rsp
    

2.6.2 Prepare RUP Lite for OVM

Perform the steps in this section only if Oracle Fusion Applications is being run in an Oracle Virtual Machine (VM) environment that was created from official releases of Oracle VM templates for Oracle Fusion Applications Release 12 (11.12.x.0.0) and higher. This content is not applicable for any Oracle VM environments that are created using other methods.

  • To determine if the Oracle VM environment was created from official releases of Oracle VM templates for Oracle Fusion Applications Release 2 and higher, verify if the /assemblybuilder directory is present in the Oracle VM environment. This confirms that the environment is an OVAB.

  • To confirm the release version, review the .labelinfo.txt and .misclabels.txt files in the u01/APPLTOP/ovabext directory to check the rehydration labels that correlate to the release version. Also check if there is a /u01/ovmext directory to determine if it is an Oracle VM IDM instance.

To install the Oracle Fusion Applications 11.12.x.0.0 Lifecycle Management Tools for Oracle VM Installer repository on the Oracle VM hosts, perform the following steps:

This repository includes RUP Lite for OVM.

  1. Two patches deliver solutions to issues that are identified post release. If content is not found under the following patches associated with the high watermark release (11.12.x.0.0) being upgraded to, no new version has been released yet:
    • Patch 23012885 delivers the latest post release version of the fasaaslcmtools.zip file on My Oracle Support. If no content exists in this patch, use the fasaaslcmtools.zip file that is delivered in the Release 11.12.x.0.0 OVAB_HOME.

    • Patch 23012889 delivers the latest post release version of the fasaasstagedtools.zip file on My Oracle Support. The patch contains fasaasstagedtools.zip, readme.txt, validate.py, and validate.label. If no content exists in this patch, use the fasaasstagedtools.zip file that is delivered in the Release 11.12.x.0.0 OVAB_HOME.

    OVAB_HOME is the top-level directory for the Oracle Virtual Assembly Builder that contains all software needed to deploy Oracle Fusion Applications as an Oracle VM instance.

  2. Unzip fasaaslcmtools.zip to a temporary location, which creates the fasaaslcmtools/Disk1 directory. Then unzip fasaasstagedtools.zip to the fasaaslcmtools/Disk1 directory, which creates the fasaaslcmtools/Disk1/preupg directory. Specify the temporary_location/fasaaslcmtools location in the REL12_SAAS_LCM_INSTALLER_DIR property in the pod.properties file. See Update Orchestrator Properties Files.
  3. Copy the entire contents of the temporary_location/fasaaslcmtools/Disk1/preupg/rupliteovm directory to SHARED_LOCATION/ORCH_LOCATION/config/POD_NAME/11.12.x.0.0/rupliteovm.
  4. Run validate.py, from the location where the patch was downloaded in step 1, to ensure that the correct fasaaslcmtools is used for the upgrade, using the following command syntax:
    validate.py fasaaslcmtools_SHIPHOME_LOCATION
    

    The value for SHIPHOME_LOCATION is the value for the REL12_SAAS_LCM_INSTALLER_DIR property from Step 2. If the script finishes with errors, confirm that the command and the argument passed to it are correct. If both values are correct, contact Oracle Support for further assistance.

  5. Verify that the env.properties file under the SHARED_LOCATION/ORCH_LOCATION/config/POD_NAME/11.12.x.0.0/rupliteovm/metadata directory contains the required property values for the following plug-ins:
    • AddBIUsageTrackerDBHost (runs in pre-root mode)

      ovm.plugin.AddBIUsageTrackerDBHost.enabled=true
      
    • AddOHSScaleoutHAToEtcHosts (runs in pre-root mode)

      ovm.plugin.AddOHSScaleoutHAToEtcHosts.enabled=true
      ovm.plugin.AddOHSScaleoutHAToEtcHosts.ohs_mapping_directory=
      ovm.plugin.AddOHSScaleoutHAToEtcHosts.standby_ohs_mapping_subdirectory=ohs_mapping_files
      
    • GenerateOptimizedQueryPlans (runs in offline mode)

      ovm.plugin.GenerateOptimizedQueryPlans.enabled=true
      
    • DeployECSF (runs in online mode)

      ovm.plugin.DeployECSF.enabled=true
      ovm.plugin.DeployECSF.connection_timeout_seconds=300
      
    • FixBaseOHSInEtcHosts (runs in post-root mode)

      ovm.plugin.FixBaseOHSInEtcHosts.enabled=true
      ovm.plugin.FixBaseOHSInEtcHosts.ohs_mapping_directory=
      ovm.plugin.FixBaseOHSInEtcHosts.standby_ohs_mapping_subdirectory=ohs_mapping_files
      
  6. Confirm that the OVM_STORAGE_MOUNT and APPLTOP properties in the env.properties file are set correctly. For example, OVM_STORAGE_MOUNT=/u01 and APPLTOP=/u01/APPLTOP.

For more information about the plug-ins, see RUP Lite for OVM Utility.

2.6.3 Prepare User Authentication Wallet File

If Oracle Beehive is used in a Windows environment to send email alerts from Upgrade Orchestrator, then there must be a secured SMTP connection, which requires user authentication data. Such data must not be stored in any property file, and it cannot be pre-seeded in a credential store. However, it is possible to use the mkstore command utility to save this required user authentication information in a wallet file. By default, this wallet file is located at ORCH_LOCATION/config/orchfwk/wallet.

To add user authentication data to the wallet file, perform the following steps:

  1. At an operating system prompt on the machine that includes the shared location ORCH_LOCATION/config, enter the following command, replacing sending_email_address@my_company.com and sending_email_password with actual values for the SMTP email account that will send the email notifications:
    orchestration.cmd mkstore -key sending_email_address@my_company.com -value sending_email_password
    

    If the key, (email address), already exists, this command overwrites the existing password with new input. If the key does not exist in the wallet, it appends the new key and value to the existing wallet.

    If this command is entered in a LINUX environment, use single quotes or spaces to enclose any values that include special characters such as the dollar sign ($).

  2. Set the following properties in the ORCH_LOCATION/config/POD_NAME/pod.properties file, substituting appropriate values. To send emails to multiple users, enter a comma-delimited list of email addresses in the EMAIL_TO_RECIPIENT property.
    EMAIL_TO_RECIPIENT=notification_receiving_email_address@my_company.com 
    EMAIL_DEFAULT_ENGINE=java
    EMAIL_PROTOCOL=smtp
    SMTP_AUTHORIZATION=true
    SMTP_HOSTNAME=your_SMTP_host_name
    SMTP_PORT_NUMBER=your_SMTP_port_number
    SMTP_SOCKETFACTORY_CLASS=javax.net.ssl.SSLSocketFactory
    SMTP_AUTH_USER=sending_email_address@my_company.com
    SMTP_AUTH_PASSWORD=
    

    Make sure that the SMTP_AUTH_PASSWORD line of the pod.properties file does not specify a password. Instead, the password value is automatically retrieved from the encrypted wallet file.

2.6.4 Update Orchestrator Properties Files

To update properties files, perform the following step:

If any property file values are updated while orchestration is running, the new values do not take effect until a new orchestration session is restarted.
  • Update the properties files which are located in the ORCH_LOCATION/config/POD_NAME directory. If a property is not relevant for the environment, leave it empty, but do not remove the property. For a detailed list of properties, see Upgrade Orchestrator Properties Files.

2.6.5 Create an Override File for RUP Installer

Perform the following steps to create an override file that will be referenced by the REL12_RUPINSTALLER_UPGRADE_PARAM property during the upgrade. This step is not applicable for Oracle VM environments.

  1. Create an override file, which can be located in SHARED_LOCATION. In this example, the file name is override.properties. It is possible to use a different name for the override file in the environment.

  2. The override file contains the following properties:

    • The VIRTUAL_HOST_MODE property must be set to one of three values: IP, Name, or Port. To determine which property value to use, perform the following steps:

      1. Open WEBTIER_INSTANCE_HOME/config/OHS/ohs1/moduleconf/FusionVirtualHost_fs.conf. An example of WEBTIER_INSTANCE_HOME is APPTOP/instance/CommonDomain_webtier.

      2. If the FusionVirtualHost_fs.conf file contains the string, NameVirtualHost, use VIRTUAL_HOST_MODE=NAME in the override file.

      3. If more than one host exist in FusionVirtualHost_fs.conf for the VirtualHost directive, use VIRTUAL_HOST_MODE=IP in the override file.

      4. Otherwise, use VIRTUAL_HOST_MODE=Port.

    • Set the user base dn and group base dn to configure Application Security Console (ASE). The default values are set as follows:

      1. user.create.bases= cn=Users,dc=us,dc=oracle,dc=com 

      2. group.create.bases= cn=FusionGroups,cn=Groups,dc=us,dc=oracle,dc=com 

      If the default value are used, there is no need to set them in overriding properties file. Otherwise, set these two properties accordingly to be consistent with the actual LDAP Identity Store setup.

    • The REFERENCE_ROLES_FILES property contains a list of the offerings that were selected to be provisioned in the environment. It is possible to obtain this list from the APPLICATIONS_CONFIG/fapatch/FUSION_env.properties file, using only the offerings that also have an entry set to TRUE in this properties file.

      The following examples are provided for each pillar:

      overrides-hcm.txt:
      VIRTUAL_HOST_MODE=Name
      REFERENCE_ROLES_FILES=PER_CORE,PER_WKF_DEPL,PER_WKF_DEV
      
      overrides-fscm.txt:
      VIRTUAL_HOST_MODE=Name
      REFERENCE_ROLES_FILES=XLE_FINANCIALS_JUR,PO_PROCUREMENT,PJF_PROJ_MNG,PIM_PROD_MNG,DOO_ORCHESTRATION,INV_LOGISTICS,FOS_SCM_FIN_ORCHESTRATION
      
      overrides-crm.txt
      VIRTUAL_HOST_MODE=Name
      REFERENCE_ROLES_FILES=MKT_MARKETING,ZBS_SALES,CMP_OIC_BU
      
    • Perform the following step if Load Balancer (LBR) is enabled:

      To create the wiring for the OHS configuration that is used by the Product Management application in the SCM domain, create the following properties. These properties must contain the values for the host and port of the custom LBR external endpoints:

      • PROCUREMENTDOMAIN.SUPPLIERPORTALAPP.LBR_HOSTNAME

      • PROCUREMENTDOMAIN.SUPPLIERPORTALAPP.LBR_PORT

      The OHS.properties file contains two related properties that must be populated for both the LBR enabled and LBR disabled scenarios: SUPPLIER_PORTAL_VIRTUAL_HOSTNAME and SUPPLIER_PORTAL_VIRTUAL_PORT. For a scaled out scenario, multiple properties exist, prefixed with the OHS_INSTANCE_ID:

      • ohs1_SUPPLIER_PORTAL_VIRTUAL_HOSTNAME

      • ohs1_SUPPLIER_PORTAL_VIRTUAL_PORT

      • ohs2_SUPPLIER_PORTAL_VIRTUAL_HOSTNAME

      • ohs2_SUPPLIER_PORTAL_VIRTUAL_PORT

  3. Update the REL12_RUPINSTALLER_UPGRADE_PARAM property in the pod.properties file to add the following value:
    -DrupOverride=SHARED_LOCATION/override.properties
    

2.6.6 Prepare Incremental Provisioning

To determine if Upgrade Orchestrator needs to run incremental provisioning, review the following list of requirements:

Incremental Provisioning Requirements for Oracle VM Environments

Review the following steps if an Oracle Virtual Machine (VM) Environment is used:

  • Review the offerings in the applicable OVM template for your environment in Overview in the Oracle Fusion Applications Installing and Managing in an Oracle VM Environment.

  • If the environment contains all of the offerings available in the template, there is no need to run Incremental Provisioning.

  • If the environment does not contain all of the offerings available in the template, run Incremental Provisioning to add offerings so that the environment matches the OVM template.

Incremental Provisioning Requirements for non-Oracle VM Environments

Review the following steps if a non-Oracle Virtual Machine (VM) Environment is used:

  • Review all offerings in Oracle Fusion Applications Product Families and Product Offerings in the Oracle Fusion Applications Installation Guide and compare them with your current installed offerings.
    • If offerings need to be added from the list of offerings for your business needs, then run Incremental Provisioning to add these offerings. If the environment has at least one SCM offering or the Procurement offering, select all mandatory SCM offerings in Incremental Provisioning.

    • If the environment has all of the offerings needed, then consider the following questions and refer to the table below to determine what to do next:

      • If the environment has no SCM offerings, then there is no need to run Incremental Provisioning.

      • If the environment has at least one SCM offering or the procurement offering, then the environment must have all mandatory SCM offerings from all releases. If the environment does not meet this requirement, then run Incremental Provisioning.

Table 2-4 Mandatory Offerings

Condition Mandatory Offering(s) What to do Comments
The environment contains at least one SCM offering or the Procurement offering Choose one of the following:
  • Recommended: Add “Manufacturing and Supply Chain Materials Management” offering to the environment.

  • Alternative: Ensure the environment has “Material Management and Logistics” and “Supply Chain Financial Orchestration” offerings.

Log in to Fusion Applications. Go to Setup and Maintenance to review the list of provisioned offerings. If the environment does not have the mandatory offering(s), then run Incremental Provisioning to add the offering(s). The Supply Chain Financial Orchestration offering was first introduced in Release 9.

“Manufacturing and Supply Chain Materials Management” was first introduced in Release 12 which supersedes “Material Management and Logistics” and “Supply Chain Financial Orchestration” offerings.

All other conditions No mandatory offering is required. There is no need to run Incremental Provisioning to add mandatory provisioning offerings. If provisioning offerings need to be added for your business needs, then run Incremental Provisioning to add these offerings. No additional comments.

For more information, see the Extend an Oracle Fusion Applications Environment Using Incremental Provisioning During Upgrade section in the Oracle Fusion Applications Installation Guide.

To prepare for incremental provisioning, perform the following steps:

  1. Set the PERFORM_INCREMENTAL_PROVISIONING property to true in the pod.properties file. If there is a plan to run incremental provisioning but this property was not set to true, then Upgrade Orchestrator skips the pause point and there will not be an opportunity to run incremental provisioning. For more information about setting the property, see pod.properties.
  2. If the environment does not already have any one of the Oracle Sales, Oracle Marketing, or Oracle Financials offerings, and you plan to add at least one of them through incremental provisioning, then confirm that the true-type fonts are installed at /usr/share/X11/fonts/TTF. If the true-type fonts are missing, install them before proceeding to the next step.

2.6.7 Validate Repository

After staging is done, ensure that the repository is valid by executing the following script as an Oracle user:

$ cd SHARED_LOCATION/11.12.x.0.0/Repository/installers 
$ ./validate_repo.sh repository_manifest.xml
If the repository is valid, the check returns the following message:
Repository integrity check completed successfully.
Solaris Only
The following output messages are expected for Solaris platforms:
./installers/biappsshiphome/patch/25499241/files/bifoundation/server/bin/libmemhook64.so does not exists in the repository 
./installers/oracle_common/patch/25217940/etc/config/.nfsA6D7 does not exists in the repository 
Total resource entries in the manifest file: 71711, missing resource entries: 2 
This repository is corrupt because of some missing files
If you see these messages on the validate_repo.sh output, ignore them and proceed.

2.7 Other Steps to Perform Before Downtime

Ensure that the following steps are performed before downtime:

2.7.1 Clean Up Old Patch Storage Directories

Patching, at the prior release level, leaves behind significant amount of content in internal patch storage directories and slows down upgrades. This content should be cleaned up prior to upgrade by performing the following steps:

  1. Download the patch 25147788 from My Oracle Support.

  2. Unzip the patch zip file (p25147788_111000_Generic.zip) to a temporary directory as follows:
    $ unzip -d /scratch/tmp/ p25147788_111000_Generic.zip
    
  3. Change your current directory to the unzipped directory as follows:
    $ cd /scratch/tmp/25147788
    
  4. Set the JAVA_HOME environment variable to the JDK installation location.

  5. Execute the patchStorageCleanup.sh script as follows:
    $ ./patchStorageCleanup.sh
    
    If the MW_HOME or OracleHome are not in default locations, then launch the script in one of the following ways:
    • ./patchStorageCleanup.sh -mwHome <Path to MiddleWareHome(s) to be cleaned up in comma separated fashion>
      
      For example:
      ./patchStorageCleanup.sh -mwHome /opt/mwh1,/opt/mwh2
      
    • ./patchStorageCleanup.sh -oh <Path to Oracle Home(s) to be cleaned up in comma separated fashion>
      
      For example:
      ./patchStorageCleanup.sh -oh /opt/oh1,/opt/oh2
      
    • ./patchStorageCleanup.sh -oh <Path to Oracle Home(s) to be cleaned up in comma separated fashion> -mwHome <Path to MiddleWareHome(s) to be cleaned up in comma separated fashion>  
      
    •  ./patchStorageCleanup.sh -mwHome <Path to MiddleWareHome(s) to be cleaned up in comma separated fashion> -oh <Path to Oracle Home(s) to be cleaned up in comma separated fashion>
      
      For example:
      ./patchStorageCleanup.sh -mwHome /slot/ems1234/appmgr/APPTOP/fusionapps
      
    The script scans can be found at the following default locations:
    • /u01/IDMTOP/products/app

    • /u01/IDMTOP/products/dir

    • /u01/IDMTOP/products/ohs

    • /u01/APPTOP/fusionapps

    • /u01/APPTOP/webtier_mwhome

    • /u01/APPLTOP/fusionapps

    • /u01/APPLTOP/webtier_mwhome

  6. Check the log files created under the 'logs' directory for details about the cleanup.

  7. Repeat steps 1 through 6 as listed on this section on the FA Admin, FA OHS, Auth OHS, and one of the IDM hosts (OIM/OID) to clean up old patch content.

2.7.2 Update the Node Manager Password in a Cloned Environment

The upgrade process does not expect the Node Manager password to be different from the keystore password. This difference in passwords causes a failure during the upgrade, which includes the following error message:

ERROR KEYSTORE WAS TAMPERED WITH, OR PASS...

To prevent this issue, confirm that the Node Manager password is the same as the keystore password before starting the upgrade. Use the Administration Console to change the values for the Node Manager password and properties.

If a cloned instance is being upgraded, change the Node Manager password back to the original password that is used by the Node Manager in the source environment for the clone. After the upgrade, it is possible to change the password back to what it was in the cloned environment after the clone was complete.

2.8 Verify Environment Before Proceeding to Downtime

Perform the following steps to verify the environment before proceeding to downtime steps:

2.8.1 Confirm Database Settings

Refer to the latest Technical Known Issues to verify that the database and Sql*Net tuning parameters are set properly to avoid timeout errors during the upgrade.

2.8.2 Confirm JDeveloper Customizations Can Be Merged

If JDeveloper customizations to a SOA composite were performed, and then the composite to the SOA runtime was deployed, perform manual steps to merge the customizations during the upgrade. To ensure that the customizations can be merged successfully, review the recommendations in About Merging Runtime Customizations from a Previously Deployed Revision into a New Revision in the Oracle Fusion Applications Extensibility Guide for Developers before starting Upgrade Orchestrator.

Merge the customizations after the SOA Preverification configuration assistant fails during the upgrade. See Merge SOA Composite JDeveloper Customizations During SOA Preverification.

2.8.3 Maintain Versions of Customized BI Publisher Reports

Ensure that you have your own versions of any customized BI Publisher reports. If an upgrade includes an update to a catalog object that was delivered with an Oracle Fusion application, the patch overwrites any customizations applied to the original report. For more information on customizing business intelligence, see the Creating and Editing Analytics and Reports guides relevant to your products.

2.8.4 Remove Distributed Order Orchestration Customizations (DOO)

If Extended Flexfields is being used and the DOO SOA composites have been customized for mapping between EBO and DOO SDO, it is possible to remove these customizations before upgrading to Release 12 and use the new automap feature. See Preserve SOA Composite JDeveloper Customizations Before Apply a Patch in the Oracle Fusion Applications Patching Guide.

For more information about the automap feature in Release 12 that allows you to avoid using SOA composite customizations by setting up Oracle Fusion Distributed Order Orchestration Extensible Flexfields, see the Oracle Fusion Applications Order Orchestration Implementation Guide.

2.8.5 Verify the FUSION User Quota on FUSION_TS* Tablespaces

The FUSION user must have an unlimited quota on all FUSION_TS* tablespaces. To verify that the FUSION user has an unlimited quota on all FUSION_TS* tablespaces, run the following query:

select tablespace_name, max_bytes from dba_ts_quotas where username = 'FUSION';

The FUSION user must have a value of -1 for max_bytes on all FUSION_TS* tablespaces. If any tablespace does not have the correct value or does not have an entry, grant the unlimited quota by running the following command:

alter user FUSION quota unlimited on tablespace_name; 

2.8.6 Validate Domain Directories

Run the validatedomains script to confirm that all Administration Server domain locations are detectable. If the steps to scale out hosts were followed, the Administration Server of the scaled out host may have been added to a new machine. This section provides the steps to temporarily add the Administration Server back to the originally provisioned machine so that all domain directories can be found by Upgrade Orchestrator. During post-upgrade steps, the Administration Server is added back to the machine that was created during scaleout.

Whether the hosts have been scaled out or not, perform the following steps to run the validation for domain locations and to temporarily update the machine for Administration Servers, if needed:

  1. Unzip domainvalidate.zip from the SHARED_LOCATION/11.12.x.0.0/Repository/installers/farup/Disk1/upgrade/validate directory into any directory on the primordial host.

    1. Update the path with the correct location of JDK by placing the JDK apptop in front of the path so that java runs from it as follows:

      (UNIX)
      PATH=$1/jdk6/bin:$1/fusionapps/jdk6/bin:$PATH
      export PATH 
      
    2. If FA_MW_HOME is APPLICATIONS_BASE/fusionapps, run the following command:

      (UNIX)
      ./validatedomains.sh APPLICATIONS_BASE
      
      

      For example:

      validatedomains.sh /u01/APPLTOP
      
    3. If APPLICATIONS_CONFIG is APPLICATIONS_BASE/instance, run the following command:

      (UNIX) ./validatedomains.sh FA_MW_HOME APPLICATIONS_CONFIG
      
      

      For example:

      validatedomains.sh /u01/APPLTOP/fusionapps /u01/APPLTOP/instance
      
  2. If validatedomains.sh reports any domains that failed the validation, and there are no scaled out hosts, skip to Step 3.

    If validatedomains.sh reports any domains that failed the validation, and if there scaled out hosts, perform the following steps on the Administration Server of each of the reported domains:

    1. Log in to the WebLogic console for the domain.

    2. Navigate to Environment, then Machines.

    3. Find the machine that corresponds to the host name for which the Administration Server was initially provisioned.

    4. Click on the machine and go to the Servers tab. Note that the Administration Server should not appear on the list of servers. If it does appear on the list, either this domain passed validation or this is not the originally provisioned machine for the Administration Server.

    5. Click Lock & Edit to make changes.

    6. Click Add.

    7. Select the AdminServer and click Finish.

    8. Click Activate Changes to apply the changes.

    9. Skip Step 3 of this procedure.

  3. If validatedomains.sh reports any domains that failed the validation, and if there are no scaled out hosts, perform the following steps:

    1. Download the patch 18062458 to a local directory.

    2. Run the extracted command against each domain directory under APPLICATIONS_CONFIG as follows:

      For Unix:
      FA_MW_HOME/oracle_common/common/bin/wlst.sh fixadminconfig.wlst APPLICATIONS_CONFIG/domains/<HOST>/<DOMAIN NAME>
      
    3. Run the validatedomains script again, to ensure that all Administration Server domain locations are detectable.

2.8.7 Verify the Node Manager Configuration is Correct

Perform the following steps on the admin-apps/PRIMORDIAL host and all Midtier hosts to verify that the node manager configuration is correct.

  1. Review the config/config.xml file in each domain directory and check the MACHINE_NAME entries. Ensure that for each machine entry, the node-manager child element has its own name element that matches the name element of the machine. Refer to the following example:

    <machine>
      <name>MACHINE_NAME</name>
      <node-manager>
        <name>MACHINE_NAME</name>
        ...
      </node-manager>
    </machine>
    
  2. If any of the node-manager elements are missing child name elements, then the configuration must be fixed by using the offline WebLogic Scripting Tool (WLST) command as described in the following steps:

    1. Run the WLST command to fix the configuration in each domain directory as follows:

      FMW_ORACLE_HOME/oracle_common/common/bin/wlst.sh
      
    2. Open the domain in offline mode as follows:

      readDomain('PATH_TO­_DOMAIN')
      
    3. Run the following commands for each impacted machine:

      cd('/Machine/MACHINE_NAME/NodeManager/MACHINE_NAME')
      set('Name', 'MACHINE_NAME') 
      
    4. Save the domain and exit WLST as shown in the following example:

      updateDomain()
      closeDomain()
      exit()
      
  3. Review the config.xml file for each of the impacted domain directories and ensure that the name elements are now present.

2.8.8 Verify the SSL Configuration is Correct

To verify that the node manager configuration is correct, perform the following steps on the admin-apps/PRIMORDIAL host and all Midtier hosts:

  1. Review the config/config.xml file in each domain directory and check the server entries. Ensure that for each server entry, the SSL child element has its own name element that matches the name element of the machine. Refer to the following example:

    <server>
    <name>SERVER_NAME</name>
    <ssl>
    <name>SERVER_NAME</name>
    ...
    </ssl>
    </server>
    
  2. If any of the ssl elements are missing child name elements, then the configuration must be fixed by using the offline WLST command as described in the following steps:

    1. Run the WLST command to fix the configuration in each domain directory:

      FMW_ORACLE_HOME/oracle_common/common/bin/wlst.sh
      
    2. Open the domain in offline mode:

      readDomain('PATH_TO­_DOMAIN')
      
    3. Run the following commands for each impacted machine:

      cd('/Server/SERVER_NAME/SSL/SERVER_NAME')
      set('Name', 'SERVER_NAME')
      
    4. Save the domain and exit WLST:

      updateDomain()
      closeDomain()
      exit()
      
  3. Review the config.xml file for each of the impacted domain directories and ensure that the name elements are now present.

2.8.9 Verify the Default Realm Name is myrealm

Upgrade Orchestrator expects the default realm name to be myrealm for the Common Domain. Changing the name to anything other than myrealm causes Upgrade Orchestrator to fail. To verify that this value has not been changed to any other name, perform the following steps :

  1. Log in to the WLS Console for the Common Domain.
  2. Click Security Realms on the domain structure pane.
  3. A list of realms displays in the Summary of Security Realms window.
  4. Verify there is an entry for myrealm and that "true" displays in the Default Realm column.

2.8.10 Verify Removal of Manual Updates to FusionVirtualHost*.conf on OHS Host

Any manual updates, such as the addition of headers, to the virtual host configuration files on the OHS hosts must be removed. The file names impacted by this step are in the following format:
FusionVirtualHost*.conf

2.8.11 Verify Version of /bin/bash on All Hosts (Unix Platforms)

Upgrade Orchestrator uses "Bash" as the default shell on Unix platforms. Ensure that the /bin/bash shell version 3.2 or higher is installed on all hosts.