| Oracle® Fusion Applications Installation Guide 11g Release 1 (11.1.1.5) Part Number E16600-02 |
|
|
View PDF |
| Oracle® Fusion Applications Installation Guide 11g Release 1 (11.1.1.5) Part Number E16600-02 |
|
|
View PDF |
This chapter describes in detail the tasks necessary to perform a physical installation, configuration, and deployment of the product offerings that you specified in your provisioning plan. It includes the following sections:
In the provisioning plan that you created, you specified the configuration details necessary to run a physical installation of Oracle Fusion Applications product offerings. 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. You must complete each phase, in order, on each host, before you move to the next phase. All phases must be completed successfully on all the hosts in your environment to create a fully operational applications environment.
The number of hosts and their purpose determines the order in which you provision the applications environment.
Provisioning provides scripts that read from the provisioning plan 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.
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.
Preconfigure: Prepares application and middleware components for deployment and creates appid users and groups. Modifies the Oracle Application Development Framework (ADF) configuration file to use the database, based on Oracle Metadata Services (MDS) in the applications enterprise archive (EAR) files. 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 Secondary screen.
Postconfigure: Performs online tasks, such as configuring the Node Manager, deploying the service-oriented architecture (SOA) 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 you are running this phase. Tracked on the Startup screen.
Validate: Performs a variety of postprovisioning validations, such as server and application availability, successful loading of identity credentials, and validation of data source. Tracked on the Validation screen.
Note:
Actions related to Oracle Identity Management components are performed only in specific phases. See Section 5.1.3 for details.A cleanup and restore phase runs automatically if a failure occurs:
Cleanup: Shuts down processes started during a failed phase and performs the necessary cleanup actions. If the automated cleanup fails, you must manually stop all processes except the Node Manager on all hosts including OPMN and Java EE processes before you can run the restore action. Note, however, that you must stop all processes if you are running the cleanup action 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 Section 5.5.3 for more information about cleanup and restore actions.
During installation, the Provisioning Wizard performs actions that are associated with the Oracle Identity Management components you installed previously. This section contains a summary of those actions, arranged by the installation phase where the action is performed.
Installation phases
The wizard performs the following actions:
Preverify phase
Verifies the existence of the system administrators group (if it was declared as existing during the wizard interview) and the existence of the designated super user in the identity store.
Preconfigure phase
Prepares the Oracle Identity Management components for configuring as follows:
Uploads the LDIF files to the identity store. These files contain entries that represent the application administrator groups used to update the identity store.
Creates the system administrator group (according to what is indicated in the interview).
Makes the super user a member of the administrators group and all the application family directory groups.
Seeds the bootstrap of AppID and gives it membership in the system administrator group.
Configure phase
Configures the Oracle Identity Management components as follows:
Creates the Oracle Fusion Applications domains using the default Oracle WebLogic Server template, with the bootstrap AppID as an administrator.
Disables the default authenticator and enables the LDAP authenticator.
Starts the Oracle WebLogic Server domain using the bootstrap AppID.
Postconfigure phase
Following configuration, the system administrator groups are assigned the appropriate enterprise roles at the product family level. As a result, the super user has:
Administrator privileges for all Oracle WebLogic Server domains and all middleware
Functional setup privileges for all Oracle Fusion Applications offerings
Administration privileges to Oracle Fusion Applications offerings, excluding transactional privileges
To provision a new environment, you start the Provisioning Wizard on the primordial host, make a selection from the options menu, and indicate the location of the provisioning plan. The wizard presents a review of the details in the plan on a series of interview screens.
You can make changes to most of the provisioning plan details on the interview screens. However, you cannot make any changes to the product offerings. You must create a new plan to change the offering mix.
Once you have completed the preverify phase successfully on all the hosts in your environment, and clicked Next to start the install phase on the primordial host, you can no longer modify any sections of the provisioning plan.
Run the phases in order, and complete each phase on all hosts in your environment before you begin the next phase. The Provisioning Wizard enables you to monitor the progress and success of each phase across all hosts.
Note:
If you set up a separate DMZ host for your web tier, you must open a separate terminal session for that host and run all provisioning phases (except the preverify phase). You cannot 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 you have three hosts — Host A (primordial host), Host B (primary host) and Host C (secondary host) — the process of provisioning those hosts works like this:
Open a terminal session on Host A, Host B, and Host C. Log in to each host.
Start the Provisioning Wizard on Host A, select Provision an Applications Environment, and specify the location of the provisioning plan.
Page through the wizard screens and make any necessary changes to the plan details displayed. If you selected to view individual domain details on the Provisioning Configuration screen, those screens are also added to the interview. Review the summary of installation actions that will be taken for this plan.
When you click Next on the Summary screen, the wizard initiates the preverify phase on Host A and displays the Prerequisite Checks screen. You can track the progress of this phase on this screen.
From the command line on the Host B and Host C terminal sessions, enter the syntax to run the preverify phase. (You do not have to wait for a phase to run to completion on the primordial host before you start the same phase on any of the other hosts.)
View the results of the preverify phase for all hosts on the Prerequisite Checks screen. The Next button will not be enabled until the preverify phase has been completed successfully on all hosts. Click Back to navigate through previous screens to fix errors. You must resolve all errors before you can continue.
Note:
Once you click Next to move to the Installation screen (the install phase), you can no longer go back to previous screens.When there are no errors, click Next to initiate the install phase on Host A.
From the command line on the Host B and Host C terminal sessions, enter the syntax to run the install phase.
View the results on the Installation screen on Host A. When the phase has been completed successfully on all hosts, click Next on the Installation screen to initiate the next phase and display the next tracking screen. The phases are listed in Section 5.1.2.
Repeat this process for the remaining phases until all have been completed successfully.
Note:
A full backup of the provisioning and configuration state is performed automatically at the end of all successfully completed phases.You may want to perform a manual backup, for example, if the automated backup after a phase should fail.
Note: 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 Microsoft Windows x64 (64-Bit):
cd $APPLICATIONS_CONFIG/instance
$REPOSITORY\provisioning\util\zip.exe -r $APPLICATIONS_CONFIG\restart\backup_phase_name\instance.zip .
If local configuration is enabled, also run these commands for each host:
cd $APPLICATIONS_CONFIG\domains\ $REPOSITORY\provisioning\util\zip.exe -r $APPLICATIONS_CONFIG\restart\backup_local_phase_name\hostname\domains\localdomains.zip . cd $APPLICATIONS_CONFIG/applications\ $REPOSITORY\provisioning\util\zip.exe -r $APPLICATIONS_CONFIG\restart\backup_local_phase_name\hostname\applications\localapplications.zip . cd $APPLICATIONS_CONFIG/biinst\ $REPOSITORY\provisioning\util\zip.exe -r $APPLICATIONS_CONFIG\restart\backup_local_phase_name\hostname\biinst\BIInstance.zip .
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 .
For IBM AIX on POWER Systems (64-Bit):
cd $APPLICATIONS_CONFIG
/usr/bin/pax -wEf $APPLICATIONS_CONFIG/restart/backup_phase_name/instance.pax -x pax $APPLICATIONS_CONFIG/instance .
If local configuration is enabled, also run these commands for each host:
/usr/bin/pax -wEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/domains/localdomains.pax $LOCAL_CONFIG/domains . /usr/bin/pax -wEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/applications/localapplications.pax $LOCAL_CONFIG/applications . /usr/bin/pax -wEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/biinst/BIInstance.pax $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 5-1 shows valid arguments used when running installation phases.
Table 5-1 Command-Line Syntax for Phase Arguments
| Syntax | Description |
|---|---|
|
|
Directory path to the location of the build scripts. This directory was set up when you installed the provisioning framework, for example |
|
|
You must provide the location of a previously saved provisioning plan. 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 you 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 you specify this argument for the preverify phase, you must specify it for all the remaining phases (install, preconfigure, configure, configure-secondary, 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. See Section 2.4.2. For example, the (UNIX) |
Table 5-2 shows the command-line syntax for running the various installation phases.
Table 5-2 Installation Phase Syntax
| Phase (Target) | Command Syntax |
|---|---|
|
Preverify |
(UNIX) (Windows) |
|
Install |
(UNIX) (Windows) |
|
Preconfigure |
(UNIX) (Windows) |
|
Configure |
(UNIX) (Windows) |
|
Configure-secondary |
(UNIX) (Windows) |
|
Postconfigure |
(UNIX) (Windows) |
|
Startup |
(UNIX) (Windows) |
|
Validate |
(UNIX) (Windows) |
|
Cleanup |
(UNIX) (Windows) |
|
Restore |
(UNIX) (Windows) |
Before you begin the physical installation, ensure that you have completed:
All setup details as described in Chapter 2
All installation tasks associated with your transaction database as described in Chapter 3
A provisioning plan with the required configuration details as described in Chapter 4
In addition, you must be able to employ enough terminal sessions to enable you to move between running each phase on the primordial host (using the Provisioning Wizard) and running the phases on the primary and secondary hosts (using the command line).
To provision your environment, you start the Provisioning Wizard and page through the installation screens to initiate each phase and monitor the build processes.
Note:
If you ignored any warnings during the creation of the provisioning plan, you must fix all issues stated in the warnings before you can successfully provision an environment. You can make those changes in this installation interview. The wizard saves the changes to your original plan and proceeds with the new instructions. All validations must pass before you can run the install phase.Ensure that you created the inventory pointer file (oraInst.loc) when you installed the provisioning framework. If you created the file in /etc, you can ignore the -invPtrLoc command line argument. If you created the file in another location, you must add the -invPtrLoc argument to the command line syntax and indicate the location of the inventory. See Section 2.4.2 and Section 5.2.
To start provisioning your new environment:
Open a terminal session and log in to the primordial host.
Open a terminal session and log in to each of the other hosts in your environment, including the DMZ host (if present).
Set the JAVA_HOME environment variable to point to the JDK location in the provisioning repository. For example:
(UNIX)
export JAVA_HOME=repository_location/jdk6
export PATH=$JAVA_HOME/bin:$PATH
(Windows)
set JAVA_HOME=repository_location\jdk6
set PATH=%JAVA_HOME%\bin;%PATH%
Run the following command on the primordial host:
(UNIX)
cd framework_location/provisioning/bin
./provisioningWizard.sh
(Windows)
cd framework_location\provisioning\bin
provisioningWizard.bat
Table 5-3 illustrates the steps required to provision a new environment on multiple hosts. Notice that once you run 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.
Note:
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, see Appendix E or click Help on any Provisioning Wizard interview screen.
Table 5-3 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: Installation Options Screen |
Presents the list of valid installation options that you can perform using the Provisioning Wizard. Select Provision an Applications Environment. Enter the path in the Provisioning Plan field to the plan you want to use to provision the environment. Or click Browse to navigate to the plan location. Click Next to continue. |
|
UI: Plan Description Screen |
This is the information you entered when you initially created the provisioning plan It is not associated in any way with the executable plan file, or the summary file, that you saved when you finished creating this plan. You can change the plan name, version, and description before you run provisioning, if you like.
Click Next to continue. |
|
UI: Installation Location Screen |
Displays the credentials for the Node Manager and the directory locations you entered in the provisioning plan. If these values have changed, make corrections on this screen. See Section 5.4.3 for details. Click Next to continue. |
|
UI: Review Provisioning Configuration Screen |
Lists the wizard interview screens where you originally specified domain-specific parameters for this provisioning plan. You can make changes to this information if necessary. Note: If you ignored any warnings during the creation of this provisioning plan, you must fix all issues stated in the warnings before you can successfully provision an environment. Select any of the screens displayed here to make changes for a product domains with warnings. All validations must pass before you can run the install phase. You cannot add or delete product offerings to this provisioning plan. To change product offerings, you must create a new plan. Select one or more options from the list. When you click Next, the screens you select are added to the flow. Note that if you return to this screen after running the preverification checks, those verification checks are invalidated. You must run the preverify phase again. Click Next to continue. |
|
UI: Summary Screen |
Review the information displayed to ensure that the installation details are what you intend. To make changes, click Back to return to previous screens in the interview. Click Next to initiate the preverify phase on the primordial host. The wizard displays the Prerequisite Checks screen. It also creates a current copy of this provisioning plan and saves it 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. Once you initiate this phase 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. You can make changes to the interview screens and rerun the preverify phase as many times as it is necessary. Click Retry to rerun this phase if errors are reported. You must fix all errors before you continue. See Section 5.5.3 for details. |
|
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) (Windows) Note: Phases can run in parallel on all hosts. However, each new phase must be run sequentially; that is, you cannot start a new phase until the previous one has been completed successfully on all the hosts in your environment. 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 Section 5.5.3 for details. 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. Note: Once you click Next, you can no longer modify the provisioning plan. |
|
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) (Windows) Monitor the progress on the Installation screen on the primordial host. |
|
CLI and UI: Copy the webtier_dmz_artifacts.zip file to the DMZ host (if present). |
After the install phase is complete, copy the webtier_dmz_artifacts.zip file from 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) (Windows) Monitor the progress on the Preconfiguration screen on the primordial host. |
|
CLI: Recopy the provisioning plan to the DMZ host (conditional) |
If you selected not to seed identity management details when you created the provisioning plan (on the Identity Management Configuration screen), you must recopy the plan to the DMZ host. This is necessary because during the preconfigure phase, the plan is updated with the administrator password (from LDAP). This new information must be available on the DMZ host. |
|
UI and CLI: Initiate the remaining phases (in order) on the primordial, primary, secondary, and DMZ (if present) hosts. |
Once the preconfigure phase reports a successful completion on each host in your 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 5-2 for a list of all the phases, and the command-line syntax. The associated screens, in phase order, are as follows:
Once 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 provisioning plan directory as follows:
|
Note that if you are provisioning a new environment on a single host, you can ignore the steps that run from the command line. Each phase starts automatically on the primordial host when you click Next.
The wizard displays the Node Manager credentials and the locations of the various directories you entered when you created this provisioning plan. 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 you created when you downloaded the provisioning repository. For Windows, the location must be a symbolically linked directory. See Section 2.2.5 for additional details. Note that a symbolic link is not necessary if the repository and the database are on the same node.
Oracle Fusion Application Home: Enter the directory path to the Oracle home that you specified when you installed the provisioning framework. This is the Fusion Applications Oracle home. It is the root directory for all Oracle Fusion Applications and Oracle Fusion Middleware products.
In a Windows environment, this name cannot exceed eight characters, and must be a symbolically linked directory. See Section 2.2.5 for additional details.
Application Configuration Directory: This directory is automatically populated based on the value you specify in the Oracle Fusion Applications Home field. It is the path to the directory where the configuration files for the domain will be written. For Windows, the location must be a symbolically linked directory. See Section 2.2.5 for additional details.
Enable Local Application 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 you enable this option, 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.
Local Application Config Directory: Specify the location for the local domain directory you want to set up. This field is required if you selected Enable Local Application Configuration. The specified directory must initially be empty.
WebGate Library Location: Oracle Fusion Applications (WebGate component) requires special versions of gcc libraries to be installed. These library files must exist somewhere on the Linux system. To make these libraries available, download them from http://gcc.gnu.org, as described in "Installing Third-Party GCC Libraries (Linux and Solaris Operating Systems Only)" in Oracle Fusion Applications Middleware Installation Guide for Oracle Identity Management.
In Linux x86-64 (64-Bit) and Oracle Solaris environments, enter the location where you installed the libraries. This field does not appear for Microsoft Windows x64 (64-Bit) or IBM AIX on POWER Systems (64-Bit).
For more information, see also "GCC Run-Time Libraries for Linux and Solaris" at: http://www.oracle.com/technetwork/middleware/ias/downloads/10gr3-webgates-integrations-readme-154689.pdf.
Middleware Dependencies
Font Directory: Appears only if you have selected Oracle Sales, Oracle Marketing, or Oracle Financials offerings. Enter the directory where the TrueType fonts are installed. The location varies on different operating systems, but is typically found here:
Microsoft Windows x64 (64-Bit): C:\WINDOWS\Fonts
Linux x86-64: /usr/X11R6/lib/X11/fonts/TTF
Oracle Solaris: /usr/X11R6/lib/X11/fonts/TrueType
IBM AIX on POWER Systems (64-Bit): /usr/X11R6/lib/X11/fonts/TrueType
Some systems may not have TrueType fonts installed. If you cannot locate the fonts on your system, verify that they have been installed. In addition, you can use the fonts directory shipped as part of the JRE installed in the repository. Regardless of which path you specify, you must have access to .ttf (.TTF) files.
Default IDM Configuration Using IDM Properties File: Select this check box if you want the values on the Identity Management Configuration screen and the Access and Policy Management Configuration screen to default to the values in the IDM properties file (idmDomainConfig.param). See Section 2.1.4.2 for more information about this file.
IDM Properties file: Enter the location of the (idmDomainConfig.param) file, for example, IDM_ORACLE_HOME/idmtools/bin/idmDomainDonfig.param.
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 (_).
In addition, if you are provisioning an environment that is pointed to an existing seeded identity management infrastructure, the RPD password must match the one that you specified when identity management was seeded. Provisioning sets up this password, but does not actually access the repository.
If the environment created is Windows-based, the wizard prompts for these values:
Windows Domain\Windows User Name: Specify a user name to use for running provisioning.
Windows Domain Password: Specify a password for running provisioning. Retype the password to Confirm it.
There are various resources available to help with errors that occur during the provisioning of a new Oracle Fusion Applications environment.
If you encounter an error during the creation of applications schemas and tablespaces:
Oracle Fusion Applications release notes may contain additional information about the latest updates.
This release of Oracle Fusion Applications relies on certified versions of Oracle Fusion Applications system requirements and supported platforms documentation for details about hardware and software, minimum disk space and memory requirements, required system libraries, packages, or patches, and minimum database requirements.
If you entered incorrect information on one of the installation screens, return to that screen by clicking Back until you see the screen.
Log files contain information about both normal and problematic events. They can help you diagnose and address some problems yourself. For example, log messages that state that a service cannot be reached might indicate a hardware failure.
If you discover a more complex issue, My Oracle Support personnel may use log files to trace the execution code paths of relevant requests as part of diagnosing the problem. Log files are particularly helpful if your Oracle Fusion Applications environment contains custom code that needs debugging, especially when using a debugger is not feasible (such as on a production system).
During each provisioning phase, the Provisioning Wizard writes the actions of the build processes to a log file created for each domain. Click the Log file icon to see details and error messages. In the log file, you can search for a specific text string, or move forward and backward through the content. The wrap feature enables text to be easily printed, or even forwarded by email.
Provisioning writes log files to the following location:
(UNIX)
APPLICATIONS_BASE/logs/provisioning/host_name
(Windows)
APPLICATIONS_BASE\logs\provisioning\host_name.
This shared location is accessible from all hosts, and contains the following log files:
runProvisioning-default-main.log: The main log file.
runProvisioning-phase_name.log: The main log file for a given phase, containing the output and error streams. These logs are used by the wizard to keep track of internal information. For example, for runProvisioning-preverify.log, each provisioning thread then writes its own log to runProvisioning-product_family-phase_name.log.
runProvisioning-product_family-phase_name.log: Displayed in the Provisioning Wizard as a Log icon for preconfigure, configure, configure-secondary, postconfigure, and startup phases. The files contain detailed information about the phase. For example, runProvisioning-fin-preverify.log contains information about the preverify actions taken while creating the Oracle Fusion Financials domain.
Note:
Because all reference roles must be provided in each product log file, you should expect to see duplicate reference role entries.Provisioning also relies on the Oracle Universal Installer (OUI), which writes log files as follows:
(UNIX)
Oracle_Inventory_Location/logs
(Windows)
C:\Program Files\Oracle\Inventory\logs.
If you do not know the location of the Oracle Inventory directory, you can find it at /etc/oraInst.loc (UNIX) or (Windows) C:\Program Files\Oracle\Inventory\logs.
Note that APPLICATIONS_BASE is the root directory under which the provisioned environment resides. With the exception of the web tier host, this physical location must be on a shared drive.
In addition to log file locations discussed in this section, note these log file locations associated only with the preconfigure, configure, configure-secondary, postconfigure, and startup phases:
Oracle WebLogic Server:
(UNIX) app.config.dir/domains/host_name/domain_name/servers/server_name/logs
(Windows) app.config.dir\domains\host_name\domain_name\servers\server_name\logs
Oracle WebLogic Server Node Manager:
(UNIX) APPLICATIONS_BASE/fusionapps/wlserver_10.3/common/nodemanager/host_name/
(UNIX) APPLICATIONS_BASE\fusionapps\wlserver_10.3\common\nodemanager\host_name\
The wizard performs automated cleanup and recovery actions. If those processes cannot clean up and restore your session, you can perform the actions manually.
See "Starting and Stopping Components in the Oracle Fusion Applications Environment" in Oracle Fusion Applications Administrator's Guide for complete instructions for stopping and starting components.
Recovery is intended to be systemwide. If a failure occurs on one server, cleanup and recovery steps must be performed on all servers. During the installation, errors may occur during the running of any of the installation phases. If you must use the abort feature, you may need to perform some cleanup tasks as well.
A Retry button is available on each provisioning phase interview screen to initiate cleanup on the primordial host for that phase. Initiating the retry operation affects the full phase, beginning with the primordial host. If additional cleanup is required, the wizard indicates what cleanup tasks are required, enables the Continue button, and waits for you to click Continue when the additional cleanup is complete. If no additional cleanup is required, the Continue button remains disabled, and the wizard starts executing the restore action.
Restart hosts are the hosts where cleanup and restore actions must be run so that the wizard can start the next installation phase. If you have enabled the local application configuration, all hosts are restart hosts and will require cleanup for certain phases (like configure and postconfigure). If you have not enabled local application configuration, the restart hosts are: the primordial host, the web tier host, the BI host, and the Oracle Fusion Supply Chain Management-Global Order Processing host. See Section 4.3.3 for information about the location of local application configurations.
The wizard detects restart hosts that require cleanup and displays a message informing you of the host names. You must perform the cleanup action from the command line on these hosts before you can initiate any restore action. Command-line syntax for the cleanup action takes the following form:
(UNIX) path_to_script/runProvisioning.sh -plan provisioning_plan_location -target cleanup-phase_name
(Windows) path_to_script\runProvisioning.bat -plan provisioning_plan_location -target cleanup-phase_name
The command-line syntax for the restore action takes the following form:
(UNIX) path_to_script/runProvisioning.sh -plan provisioning_plan_location -target restore-phase_name
(Windows) path_to_script\runProvisioning.bat -plan provisioning_plan_location -target restore-phase_name
These actions are available for the preverify, install, preconfigure, configure-secondary, postconfigure, startup, and validate phases. They are also available for shutdown and deinstall actions.
When a failure occurs during one of the provisioning phases, do the following:
Click Retry to run the cleanup action on the primordial host (Common domain host).
If your environment contains additional hosts, the wizard displays a message giving you the names of the other hosts.
Run the cleanup action from the command line on the other hosts in the terminal session. This can be done in parallel.
(UNIX) path_to_script/runProvisioning.sh -plan provisioning_plan_location -target cleanup-phase_name
(Windows) path_to_script\runProvisioning.bat -plan provisioning_plan_location -target cleanup-phase_name
Click Continue. If all cleanup steps are completed on all hosts where required, the wizard starts the restore action on the primordial host or prompts you to complete steps that have not been completed. Click Continue again when finished to start the restore action on the primordial host.
If your environment contains other hosts, the wizard displays a message giving you the names of the other hosts.
Note:
On Windows, do not open files in the top-level provisioning directory or any of its descendent directories before you run the restore action.Run the restore action from the command line on the other hosts from the terminal session for each host. This action can run in parallel.
(UNIX) path_to_script/runProvisioning.sh -plan provisioning_plan_location -target restore-phase_name
(Windows) path_to_script\runProvisioning.bat -plan provisioning_plan_location -target restore-phase_name
Click OK on the primordial host to start the next phase. The wizard displays the same messages as described in Step 4 if all additional hosts have not been restored.
The automated cleanup and restore actions cannot handle every type of failure. Sometimes manual steps are needed. This is true, for example, when the configure phase fails and any of the following situations exists:
Node Manager is not yet configured
Node Manager is configured with an invalid trust key
Administration Server is not yet registered with the Node Manager
Administration Server is not running
Under any of these circumstances, the Node Manager will not be able to shut down the Administration Server and the Managed Servers during cleanup-phase_name. You must manually shut down all servers before you continue with the restore-phase_name.
Shut down web tier processes, if any, with this command: (UNIX) WT_CONFIG/bin/opmnctl shutdown. To remove the Windows Service, run C:\sc delete OracleProcessManager_CommonDomain_webtier.
Note: Applies to cleanup-configure, cleanup-configure-secondary, and cleanup-postconfigure.
Shut down BI processes, if any, by running (UNIX) BI_CONFIG_HOME/bin/opmnctl shutdown. To remove the Windows Service, run C:\sc delete OracleProcessManager_BIInstance. See "Using the OPMN Command Line to Start, Stop, Restart, and View the Status of System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition 11g for more information.
Note: This applies to cleanup-configure, cleanup-configure-secondary, and cleanup-postconfigure.
Shut down Global Order Promising (GOP) (if provisioned) with this command: (UNIX) gop_instance_base/bin/opmnctl shutdown. To remove Windows service, run: (Windows) sc delete GlobalOrderPromisingServer1.
Note: This applies to cleanup-postconfigure.
Shut down Informatica Identity Resolution (IIR) processes, if any, by running these two scripts in the order listed:
APPLICATIONS_BASE/informaticaIR/bin/idsdown
APPLICATIONS_BASE/informaticaIR/bin/lidown
Note: This applies to cleanup-postconfigure, if IIR is provisioned.
Shut down Java EE processes using the method recommended for the Oracle WebLogic Server. See "Starting and Stopping Java EE Applications Using WLST" in Oracle Fusion Applications Administrator's Guide for details.
Note: This applies to cleanup-configure, cleanup-configure-secondary, and cleanup-postconfigure.
You do not have to shut down the Node Manager unless it was not configured properly.
Errors during cleanup of a target produce messages that inform you of the error and display the contents of the associated log file. If you scroll through a message, you can view additional messages, including the manual steps that you should take to fix the problem.
Note that failures during cleanup-install require specific cleanup tasks as follows:
Run the Oracle Universal Installer deinstall process for each component against the same oraInventory that provisioning uses. See the Oracle Universal Installer and OPatch User's Guide for information.
Delete the install phase guards. You can find them under APPLICATIONS_BASE/instance/phaseguards/.
(Windows) Delete the following key from the Windows registry before re-running provisioning:
HKEY_LOCAL_MACHINE/SOFTWARE\Wow6432Node\oblix\oblixNetPoint\10.1.4\ WebGate\install_directory
If this step is not completed, WebGate will not be installed properly and will generate the following error during the configure-secondary phase:
webgate-build.xml:928: The directory appbase\webgate\access\oblix\apps\common\bin does not exist.
Provisioning cannot reliably stop all grandchild processes associated with failures during the running of a phase. Occasionally, remnant process are present after a failure. Oracle recommends that you manually check and stop all remnant processes that start from the APPLICATIONS_BASE and the framework_location/provisioning folder, except for Node Manager and the Provisioning Wizard.
Take this action after you complete the cleanup action for any phase, and before you run a restore action for that phase. Without this additional cleanup action, you may experience unwanted interference with the restore action and subsequent rerun logic. This is especially true for long-running child processes such as LDAP policy migration.
You can identify remnant processes in the APPLICATIONS_BASE as follows:
(Linux) ps -ef | grep APPLICATIONS_BASE/folder_name
(Windows) wmic process get Processid,Commandline,Description | find APPLICATIONS_BASE/folder_name
You can identify remnant processes in the framework_location/provisioning folder as follows:
(Linux) ps -ef | grep framework_location/provisioning/folder_name
(Windows) wmic process get Processid,Commandline,Description | find framework_location/provisioning/folder_name
Remember, do not stop the Node Manager and UI processes.
If the automated restore operation fails, you must complete these manual steps for all phases, except as noted:
Delete the restart phase guard (phase_name.grd) file associated with the failure. It is located under APPLICATIONS_BASE/restart/.
You must restore the instance/ directory from the backup, located as follows:
(UNIX) APPLICATIONS_BASE/restart/backup_phase_name/instance.tar
(Windows) APPLICATIONS_BASE \restart\backup_phase_name\instance.zip
(IBM AIX on POWER Systems (64-Bit) APPLICATIONS_BASE/restart/backup_phase_name/instance.pax
Follow these steps to restore the instance/ directory:
(UNIX)
rm -rf CONFIG_HOME
mkdir CONFIG_HOME
tar -xfv path_to_instance.tar/instance.tar -C CONFIG_HOME
(Windows)
rm -rf CONFIG_HOME
mkdir CONFIG_HOME
cd CONFIG_HOME
framework_location\provisioning\util\unzip.exe path_to_instance.zip\instance.zip -d .
(IBM AIX on POWER Systems 64-Bit)
rm -rf CONFIG_HOME
mkdir CONFIG_HOME
cd $CONFIG_HOME
pax -rEf path_to_instance.pax/instance.pax -x pax -p e
When a local application configuration has been enabled, you must manually restore the localdomains and localapplications configuration directories on every local_application_config_host:
(UNIX) APPLICATIONS_BASE/restart/backup_phase_name/local_application_config_host/localdomains.tar and...
(UNIX) APPLICATIONS_BASE/restart/backup_phase_name/local_application_config_host/localapplications.tar
(Windows) APPLICATIONS_BASE\restart\backup_phase_name\local_application_config_host\localdomains.zip and...
(Windows) APPLICATIONS_BASE\restart/backup_phase_name\local_application_config_host\localapplications.zip
(IBM AIX on POWER Systems 64-Bit) APPLICATIONS_BASE/restart/backup_phase_name/local_application_config_host/localdomains.pax and...
(IBM AIX on POWER Systems 64-Bit) APPLICATIONS_BASE/restart/backup_phase_name/local_application_config_host/localapplications.pax
In addition, restore the following file related to Oracle Business Intelligence:
(UNIX) APPLICATIONS_BASE/restart/backup_phase_name/local application_config_host/biinst/BIInstance.tar
(Windows) APPLICATIONS_BASE\restart\backup_phase_name\local application_config_host\biinst\BIInstance.zip
(IBM AIX on POWER Systems 64-Bit) APPLICATIONS_BASE/restart/backup_phase_name/local application_config_host/biinst/BIInstance.pax
For restore-configure-secondary and restore-postconfigure only, start the CommonDomain Administration Server. See "Starting an Administration Server Using WLST and Node Manager" in Table 3-1 of Oracle Fusion Applications Administrator's Guide for complete instructions for stopping and starting components.
For restore-postconfigure only, start Oracle HTTP Server by running WT_CONFIG_HOME/bin/opmnctl startall. Oracle HTTP Server must be started from the host where it is installed. It cannot be started from any other host.
For restore-configure and restore-postconfigure, check the restore logs to see if the BI schema restore operation is complete. Perform the restore operation for the database contents first.
To restore the BI schema from backup, perform the following actions:
Drop all tables in FUSION_BIPLATFORM, if you have not done so already. Drop only the tables — not the schema user.
Run the following stored procedure as the FUSION_BIPLATFORM user. For restore-configure, use biplatform-preconfigure.dmp as the v_dump_file_name. For restore-postconfigure, use biplatform-configure-sec.dmp:
DECLARE
v_schema_name VARCHAR2(30) := 'FUSION_BIPLATFORM';
v_directory VARCHAR2(30) := 'FUSIONAPPS_PROV_RECOVERY_DIR';
v_dump_file_name VARCHAR2(30) := <biplatform-preconfigure.dmp or
biplatform-configure-sec.dmp>;
v_unique_job_name VARCHAR2(50) := <unique identifying job name e.g. Manual BI
Schema Restore>;
v_temp_schema_name VARCHAR2(40) := 'IN (''' || v_schema_name || ''')';
v_handle NUMBER;
v_job_state VARCHAR2(30);
BEGIN
v_handle :=
DBMS_DATAPUMP.open('IMPORT','TABLE',NULL,v_unique_job_name,'COMPATIBLE');
DBMS_DATAPUMP.add_file(v_handle,v_dump_file_name,v_directory);
DBMS_DATAPUMP.metadata_filter(v_handle,'SCHEMA_EXPR',v_temp_schema_name);
DBMS_DATAPUMP.start_job(v_handle);
DBMS_DATAPUMP.wait_for_job(v_handle,v_job_state);
DBMS_DATAPUMP.detach(v_handle);
END;
If LDAP cleanup fails, perform the following manual tasks:
For the preconfigure phase, complete these tasks:.
Undo member assignments on Administrators, Operators, and Monitors group nodes.
Remove AppIDUsers node under user base distinguished name.
Remove AppIDGroups node under group base distinguished name.
Remove FusionGroups node under group base distinguished name.
Remove Administrators, Operators, and Monitors groups under group base distinguished name (if you created them in the provisioning plan).
Remove jpsroot (if you enable it in the provisioning plan).
For the configure phase, remove the cn=JPSContext node (with its children) under the jpsroot node from the policy store LDAP if seeding is enabled. Perform this task on the primordial host.
For the postconfigure phase, remove all nodes under jpsroot and recreate the container nodes as well as OPSS credentials that were created in the configure phase:
Remove all nodes under jpsroot node.
Create a temporary bootstrap domain and bring up its Administration Server.
Run reassociateSecurityStore for that domain with join=false to create a fresh policy domain on LDAP.
Since the work completed in the configure phase is undone by the deletion of the policy domain during cleanup, seed OPSS credentials.
Bring down the bootstrap domain's Administration Server and delete the domain from the file system.
You cannot register this domain with Node Manager. Use the command line to bring up this server.
Rerun restore-postconfigure after you fix any issues. If this does not resolve the issues, you should start from the beginning.
You may encounter the following error while running the preverification phase on Windows systems:
"C:\repository_location/installers/database/Disk1/setup.exe": CreateProcess error=740, The requested operation requires elevation at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
If you receive this error, disable User Access Control (UAC) or log in as a Local Administrator to the machine where the Provisioning Wizard is not functioning properly.
See http://technet.microsoft.com/en-us/library/dd759070.aspx for information about disabling UAC.
You can interrupt the installation process while it is in progress by clicking Cancel, or by clicking the x icon next to a build that has failed. If you click Cancel, all processes running in the background are terminated and put in a Failed status.
You can start the wizard again after you initiate a Cancel action. The wizard detects that the installation has been partially completed, and presents you with two options:
Resume from where you left off. The wizard asks if you want to resume. Click Yes.
The wizard takes you to the screen where you clicked Cancel and created the failure. Restart the installation at that point by clicking the Retry button. The wizard performs cleanup and recovery actions for you.
Clean up the errors manually and rerun the Provision a New Applications Environment option for the provisioning plan from the beginning.
Once you have successfully completed the installation phases on all the hosts in your environment, you may need to perform postinstallation tasks. For example, you may need to apply applications or middleware related patches.
For general information about applying patches to an applications environment, see Oracle Fusion Applications Patching Guide.
You can register the Node Manager process as a service. This requires starting the process as a user other than root. Complete this task as follows:
Create a file containing the following property:
provisioning.setup.common.core.node.manager.linux.user=user name
Run the following command from each host in an environment with Managed Servers. This installs a "nodemanager-n" script under /etc/init.d. Provide the location of the file that you created in the previous step.
sudo ./runProvisioning.sh -plan provisioning_plan_location -override location_of_property_file -target configure-root
The script is configured using chkconfig to start automatically at run level 5.
Note: If there are multiple installs on the same machine from different middleware homes, you might see more than one script under /etc/init.d (named "nodemanager-n").
The TCP/IP port numbers below 1024 are special in that only processes with root privileges are allowed to listen on those ports. By default, Oracle HTTP Server runs as a non-root user (the user that installed Oracle Fusion Middleware).
If you plan to run Oracle HTTP Server on a privileged port (for example, port 80), you must enable Oracle HTTP Server to run as root. See "Viewing and Changing Ports for Components" in Oracle Fusion Applications Administrator's Guide.
Create a file called upgradeLDAPUsersForSSO.props with the following contents. This file is only for the IDSTORE user.
IDSTORE_DIRECTORYTYPE: OID IDSTORE_HOST: idstore.mycompany.com IDSTORE_PORT: 3060 IDSTORE_ADMIN_USER: cn=IDRWUSER,cn=users,cd=mycompany,dc=com IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com IDSTORE_GROUPSEARCHBASE: cn=groups,dc=mycompany,dc=com PASSWORD_EXPIRY_PERIOD: 7300
The IDRWUser is the read-write user created for provisioning:
IDM_ORACLE_HOME/idmtools/bin/idmConfigTool.sh -upgradeLDAPUsersForSSO input file=upgradeLDAPUsersForSSO.props log_file=upgradeLDAPUsersForSSO.out
Additional privileges must be given to the entities that are created during provisioning for the IDStore and the Policy Store. To add these privileges, following these steps from the IDM domain:
Set the environment variables: MW_HOME, JAVA_HOME, IDM_HOME, and ORACLE_HOME. Set IDM_HOME to IDM_ORACLE_HOME. Set ORACLE_HOME to IAM_ORACLE_HOME.
Create a properties file as follows:
IDSTORE_HOST: idstore.mycompany.com IDSTORE_PORT: 389 IDSTORE_BINDDN: cn=orcladmin IDSTORE_USERSEARCHBASE: cn=Users,DC=mycompany,dc=com IDSTORE_SEARCHBASE: dc=mycompany,dc=com IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com POLICYSTORE_HOST: policystore.mycompany.com POLICYSTORE_PORT: 389 POLICYSTORE_BINDDN: cn=orcladmin POLICYSTORE_CONTAINER: cn=FAPolicies
Perform postprovisioning configuration as follows:
(Linux x86-64)
idmConfigTool.sh -postProvConfig input_file=idm.props
(Windows)
idmConfigTool.bat -postProvConfig input_file=idm.props
The automatic incremental reconciliation processing can bring users and roles records from the IDStore into Oracle Identity Manager. However, in order for this processing to work correctly, you must perform a full reconciliation (RECON) immediately after provisioning is complete.
To perform a full reconciliation, complete the following tasks:
Disable the following jobs:
LDAP User Create and Update Reconciliation
LDAP User Delete Reconciliation
LDAP Role Membership Reconciliation
LDAP Role Create and Update Reconciliation
LDAP Role Delete Reconciliation
LDAP Role Hierarchy Reconciliation
Fusion Applications Role Category Seeding
Run the following jobs in the order listed:
LDAP User Create and Update Full Reconciliation
LDAP Role Create and Update Full Reconciliation
LDAP Role Hierarchy Full Reconciliation
LDAP Role Membership Full Reconciliation
Re-enable the reconciliation jobs that were disabled in Step 1.
To delete the restart files for Business Intelligence (BI), log in to the database using schema user ID FUSION_BIPLATFORM and run the following PL/SQL command:
BEGIN
utl_file.fremove ('FUSIONAPPS_PROV_RECOVERY_DIR','biplatform-preconfigure.dmp'); END fremove;
BEGIN
utl_file.fremove ('FUSIONAPPS_PROV_RECOVERY_DIR','biplatform-configure-sec.dmp'); END fremove;
If you encounter any issues when running this command, you can delete the files by logging in to the database host machine and deleting the restart files as follows:
Navigate to the location that is specified by the directory object FUSIONAPPS_PROV_RECOVERY_DIR. To find the location, use this PL/SQL statement:
select DIRECTORY_PATH from ALL_DIRECTORIES where DIRECTORY_NAME = 'FUSIONAPPS_PROV_RECOVERY_DIR';
Delete biplatform-preconfigure.dmp and biplatform-configure-sec.dmp.
Your new Oracle Fusion Applications environment is complete and operational. You must now perform the necessary implementation and functional setup tasks.
For complete information about setting up and managing passwords for your new environment, see "Securing Oracle Fusion Applications" and "Provisioning Identities" in Oracle Fusion Applications Administrator's Guide
Before you can start using any of the product offerings you have installed, you must complete some common implementation tasks and enable the functionality of the offerings in your environment.
A large library of product-related documentation is available for use after provisioning. Some of the guides that you will find useful are listed here:
Oracle Fusion Applications Information Technology Management, Implement Applications Guide
Product-specific Oracle Fusion Applications implementation guides
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|