This section includes the following topics:
In the response file that is created, the configuration details necessary to run a physical installation of Oracle Fusion Applications product offerings are specified. For full-scale environments, typically the offerings must be provisioned on multiple hosts, and the installation must be run from a shared drive that is accessible to all hosts.
The installation process is run in phases, in an assigned order. Complete each phase, in order, on each host, before moving to the next phase. All phases must be completed successfully on all the hosts in the environment to create a fully operational applications environment.
If a failure is encountered with any of the provisioning phases, see Troubleshoot an Oracle Fusion Applications Environment, for information about how to recover from failure, by automatically completing the cleanup phase on all provisioning hosts, followed by the restore phase on all provisioning hosts.
After the cleanup and restore phases are complete without failure on all provisioning hosts, rerun the provisioning phase on the provisioning hosts that failed previously, then continue with the remaining provisioning phases. Do not rerun the provisioning phase on the provisioning hosts that were successful.
Provisioning provides scripts that read from the response file and take action for each installation phase (target). As each phase is run, its progress is tracked on a related screen in the Provisioning Wizard user interface.
Run the Provisioning Wizard on the primordial host to create a provisioning response file. If the Provisioning Wizard is run on a non-primordial host to create a provisioning response file, the validation assumes that the host is the primordial host. Ensure that the validation errors are interpreted correctly as they may not be applicable to the non-primordial host.
When provisioning a new environment, the Provisioning Wizard should only be run on the primordial host and the Provisioning Command-Line Interface on non-primordial hosts.
Installation phases and the names of the tracking screens are as follows:
Preverify: Checks to see that all prerequisites are present. Tracked on the Prerequisite Checks screen.
Install: Installs applications, middleware, and database components. Creates the applications Oracle home directory. Tracked on the Installation screen.
The database schema owner password complexity check is run at the end of the Install phase. See Database Schema User Password Complexity Rule.
Preconfigure: Prepares application and middleware components for deployment and creates appid users and groups. Modifies the Oracle Application Development Framework (Oracle ADF) configuration file in the applications enterprise archive (EAR) files to use the database as the Oracle Metadata Services (MDS) Repository. Also updates the connections.xml file in all applications EAR files with endpoint information. Tracked on the Preconfigure screen.
Configure: Creates and configures Oracle WebLogic Server domains, Managed Servers, and clusters; applies templates; creates and configures data sources, queues, and topics; configures middleware (wiring); and deploys applications product offerings to domains. Tracked on the Configure screen.
Configure-secondary: Performs the configure actions on a primary or secondary host or both. If there is no primary or secondary host, or if there is only a primary host, this phase runs, but takes no action. Tracked on the Configure Primary/Secondary screen.
Postconfigure: Performs online tasks, such as configuring the Node Manager, deploying the service-oriented architecture (Oracle SOA Suite) composite, establishing Oracle HTTP Server wiring, seeding policies, and setting up postdeployment security configuration. Tracked on the Postconfigure screen.
Startup: Starts the Administration Server and Managed Servers for each domain on the host where this phase is running. Tracked on the Startup screen.
Validate: Performs a variety of post-provisioning validations, such as server and application availability, successful loading of identity credentials, and validation of data source. Tracked on the Validation screen.
Actions related to Oracle Identity Management components are performed only in specific phases. See Installation Phase Actions for Oracle Identity Management Components.
If a failure is encountered and the automatic cleanup and restore phases are executed, the cleanup and restore phase runs these tasks automatically:
Cleanup: Shuts down processes started during a failed phase and performs the necessary cleanup actions. If the automated cleanup fails, manually stop all processes except the Node Manager on all hosts including OPMN and Java EE processes before running the restore action. Note, however, all processes must be stopped if the cleanup action is running on the configure phase.
Restore: The necessary restore actions required for a given provisioning phase. This action deletes and restores the instance directory, and, if necessary (and available), restarts the Common domain Administration Server and Oracle HTTP Server.
See Recovery After Failure for more information about cleanup and restore actions.
The number of hosts and their purpose determines the order in which the applications environment is provisioned.
Primordial host: Location of the Common domain (specifically the Administration Server of the Common domain). Only one primordial host exists in each environment.
Primary host: Location where the Administration Server for a domain runs. Only one primary host exists in a domain.
Secondary host: Location where the Managed Servers for any application reside when they are not on the same host as the Administration Server of the same domain. The term, secondary host, is meaningful when a domain spans across more than one physical server. The server(s) that does not have the administration server is(are) called secondary host(s).
DMZ host: A host that cannot access the shared storage within the firewall is said to be in a demilitarized zone (DMZ). Typically used to install Oracle HTTP Server so that restrictions on communication with components within the firewall can be enforced. See Set Up a Demilitarized Zone (DMZ) for the Web Tier.
Run the Provisioning Wizard on the primordial host to create a provisioning response file. If the Provisioning Wizard is run on a non-primordial host to create a provisioning response file, the validation assumes that the host is the primordial host. Ensure that the validation errors are interpreted correctly as they may not be applicable to the non-primordial host.
When provisioning a new environment, the Provisioning Wizard should only be run on the primordial host and the Provisioning Command-Line Interface on non-primordial hosts.
Before beginning the physical installation, ensure that the following tasks have been completed:
All setup details as described in Prepare for an Installation
All installation tasks associated with the transaction database as described in Install Oracle Fusion Applications Transaction Database
A response file with the required configuration details as described in Create a Response File
For Solaris 11 Only
Ensure that the Solaris Package SUNWttf-bh-luxi is installed on the FA servers. Do this for both Oracle Solaris on SPARC (64-bit) and Oracle Solaris on x86-64 (64-bit) platforms.
For Solaris 11.3, ensure that the OS level packages installed are of version 11.3.3.6.0 or higher.
To provision a new environment, start the Provisioning Wizard on the primordial host, make a selection from the options menu, and indicate the location of the response file. The wizard presents a review of the details in the response file on a series of interview screens.
Changes can be made to most of the response file details on the interview screens. However, changes cannot be made to the product offerings. A new response file must be created to change the offering mix.
After completing the preverify phase successfully on all the hosts in the environment, and clicking Next to start the install phase on the primordial host, it is not longer possible to modify any sections of the response file.
Run the phases in order, and complete each phase on all hosts in the environment before beginning the next phase. The Provisioning Wizard enables to monitor the progress and success of each phase across all hosts.
If a separate DMZ host is setup for the web tier, open a separate terminal session for that host and run all provisioning phases (except the preverify phase). To ignore preverify phase errors, use the command line argument -ignoreSysPrereqs true in the runProvisioning command. It is not possible to view the build processes on the DMZ host on the primordial host interface because the DMZ host does not have access to the shared network drive.
For example, if there are three hosts — Host A (primordial host), Host B (primary host) and Host C (secondary host) — the process of provisioning those hosts works like this:
A full backup of the provisioning and configuration state is performed automatically at the end of each successfully completed phase. The backup is saved in APPLICATIONS_BASE/restart/.
To provision an environment, start the Provisioning Wizard and page through the installation screens to initiate each phase and monitor the build processes. Note that Oracle Fusion Middleware Oracle homes and Oracle Fusion Applications Oracle home are read-only, and customers are not expected to update or install any components manually to these home directories. These home directories can be updated only by Oracle Fusion Applications lifecycle tools, such as Provisioning, RUP Installer, and Patch Manager.
WARNING: If any warnings were ignored during the creation of the response file, fix all issues stated in the warnings before successfully provisioning an environment. Make those changes in this installation interview. The wizard saves the changes to the original response file and proceeds with the new instructions. All validations must pass before running the install phase.
Ensure that the inventory pointer file (oraInst.loc) was created when the provisioning framework was installed. If the file was created in /etc, ignore the -invPtrLoc command line argument. If the file was created in another location, add the -invPtrLoc argument to the command line syntax and indicate the location of the inventory. See Use the Command-Line Interface for Installations on the Primary and Secondary Hosts.
To start provisioning the new environment:
MANDATORY: Steps 3 to 6 must be applied on the primordial host and also on all other provisioning hosts specified in the provisioning response file.
In UNIX, by default, the provisioning framework uses the directory specified in the environment variable $PROVTMP, as the location to write temporary files during provisioning. If it is not defined then the value specified in the following environment variables is used: $TMPDIR, $TMP, $TEMP. If none of these is set, then /tmp is used.
To change the temporary location, set the $PROVTMP environment variable before starting the Provisioning Wizard and provisioning command line.
Table 13-1 illustrates the steps required to provision a new environment on multiple hosts. Notice that after running the first phase (preverify) on all hosts, the steps to run the remaining phases are the same. Move to each subsequent phase, in the assigned order.
In the table, UI denotes a step performed in the Provisioning Wizard, and CLI denotes a step performed on the command line.
For help with any of the Provisioning Wizard screens, click Help.
When the Provisioning Wizard is run to provision an applications environment and any issue occurs during provisioning, the error and warning messages are displayed at the bottom of the screen.
Table 13-1 Provisioning a New Applications Environment
| Interface (UI or CLI) | Action Required |
|---|---|
|
UI: Welcome Screen |
No action is required on this read-only screen. Click Next to continue. |
|
UI: Specify Central Inventory Location |
This screen displays only if one or more of the following conditions are not met:
Specify the location of the Central Inventory Directory that meets the previous criteria. The For non-Windows platforms, in the Operating System Group ID field, select or enter the group whose members are granted access to the inventory directory. All members of this group can install products on this host. Click OK to continue. The Inventory Location Confirmation dialog prompts to run the To continue the installation without root access, select Continue installation with local inventory. Click OK to proceed with the installation. For information about setting the Inventory Directory, see oraInventory Planning. Note that the directory specified for For more information about inventory location files, see Oracle Universal Installer Inventory in the Oracle Universal Installer User's Guide. Click Next to continue. |
|
UI: Installation Options Screen |
Presents the list of valid installation options that can be performed using the provisioning wizard. Select Provision an Applications Environment. Enter the path in the Response File field to the response file to be used to provision the environment. Or click Browse to navigate to the response file location. Click Next to continue. |
|
UI: Response File Description Screen |
This is the information entered when the response file was initially created. It is not associated in any way with the executable plan file, or the summary file, that is saved when this response file was initially created. It is possible to change the response file name, version, and description before provisioning is run.
Click Next to continue. |
|
UI: Installation Location Screen |
Displays the credentials for the Node Manager and the directory locations entered in the response file. If these values have changed, make corrections on this screen. See Installation Location Details . Click Next to continue. |
|
UI: Review Provisioning Configuration Screen |
Lists the wizard interview screens where the domain-specific parameters were originally specified for this response file. Changes can be made to this information if necessary. Note: If any warnings are ignored during the creation of this response file, all issues stated in the warnings must be fixed before successfully provisioning an environment. Select any of the screens displayed here to make changes for a product domains with warnings. All validations must pass before running the install phase. Product offerings cannot be added or deleted to this response file. To change product offerings, create a new response file. Select one or more options from the list. After clicking Next, the screens selected are added to the flow. Note that in case of returning to this screen after running the preverification checks, those verification checks are invalidated. Thus, run the Preverify phase again. Click Next to continue. |
|
UI: Summary Screen |
Review the information displayed to ensure that the installation details are correct. To make changes, click Back to return to previous screens in the interview. Click Next to initiate the preverify phase. The wizard displays the Prerequisite Checks screen, and creates a current copy of this response file. The response file is saved in the directory indicated in the message pane. Click Next to continue. |
|
UI: Prerequisite Checks Screen |
The preverify phase performs prerequisite checks for Oracle Fusion Applications provisioning on the primordial host. The host is marked with a Home symbol in the Host column. The Domains column lists the domains that are being deployed. After this phase has been inititated on the primary and secondary hosts (from the command line), the build processes for those hosts are also shown. The Status column indicates the progress of each phase for each host:
Click an x or a Restricted symbol to display messages about failures. Click the host-level Log file for details about this phase. Click a build Log file to see details specific to that build. Changes can be made to the interview screens and rerun the preverify phase as many times as is necessary. Note that when changes to the response file are made and preverify is rerun, Oracle Fusion Applications Provisioning requires that the application configuration directory be empty. Click Retry to rerun this phase if errors are reported. Fix all errors before continuing. See Troubleshooting Preverify Phase Errors. |
|
CLI and UI: Run the preverify phase on primary and secondary hosts from the command line and monitor progress in the UI. |
In the terminal session for the primary and secondary host, run the preverify phase with this command: UNIX: Note: The same provisioning phases can be run in parallel on all hosts simultaneously if the provisioning process has been started in the primordial host first. However, each new provisioning phase must be run in the specific order listed in Installation Phases and Types of Hosts in a Multiple-Host Environment. Thus, a new phase cannot be started until the previous phase has been completed successfully on all the hosts. Monitor the progress of the preverify phase using the Prerequisite Checks screen on the primordial host. Click Retry to rerun this phase if errors are reported. See Troubleshoot Preverify Phase Errors. When this phase is complete with no errors on all hosts, click Next. The wizard starts the install phase on the primordial host and displays the Installation screen. When the preverify phase is successful on the primordial host, place a copy of the response file and the generated provisioning plan (APPLICATIONS_BASE Note: If an incremental provisioning is performed, see Extend an Oracle Fusion Applications Environment Using Incremental Provisioning During Upgrade. If the webtier is placed in DMZ, then in addition of copying the generated Note: After clickingNext, the response file cannot longer be modified. |
|
UI: Installation Screen |
Displays the progress of the install phase on the primordial host. Build messages and Log icons track the progress for all phases in the same manner as described for the preverify phase. |
|
CLI and UI: Run the install phase on the primary, secondary, and DMZ (if present) hosts and monitor the progress in the UI. |
In the terminal session, run the install phase on the primary, secondary, and the DMZ host (if present) with this command: UNIX: Monitor the progress on the Installation screen on the primordial host. |
|
CLI and UI: Copy the |
After the install phase is complete, copy the Click Next to initiate the preconfigure phase on the primordial host. The wizard displays the Preconfigure screen. |
|
UI: Preconfigure Screen |
Displays the progress of the preconfigure phase on the primordial host. |
|
CLI and UI: Run the preconfigure phase on the primary, secondary, and DMZ (if present) hosts and monitor the progress in the UI. |
In the terminal session, run the preconfigure phase on the primary, secondary, and the DMZ host (if present) with this command: UNIX: Monitor the progress on the Preconfiguration screen on the primordial host. |
|
UI and CLI: Initiate the remaining phases (in order) on the primordial, primary, secondary, and DMZ (if present) hosts. |
After the preconfigure phase reports a successful completion on each host in the environment, return to the primordial host and click Next to initiate the next phase. As each new phase is started on the primordial host, on the command line, enter the command to run that phase on the primary, secondary, and DMZ host (if present) on the command line. See Table 13-4 for a list of all the phases, and the command-line syntax. The associated screens, in phase order, are as follows:
After the phases are complete with no errors, click Next on the Startup screen to initiate the validate phase and then start this phase on the other hosts. |
|
UI: Validation |
When the validate phase is complete with no errors on all hosts, click Next. |
|
UI: Installation Complete |
This screen displays the configuration of the new environment. Click Finish. The wizard automatically saves a summary file that describes this installation. The file is saved to the response file directory as follows:
|
Note that if a new environment is provisioned on a single host, ignore the steps that run from the command line. Each phase starts automatically on the primordial host when clicking Next.
The wizard displays the Node Manager credentials and the locations of the various directories entered when this response file was created. You can change these values, if necessary.
Node Manager Credentials
User Name: Specify a user name for the Node Manager role.
Password: Specify a password for the Node Manager and retype it in the Confirm Password field.
Provide locations of various directories that the administrator needs access to.
Installation and Configuration
Installers Directory Location: Enter the path to the repository_location directory created when the provisioning repository was downloaded.
Applications Base: Enter the directory path to the Oracle home specified when the provisioning framework was installed. This directory is the Fusion Applications Oracle home. It is the root directory for all Oracle Fusion Applications and Oracle Fusion Middleware products.
The applications base directory must not be set to the system root directory or set to the root directory of a logical drive. Some lifecycle management tools computed directory names by backing up one directory level from the applications base directory and then appending the appropriate subdirectory name. These tools fail if the applications base directory is set to the system root directory or set to the root directory of a logical drive because it is not possible to back up one directory level from the system root directory or from the root directory of a logical drive.
In a UNIX environment, this name cannot exceed 59 characters.
Applications Configuration: This directory is automatically populated based on the value specified in the Applications Base field. This value is the path to the directory where the configuration files for the domain are written.Enable Local Applications Configuration: Select this checkbox to run the Managed Servers from a non-networked (local) disk on the host, visible only to the processes running on that host. If this option is enabled, the wizard copies the domain configuration from the shared location and places it on the local disk you specify. This configures all Managed Servers to run from the non-networked location.
Enable Local Applications Configuration: Select this check box to run the Managed Servers from a non-networked (local) disk on the host, visible only to the processes running on that host. If this option is enabled, the wizard copies the domain configuration from the shared location and places it on the specified local disk. This configures all Managed Servers to run from the non-networked location.
Local Applications Configuration: Specify the location for the local domain directory that is set up. This field is required if the Enable Local Applications Configuration option is selected. The specified directory must be empty.
Middleware Dependencies
Font Directory: Appears only if the Oracle Sales, Oracle Marketing, or Oracle Financials offerings are selected. Enter the directory where the TrueType fonts are installed. The location varies on different operating systems, but is typically found here:
Linux x86-64: /usr/X11R6/lib/X11/fonts/TTF
Oracle Solaris: /usr/X11R6/lib/X11/fonts/TrueType
Some systems may not have TrueType fonts installed. If the fonts cannot be located on the system, verify that they have been installed. In addition, the fonts directory shipped as part of the JRE installed in the repository can be used. Regardless of which path are specified, access to .ttf (.TTF) files is necessary.
Oracle Business Intelligence Repository Password
RPD Password: Specify and Confirm a password to allow access to the metadata repository (RPD) for both Oracle Business Intelligence Applications and Oracle Transactional Business Intelligence. The password must be between 8 and 30 characters and contain at least one digit. It can include letters, numbers, pound sign (#), dollar sign ($), or underscore (_). To include a dollar sign ($) in the RPD password, enter one additional dollar sign ($) as the escape character before the dollar sign ($) in the password. Provisioning sets up this password, but does not actually access the repository.
This checklist is an addition to the automated validation that takes place during the validate phase of Oracle Fusion Applications Provisioning. See Perform Validation Steps in the Oracle Fusion Applications Cloning Administrator's Guide.
The Oracle Fusion Applications Administrator should also perform a final environment validation of the entire stack. Table 13-2 gives a high-level list of such tasks.
Table 13-2 Technical Stack Validation
| Component | Task | Expected Outcome |
|---|---|---|
|
WLS Console (Oracle Identity Management) |
Connect to the WLS Console of the IDMDomain using a browser (point directly at the WLS AdminServer port). |
Connect successfully and check the status of the servers in the domain. |
|
EM Console (Oracle Fusion Applications) |
Connect to the EM Console of each Fusion Applications Domain using a browser (point directly at the WLS AdminServer port). |
Connect successfully and check the status of the Fusion Middleware components (including BI, WebCenter, ESS, SOA) as well all the Fusion Applications managed servers for each domain. |
|
SSO/Home Page (Oracle Fusion Applications) |
Open the Fusion Applications Homepage using a browser (point at the CommonDomain OHS host/port or LBR if the environment has one). |
Redirection to the OAM SSO login screen. After logging in, see the Fusion Applications Homepage and no error messages. If there are error messages, attempt to refresh the page as they may simply be timeouts since this is the first time the page is being accessed. |
|
Functional Setup |
Navigate to Setup and Maintenance page using the Navigator Menu. |
See the Setup and Maintenance page with no error messages. |
|
Scheduled Jobs |
Navigate to the Scheduled Jobs page using the Navigator Menu. * |
See the Scheduled Jobs page with no error messages. |
|
Reports and Analytics |
Navigate to the Reports and Analytics page using the Navigator Menu. * |
See the Reports and Analytics page with no error messages. Click on the folders to display the available reports. |
* If the Scheduled Jobs or Reports and Analytics links do not appear in the Navigator Menu, enable them in Functional Setup:
Navigate to Setup and Maintenance using the Navigator Menu.
Use the Search box to search for the Work Menu. The results are displayed on the right and should include Manage Menu Customizations.
Click on Go to Task (next to Manage Menu Customizations).
Find the Scheduled Jobs or Reports and Analytics menu items on the tree and make sure they are configured as visible/rendered.
A manual backup can be performed, for example, if the automated backup after a phase fails.
Run these commands for each phase, preverify through postconfigure, and for each host in the environment.
For Linux x86-64:
/bin/tar -C $APPLICATIONS_CONFIG/instance -cf $APPLICATIONS_CONFIG/restart/backup_phase_name/instance.tar
If local configuration is enabled, also run these commands for each host:
/bin/tar -C $LOCAL_CONFIG/domains -cf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/domains/localdomains.tar /bin/tar -C $LOCAL_CONFIG/applications -cf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hosthame/applications/localapplications.tar /bin/tar -C $LOCAL_CONFIG/biinst -cf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/biinst/BIInstance.tar
For Oracle Solaris:
/bin/tar -cEf $APPLICATIONS_CONFIG/restart/backup_phase_name/instance.tar -C $APPLICATIONS_CONFIG/instance
If local configuration is enabled, also run these commands for each host:
/bin/tar -cEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/domains/localdomains.tar -C $LOCAL_CONFIG/domains /bin/tar -cEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/applications/localapplications.tar -C $LOCAL_CONFIG/applications /bin/tar -cEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/biinst/BIInstance.tar -C $LOCAL_CONFIG/biinst
The installation phases on the primary and secondary hosts are run from the command line, using specific arguments to further define the necessary actions.
Table 13-3 shows valid arguments used when running installation phases.
Table 13-3 Command-Line Syntax for Phase Arguments
| Syntax | Description |
|---|---|
|
|
Directory path to the location of the build scripts. This directory is set up when the provisioning framework is installed, for example |
|
|
Provide the location of a previously saved response file. Input is:
|
|
|
Indicates that the script should run a specific installation phase (target). Any |
|
- |
Options: Default: Adding this argument disables validation for database, schema, and hosts, and enables to progress to the install phase without having to fix failure issues. Checks continue to be performed, but failures are ignored. Can be used as an argument with both the If this argument is specified for the preverify phase, specify it for all the remaining phases (install, preconfigure, configure, configure-secondary, postconfigure, startup, and validate). If it is not specified for the remaining phases, a phase guard exception will be raised. |
|
- |
Specifies the location of the Oracle Inventory directory, which is used by the installers to keep track of which Oracle products are installed on a host. For example, the UNIX: |
Note that the -plan argument in previous releases was replaced by the -responseFile argument.
Table 13-4 shows the command-line syntax for running the various installation phases.
In the command syntax, ensure that path_to_script is a local drive and not an UNC path.
Table 13-4 Installation Phase Syntax
| Phase (Target) | Command Syntax |
|---|---|
|
Preverify |
UNIX: |
|
Install |
UNIX: |
|
Preconfigure |
UNIX: |
|
Configure |
UNIX: |
|
Configure-secondary |
UNIX: |
|
Postconfigure |
UNIX: |
|
Startup |
UNIX: |
|
Validate |
UNIX: |
|
Cleanup-phase_name |
UNIX: Substitute phase_name with the appropriate provisioning phase (install, preconfigure, configure, configure-secondary, or postconfigure) to perform a cleanup action. |
|
Restore-phase_name |
UNIX: Note: Substitute phase_name with the appropriate provisioning phase (install, preconfigure, configure, configure-secondary, or postconfigure, startup, validate) to perform a restore action. |
After completeing provisioning a new Oracle Fusion Applications environment, proceed to Troubleshoot Your Oracle Fusion Applications Environment for troubleshooting instructions.