Provisioning Tasks Class Libraries

The Apache ANT utility allows the developer to run OS commands, Java programs, and other types of codes, each of which is contained in an element called task defined in the build files. A developer can create custom task definitions using Java classes and bundle the class libraries in .jar (Java Archive) files. Oracle Fusion Applications provisioning related tasks are also bundled in various task definition libraries and available under the <FRAMEWORK_LOCATION>/provisioning/lib path. FRAMEWORK_LOCATION is where we have installed the provisioning framework (/app/fusion). Figure 10-3 lists some of the class libraries in this location that include the actual tasks definitions for the provisioning process. These class libraries contain the tasks which are the actual activity to be performed. These tasks can be directly called from build files, which we will discuss next. The same location also can contain third-party extensions in the form of .jar files, which also can be referenced by ANT build files.

Figure 10-3. Provisioning task definition libraries

Provisioning Build Files

Provisioning build files are located in the <FRAMEWORK_LOCATION>/provisioning/provisioning-build directory. These are ANT build automation files or build files written in the XML format. These files contain the logical flow of the provisioning process in the form of various tasks. These tasks can be defined in the build file or can make direct calls to the java program units contained in the custom tasks definition libraries. The following are important elements of an ANT build file.

• Project: A logical grouping of related tasks and targets. Each build file will have a distinct project name which will contain a number of targets within it. Project contains a number of targets and only the target which is specified while referencing the build file is executed. Each project has a default target and if no target is specified during the build process, the default target is executed.

• Targets: A container of tasks to be performed similar to traditional make utility targets in order to achieve a specific build objective. A target may depend on one or more other targets. So in order to execute one target, the dependency targets are executed from left to right by following any further dependencies. If a dependent target is has already run then it will not run again during this dependency check.

• Tasks: The actual code or program unit that is required to be executed. There are many built-in tasks and a developer can write his own task definition as well. Each task can have multiple attributes which are specified in attribute and values pairs. The values could be any string or a reference to a predefined property value. We will look at properties next. Let’s take a short example of project, target and tasks to understand how they relate to each other. Note that a good understanding of how ANT works will always help you in troubleshooting and finding the root cause easily. This example is based on Apache ANT open source manual. Here we are executing the built-in ANT tasks javac and mkdir.

  <project name="AntExample" default="compile">

  <property name="srcdir" location="src"/>

  <property name="destdir" location="dest"/>

  <target name="compile">

  <mkdir dir="${dest}"/>

  <javac srcdir="${srcdir}" destdir="${destdir}"/>

  </target>

  </project>

  Taskdefs : Used to add a new task definition in the current project. These task definitions may include a reference to a Java class that must exist in any of the included .jar files in the ANT library directory (../lib). In Fusion Applications provisioning framework the custom task definitions are created in a build file named common-taskdefs-build.xml. This file is referenced by common-build.xml file and in turn by the provisioning entry point orchestration.xml build file so these tasks remain available to all provisioning targets. For example:

  <taskdef name="createDomain" classname="oracle.apps.fnd.provisioning.ant.taskdefs.CreateDomainTask" classpath="${provisioning.classpath}"/>

• Properties : The key-value pairs defined either using the <property> task or predefined outside ANT using some input files or one of many possible task. Key acts as a variable which can be used at runtime by ANT by expanding ${key} to a value which is either predefined or generated at runtime. One example of a build file that sets various properties during Fusion Applications Provisioning is common-propertyops-build.xml. For example:

<property name="tstamp.format" value="MM/dd/yyyy hh:mm:ss aa z" />

<property name="time.total" value="Total time: " />

During provisioning process some properties are also loaded from provisioning plan file. We will look at this in next section. Figure 10-4 shows some of build files contained at <FRAMEWORK_LOCATION>/provisioning/provisioning-build. Although all these files are located in same directory and used in the same fashion as any other build files, we have grouped these files into four categories to help you understand them better.

Figure 10-4. Provisioning build files

• Provisioning phases and orchestration-related build files: This category includes the build files containing common actions related to each Provisioning Phase in common-<phase>-build.xml format. This category also includes the main installation build file orchestration-build.xml which is the entry point of any Fusion Applications Provisioning. Any phase will begin with orchestration build which internally calls all other build targets and tasks.

• Fusion Applications products-related build files: This category includes all the build files related to a particular product family of Fusion Applications suite. There may be one or more build files for each product family which reference each other from main product build file which is in <product>-build.xml format. We will show an example in coming section for one product family and how the tasks calls are being referenced via multiple build files till the particular task definition.

• Fusion middleware products-related build files: Similar to Fusion Applications Products Build Files, there are individual build files for each Fusion Middleware Product in the same directory. The format is again <product>-build.xml for example soa-build.xml, webcenter-build.xml and so on. These build files are referenced every time a middleware component related build action is called in any phase.

• Common tasks-related build files: This category includes all the build files which are not related to specific phase or product but contain generic task definitions, targets and properties which are common to most phases and products. In the following build files example we will show you how common tasks are referenced from product or phase related build files.

Provisioning Plan File

This file can be considered as input file as well as output file since it is first created as an output file at the beginning of Preverify stage and then used as input file for all phases. The location of this file is <APPLICATIONS_BASE>/provisioning/plan directory which is also created in the Preverify phase just before creation of provisioning plan file. This file should not be confused with the provisioning response file although many people sometimes use the word provisioning plan interchangeably with the response file. Response file is created from the specific responses you entered during the wizard while provisioning plan file is created internally by the provisioning framework during the Preverify phase after validating the response file and then creating a properties file named provisioning.plan. This file contains values of your provisioning environment specific variables which are used by the provisioning build files in alphabetically sorted order.

Then following target included in the common-propertyops-build.xml build file loads the properties from provisioning plan during every provisioning phase and the key values are referred by the build files at runtime.

<taskdef name=" loadplan "

classname=" oracle.apps.fnd.provisioning.ant.taskdefs.LoadPlanTask "

classpathref="bootstrap.provisioning.classpath"/>

...

<target name="common-load-properties" unless="load.properties.done"

depends="private-bootstrap-tasks, private-generate-plan-from-response-file">

...

<loadplan plan="${provisioning.plan}"

override="${plan.override}"

invptrloc="${invptr.location}"

ignoresysprereqs="${preverify.ignore}"/>

...

</target>

You will see following entries in each phase log files related to loading of properties from provisioning plan. Once these properties are loaded, the build files can refer the values using ${key} reference which will be expanded at runtime by ANT to a corresponding value.

...

[echo] Plan file: /app/oracle/provisioning/plan/provisioning.plan

[loadplan] Loading /app/oracle/provisioning/plan/provisioning.plan

[loadplan] Loaded /app/oracle/provisioning/plan/provisioning.plan

The contents of the provisioning.plan file is in <key>=<value> format. Let’s look at some examples of these properties set in the provisioning plan file.

Database-Related Property Examples

database.fusion.dbhost.host.name=fadbhost.paramlabs.com

database.fusion.dbhost.port=1521

database.fusion.enterprise.servicename=fusiondb

IDM Setup-Related Property Examples

provisioning.setup.load-idm-properties.load-idm.load.idm.properties=true

provisioning.setup.load-idm-properties.load-idm.validated.and.processed=true

provisioning.setup.load-idm-properties.load-idm.inputfile.location=/app/fusion/idmsetup.properties

Locations-Related Property Examples

provisioning.setup.common.core.default.home.top=/app/oracle

provisioning.setup.common.core.phaseguards.dir=/app/oracle/provisioning/phaseguards

provisioning.setup.install-location.locations.default.home.instance=/app/oracle/instance

Example of a Provisioning Task Execution Using ANT Build Files

Let’s look at an example task execution during the orchestration process shown in Figure 10-5. We have taken an example of createDomain which is used to create a product family domain in the Configure phase before any managed server cluster can be created.

Figure 10-5. Example task execution across multiple build files

As you can see we have taken example of createDomain task. This task is called during the Configure phase for each product family and creates the respective application domain. Here we will look at HCM WebLogic domain creation task. Let’s look at the steps involved in this ANT call.

1. The entry point for Fusion Applications provisioning is always the build file named orchestration.xml, as you can see in Figure 10-5. We can see the target named configure in this file. configure target internally calls private-invoke-parallel with value of wrappertarget parameter as private-invoke-hcm and value of target parameter as configure.

2. The private-invoke-parallel in turn runs the target name ${wrapppertarget}, the value of which resolves to private-invoke-hcm.

3. The private-invoke-hcm target then runs another target named {$target}, which resolves to configure. But since the antfile value specified is hcm-build.xml, it looks for this target in this file.

4. hcm-build.xml file imports another build file named base-product-family.xml which contains the target named configure.

5. configure internally calls private-configure target which in turn runs common-apps-create-domain via multiple internal calls not shown here.

6. The target common-apps-create-domain is found in another imported file named common-configure-build.xml. This target runs the configure target within the domain-build.xml build file.

7. The configure target in domain-build.xml runs a private-configure target which in turn runs common-create-product-family-domain target.

8. The common-create-product-family target is found in the imported file common-configure-build.xml. This target runs the Task named createDomain, which refers to the oracle.apps.fnd.provisioning.ant.taskdefs.CreateDomainTask class, which may contain the actual code for the task.

9. The Apache ANT utility looks up for this class and finds the ../lib/oracle-provisioning-anttasks.jar file.

This concludes the example workflow of a sample task execution in Fusion Applications provisioning.

Phaseguard Files

Phaseguards are created for each host and for every provisioning phase in the <phase>-<hostname>-<status>.grd format. These are blank files acting as flag files for the provisioning framework to detect the current status of the phase. Each phase may have one of the status from STARTED, COMPLETED, ENDED, FAILED, or ABORTSIGNLED.

The directory phaseguards also contains a sub-directory named pf (Product Family) which contains individual status of each product family in every phase. These files are in <phase>-<hostname>-<product family>-<status>.grd format. Product family phaseguards can have STARTED, COMPLETED, or FAILED status. Whenever a phase is restarted after failure, these product family phaseguard files are read and only those which failed earlier are restarted.

Provisioning Lock Files

Provisioning lock files are also as sensitive as phaseguards and should not be touched manually. Provisioning framework controls the asynchronous flow of certain tasks which should not run at the same time by allowing each product build to obtain a lock in form of these flag files so that other tasks may not run the same tasks at that time and need to wait till the lock is released. There is a specific timeout specified for each of such tasks on how long they need to wait before aborting the task and sending failure signal. Provisioning lock files have extension .lck and are blank files acting as a placeholder or flag file only. Only in case of manual cleanup these files can be deleted if you are fully aware of the root cause or if advised by Oracle Support.

Instance and Local Configuration Backup Files

Upon completion of each provisioning phase related tasks, the provisioning framework creates a backup of the instance directory and local configuration directory (if exists). These files are named instance.tar and placed under respective <APPLICATIONS_BASE>/provisioning/restart/backup_<phase> directory for each completed phase. Depending on the number of phases successfully completed, you will see a number of directories in this location. These backup files are used to do a full or partial restore of instance directory in case of failure during Fusion Applications installation.

Figure 10-6 shows the three types of output files along with their location. Note that this diagram shows the status after a successful completion of provisioning so you do not see any FAILED or ABORTSIGNALED phaseguards. Also although you can see all instance backups for reference only since upon successful completion of next phase the instance backup from previous phase is no longer required and deleted automatically. So you may not see the directories for other earlier phases except the Postconfigure phase under restart directory upon completion of Fusion Applications provisioning.

Figure 10-6. Important files created during provisioning

Now let’s try to relate the Fusion Applications provisioning phases with the output files created during each phase. As you can see the phase proceeds in following stages. Let’s see the output files created in each of these stages.

1. Phase initiation: Once the phase is initiated, it first creates a phaseguard file named <phase>-<hostname>-STARTED.grd to let other attempts to run the provisioning framework know that the phase has already initiated on this host and not yet completed.

2. Phase execution: During the execution of the phase build targets related to each product family (those part of selected configuration) are executed. This begins with first creating a phaseguard file for the respective product family with name as <phase>-<hostname>-<product family>-STARTED.grd. During the execution of the phase several lock files are created to control asynchronous tasks. Once the tasks related to a particular product family completes then a phaseguard file named <phase>-<hostname>-<product family>-COMPLETED.grd is created. The other product families related build targets may still be running at this stage.

3. Tasks completion: Once all product families related tasks for the particular phase are complete, the installer creates phase tasks completion phaseguard file named <phase>-<hostname>-COMPLETED.grd and the status column of the phase on the wizard screen shows up as completed with a green tick mark sign. However the Next button to initiate the next phase will not be active yet.

4. Phase completion: During the time between tasks completion and phase completion the provisioning framework creates backup of the complete instance directory and local configuration (if available) to the restart directory in the background. It also creates backup lock files to indicate that the backup is going on. Once these tar backups are complete, the framework writes a phaseguard file named <phase>-<hostname>-ENDED.grd. At this stage you will notice that the Next button to proceed to next phase becomes enabled.

Figure 10-7 shows stages of a generic phase as mentioned above in graphical format.

Figure 10-7. Stages of each phase with corresponding files created

Fusion Applications Provisioning Log Files

Provisioning Log files and output files are your most important resources during provisioning process since we will use them heavily to troubleshoot or monitor the provisioning phases. Log files (.log extension) contain details of every task being executed during the provisioning process while the output files (.out extension) contain the standard execution output of each task. The output files are generated for phase only not for each product domain. While log files are crated for each phase as well as every product domain and for some phases there are log files for managed servers as well. Output files generally contain the execution output with timing details while log files contain the verbose messages about the tasks being started, completed or error conditions.

If there are any errors during any of the provisioning phases, you may not find java related exception details in log files so in this case you must refer to the output files since such exception details are found in output files. For individual command-line tasks like cleanup and restore you may see output files containing the console output. In later sections we will see how to clean up the phase and restore to previous state before restarting the same phase again. In this case the provisioning framework creates a directory named <phase>-<timestamp> inside <logfiles location>/archive and moves previous log files related to failed phase. This is done in order to avoid the files from being overwritten and to keep them available for future reference or troubleshooting.

The default logging level in the log files is specified in the configuration file prov-logging-config.xml located at <FRAMEWORK_LOCATION>/provisioning/bin directory, the same directory where from where we run the provisioning wizard scripts. Names of the logger parameters that control the level of logging in the files as well as on the console are runProvisioning-default-main and runProvisioning-console respectively. The default level of these logger is TRACE:1 and NOTIFICATION:1 respectively which are FINE and INFO levels. There are various other levels like TRACE:16 (FINER), TRACE:32 (FINEST) etc. for more detailed log for further debugging purpose. All you need to do is to back up prov-logging-config.xml file and modify the following lines temporarily to change the logging level.

<logger name="runProvisioning-default-main" level="TRACE:1">

<logger name="runProvisioning-console" level="NOTIFICATION:1">

Let’s look at some of the important log and output files created during the provisioning process. Figure 10-8 shows the name format and location of the important provisioning log and output files.

Figure 10-8. Fusion Applications Provisioning Log files

As you can see the files are generated at <APPLICATIONS_BASE>/log/provisioning/plan<timestamp>/<hostname>, where hostname is the host where the current provisioning phase is running and timestamp format is number of milliseconds from 1-Jan-1970 00:00:00 not counting the leap seconds. This value is generated at runtime using java.lang.System.currentTimeMillis() method. You can also see the archive folder and corresponding archived log files for each phase.

Preverify Phase

Figure 10-16 shows the Prerequisite Checks screen, which runs the Preverify phase behind the scenes.

Figure 10-16. Prerequisite Checks screen

Once you see the target-tasks tree on the screen, you can initiate the phase from other primary and/or secondary hosts if they are selected in your installation topology. You must initiate the phase on these nodes using the command-line interface only. You can monitor the progress of the phase on each non-DMZ host on this same screen. The following is the script you need to run to initiate the phase on other hosts. Note that you may need to use the -ignoreSysPrereqs true argument on the command line if you have used the same option while invoking the wizard earlier.

./runProvisioning.sh -responseFile <Response File path> -target preverify

[-ignoreSysPrereqs true]

For example:

[fusion@primaryhost ]$ cd /app/fusion/provisioning/bin

[fusion@primaryhost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target preverify -ignoreSysPrereqs true

Since the selected topology has only one node for the Fusion applications tier, we need not run this command on any host. We will use only the wizard for Fusion Applications installation but we will mention the steps required for multi-host topology as well wherever applicable.

As mentioned earlier you can monitor the progress of the phase on the corresponding Wizard screen. The screen shows a target-task based tree with each product family or domain as the parent of the tree node and all related tasks as sub-nodes of the same starting from orchestration product family. Although there is no domain for orchestration product family, it is the starting point of each phase build. The script that’s internally called by the wizard to run the actual ANT build command is as follows.

/app/fusion/provisioning/ant/bin/ant

-f /app/fusion/provisioning/provisioning-build/orchestration-build.xml

-Dresponsefile.input=/app/fusion/provisioning/bin/provisioning.rsp

-Dconfigframework.lib.dir=/app/fusion/provisioning/lib

-Dtools.lib.dir=/app/fusion/provisioning/lib

-logger oracle.apps.fnd.provisioning.ant.taskdefs.util.logger.ProvisioningLogger

-lib /app/fusion/provisioning/lib/oracle-provisioning-antlogger.jar

-lib /app/fusion/provisioning/lib/ojdl.jar

-lib /app/fusion/provisioning/lib/dms.jar

-Dpreverify.ignore true

-Ddebug.timestamp 09_11_14_01_49_46

-Dprovisioning.target preverify preverify

As you can see, the build file being called internally is orchestration-build.xml, which is essentially the provisioning entry point. The response file is passed using the parameter DresponseFile.input. Based on the target mentioned as the parameter Dprovisioning.target, the ANT utility runs the appropriate target in the orchestration.xml build file. In this case, it is a preverify target.

While the tasks in a target are executing you will see a clock symbol next to the target name. Once all the tasks in any target are complete, you will see a green checkmark next to the target name. Any errors or warnings in the task will be displayed by red x mark or yellow exclamation symbol respectively next to the task as well as the product family tree parent node. The orchestration family node will also reflect the same symbol but if there are errors or warnings then the orchestration node will be marked with error symbol.

You can see the home icon on top of the screen before hosts column, which suggests that the host where the wizard is running is essentially the primordial host. The current provisioning phase is highlighted in the left panel. The bottom messages panel will remain empty until you select any member of the tree. Once you click on any line in the tree, it will show a success, warning, or failure message in the messages tab whenever such message is available.

There are a lot of documented known errors or warnings for this phase depending on the topology. You can refer to the release notes for current release to determine which errors can be skipped. For example, the following was a known error in Fusion Applications 11g, Release 7 and, in some cases, you may see this error even in the latest release. This error can be ignored if you have already validated your Identity Management environment manually.

OAM_Validation: Cannot perform OAM Validation as null

In such cases if you have not initiated the script with the ignoreSysPrereqs true argument then the Next button may not be activated and you may see the Retry button to rerun the phase. If you have used ignoreSysPrereqs argument then both the Retry and Next buttons will be activated. Note that this is not applicable for other phases so even if you have used the same argument, you cannot skip the errors in any other phases and any error must be fixed before you can proceed to the next phase. Make sure not to use any workarounds to skip the phase (except validate phase) since it may result in incomplete and erroneous installation of Fusion Applications.

Here are the major activities performed during the Preverify phase.

• Runs various validation tests to check if the environment meets the installation prerequisites.

• It checks if the installation location is writable, checks available physical memory, disk space, swap space, ports availability, JDK version, kernel parameters, and so on.

• Validates connection to FA and IDM databases.

• Validates the Identity Management managed servers and URLs reachability.

• Creates a provisioning plan file from the response file.

• If you did not select the Create Administrators Group checkbox in Identity Management screen of response file creation then it checks whether the Administrator group already exists.

• It also checks whether the super user specified in the same screen already exists in identity store or a new user needs to be created.

In this example the only warning it shows is related to HWR mount point size which is a special file system path where HWR reporting files are stored. The minimum required size is 1024 GB as per documentation. You can ignore the warning about HWR mount point size (1024 GB) if you are not using this functionality.

The following are the important files created during the Preverify phase. If there are any issues with the phase you may need to refer to these files for troubleshooting.

Log files: Created at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. For example, /app/oracle/logs/provisioning/plan1415477981901/fahost.

runProvisioning-preverify.log

runProvisioning-preverify-logstatus.log

runProvisioning-preverify.out

Phaseguards: Created at <APPLICATIONS_BASE>/provisioning/phaseguards. For example, /app/oracle/provisioning/phaseguards.

preverify-fahost-STARTED.grd

preverify-fahost-ENDED.grd

preverify-fahost-COMPLETED.grd

pf/preverify-fahost-<phase>-STARTED.grd

pf/preverify-fahost-<phase>-COMPLETED.grd

Provisioning Plan: The provisioning.plan file is created at <APPLICATIONS_BASE>/provisioning/plan. For example, /app/oracle/provisioning/plan/provisioning.plan.

As you can see, the Preverify phase creates the internal provisioning plan file <APPLICATIONS_BASE>/provisioning/plan/provisioning.plan from provisioning response file. Since this is a shared location, this file will be available to primordial, primary, and secondary hosts except a DMZ host since DMZ uses the local file system. If your architecture involves a DMZ host then you must manually copy this file to <APPLICATIONS_BASE>/provisioning/plan on the DMZ host before you proceed to the Install phase.

Install Phase

Once the Preverify phase is completed successfully, click Next to proceed to the Install phase, as shown in Figure 10-17.

Figure 10-17. Installation phase status screen

Now you will see the installation (install) phase progress screen. The interface for all phases looks exactly the same with same top-level titles in the task tree. Each phase runs on each of the configured product domains and, depending on the number of physical CPUs on the host, tasks related to multiple product families may start in parallel.

Once the Install phase has been kicked off on the primordial host, you can initiate the phase on primary hosts (if present), secondary hosts (if present), and DMZ host (if present) from the command-line interface as follows.

./runProvisioning.sh -responseFile <Response File path> -target install [-ignoreSysPrereqs true]

For example:

[fusion@primaryhost ]$ cd /app/fusion/provisioning/bin

[fusion@primaryhost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target install -ignoreSysPrereqs true

The following important actions are performed during the Install phase.

• Installs Fusion Middleware and Fusion Application components in respective home directories.

• Once installation of each component is done, it applies the tech patches from the patches directories that are bundled with the installation media and extracted at the respective product directory in the installation repository.

• This phase involves any Identity Management environment-related actions.

The actual ANT command executed behind the scenes is as follows.

/app/fusion/provisioning/ant/bin/ant

-f /app/fusion/provisioning/provisioning-build/orchestration-build.xml

-Dresponsefile.input=/app/fusion/provisioning/bin/provisioning.rsp

-Dconfigframework.lib.dir=/app/fusion/provisioning/lib

-Dtools.lib.dir=/app/fusion/provisioning/lib

-logger oracle.apps.fnd.provisioning.ant.taskdefs.util.logger.ProvisioningLogger

-lib /app/fusion/provisioning/lib/oracle-provisioning-antlogger.jar

-lib /app/fusion/provisioning/lib/ojdl.jar

-lib /app/fusion/provisioning/lib/dms.jar

-Dpreverify.ignore true

-Ddebug.timestamp 09_11_14_02_02_07

-Dprovisioning.target install install

The following are the important files created during the Install phase. If there are any issues with this phase, you may need to refer to these files for troubleshooting.

Log files: Created at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. For example, /app/oracle/logs/provisioning/plan1415477981901/fahost.

runProvisioning-install.log

runProvisioning-install-logstatus.log

runProvisioning-install.out

Phaseguards: Created at <APPLICATIONS_BASE>/provisioning/phaseguards. For example, /app/oracle/provisioning/phaseguards.

install-fahost-STARTED.grd

install-fahost-ENDED.grd

install-fahost-COMPLETED.grd

pf/install-fahost-<phase>-STARTED.grd

pf/install-fahost-<phase>-COMPLETED.grd

Instance directory Backup: Back up of the instance directory <APPLICATIONS_BASE>/instance is created at <APPLICATIONS_BASE>/provisioning/restart/backup_<phase>. For example, a .tar backup of /app/oracle/instance directory is created at /app/oracle/provisioning/restart/backup_install/instance.tar.

Installation takes a few hours depending on the type of disk selected and other hardware configuration. Once the Installation phase is complete on all hosts, the Next button will be activated. The Installation phase creates a file named webtier_dmz_artifacts.zip at <APPLICATIONS_BASE>. If you have a DMZ host in your topology, you must copy this file to the same location on the DMZ host before you can proceed.

Preconfigure Phase

Once Install phase has completed successfully, click Next to proceed to the Preconfigure phase, as shown in Figure 10-18.

Figure 10-18. Preconfigure phase status screen

As you know the phase runs on each of the configured product domains and, depending on the number of physical CPUs on the host, tasks related to multiple product families may start in parallel. But there are some tasks that should not run in parallel. To make sure that these tasks are not run in parallel, the provisioning framework makes use of lock files, which are empty files that act as a flag to indicate that the task is already being executed by another process. So once such a task is initiated, the task creates the appropriate lock file. If any other task wants to run the same action then it will first check if it is possible to acquire a lock on this file and such lock already exists then it will need to wait for the previous task to complete. There is a stipulated time until which the process will wait after which also if it cannot acquire lock then it will fail. These timeout parameters are specified in relevant XML build files and should not be modified as a workaround to get rid of timeout errors unless specified by a provisioning expert or by Oracle Support.

Once the Preconfigure phase has been kicked off on the primordial host, you can initiate the phase on the primary hosts (if present), secondary hosts (if present), and DMZ host (if present) from the command-line interface as follows. In case of single FA host topology, you should skip this step.

./runProvisioning.sh -responseFile <Response File path> -target preconfigure

[-ignoreSysPrereqs true]

For example:

[fusion@primaryhost ]$ cd /app/fusion/provisioning/bin

[fusion@primaryhost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target preconfigure -ignoreSysPrereqs true

The following important actions are performed during the Preconfigure phase.

• Performs ESS ADF configuration by updating connections.xml with the Fusion Applications database MDS schema details (FUSION_MDS_ESS) so that ADF uses this as the metadata services repository.

• Uploads the LDIF files containing tasks to create Application administrator groups. These files with the .ldif extension are already copied as part of the Install phase under /app/oracle/fusionapps/applications/com/acr/security/ldif.

• Creates system administrator groups if selected during response file creation and if it does not already exist.

• Seeds AppID users and AppID groups to the identity store using oid_appid_users.ldif and oid_appid_groups.ldif files. Gives the bootstrap AppID membership of the system administrators group.

• Makes the designated super user (FAAdmin in this case) member of the administrator groups and other groups related to the application family.

The actual ANT command executed behind the scenes is as follows.

/app/fusion/provisioning/ant/bin/ant

-f /app/fusion/provisioning/provisioning-build/orchestration-build.xml

-Dresponsefile.input=/app/fusion/provisioning/bin/provisioning.rsp

-Dconfigframework.lib.dir=/app/fusion/provisioning/lib

-Dtools.lib.dir=/app/fusion/provisioning/lib

-logger oracle.apps.fnd.provisioning.ant.taskdefs.util.logger.ProvisioningLogger

-lib /app/fusion/provisioning/lib/oracle-provisioning-antlogger.jar

-lib /app/fusion/provisioning/lib/ojdl.jar

-lib /app/fusion/provisioning/lib/dms.jar

-Dpreverify.ignore true

-Ddebug.timestamp 09_11_14_01_49_46

-Dprovisioning.target preverify preverify

The following are the important files created during the Preconfigure phase. If you have any issues with the phase you may need to refer to these files for troubleshooting.

Log files: Created at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. For example, /app/oracle/logs/provisioning/plan1415477981901/fahost.

runProvisioning-preconfigure.log

runProvisioning-<product_family>-preconfigure.log

runProvisioning-preconfigure-logstatus.log

runProvisioning-preconfigure.out

Phaseguards: Created at <APPLICATIONS_BASE>/provisioning/phaseguards. For example, /app/oracle/provisioning/phaseguards.

preconfigure-fahost-STARTED.grd

preconfigure-fahost-ENDED.grd

preconfigure-fahost-COMPLETED.grd

pf/preconfigure-fahost-<phase>-STARTED.grd

pf/preconfigure-fahost-<phase>-COMPLETED.grd

Instance directory backup: Back up of the instance directory <APPLICATIONS_BASE>/instance is created at <APPLICATIONS_BASE>/provisioning/restart/backup_<phase>. For example, a .tar backup of /app/oracle/instance directory is created at /app/oracle/provisioning/restart/backup_preconfigure/instance.tar.

Configure Phase

Once the Preconfigure phase is complete on all hosts, click Next to proceed to the Configure phase, as shown in Figure 10-19.

Figure 10-19. Configure phase status screen

Configure and Postconfigure are two of the most time-consuming phases after the Install phase. You can monitor this screen to see the progress of the Configure phase for each product family on each host (except DMZ). Once the Configure phase has been kicked off from the primordial host, start it from the primary hosts (if available), secondary hosts (if available), and DMZ host (if available) using the following command-line interface scripts.

./runProvisioning.sh -responseFile <Response File path> -target configure

[-ignoreSysPrereqs true]

For example:

[fusion@primaryhost ]$ cd /app/fusion/provisioning/bin

[fusion@primaryhost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target configure -ignoreSysPrereqs true

The Configure phase performs a lot of important activities with respect to Fusion Applications installation. The following are some of the actions performed during the Configure phase.

• Creates WebLogic domains for all required product families, including CommonDomain and other Application domains required for the products selected for installation on the selected host with the bootstrap AppID as the administrator.

• Once the domains are created, it creates WebLogic clusters and managed servers as part of the clusters.

• Configures the data sources for each domain and wires the middleware components.

• Deploys the application products to the respective managed servers.

• Registers the node managers on servers and enrolls the product domains with the node manager.

• Starts up the administration server for each configured WebLogic domain.

• Creates Oracle HTTP Server virtual host configuration files for each domain.

• Disables the default authenticator and enables LDAP authenticator in order to use SSO.

The actual ANT command executed behind the scenes is as follows.

/app/fusion/provisioning/ant/bin/ant

-f /app/fusion/provisioning/provisioning-build/orchestration-build.xml

-Dresponsefile.input=/app/fusion/provisioning/bin/provisioning.rsp

-Dconfigframework.lib.dir=/app/fusion/provisioning/lib

-Dtools.lib.dir=/app/fusion/provisioning/lib

-logger oracle.apps.fnd.provisioning.ant.taskdefs.util.logger.ProvisioningLogger

-lib /app/fusion/provisioning/lib/oracle-provisioning-antlogger.jar

-lib /app/fusion/provisioning/lib/ojdl.jar

-lib /app/fusion/provisioning/lib/dms.jar

-Dpreverify.ignore true

-Ddebug.timestamp 09_11_14_10_46_10

-Dprovisioning.target configure configure

The following are the important files created during the Configure phase. If there are any issues with the phase you may need to refer to these files for troubleshooting.

Log files: Created at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. For example, /app/oracle/logs/provisioning/plan1415477981901/fahost.

runProvisioning-configure.log

runProvisioning-<product_family>-configure.log

runProvisioning-configure-logstatus.log

runProvisioning-configure.out

Phaseguards: Created at <APPLICATIONS_BASE>/provisioning/phaseguards. For example, /app/oracle/provisioning/phaseguards.

configure-fahost-STARTED.grd

configure-fahost-ENDED.grd

configure-fahost-COMPLETED.grd

pf/configure-fahost-<phase>-STARTED.grd

pf/configure-fahost-<phase>-COMPLETED.grd

Instance directory Backup: Back up of the instance directory <APPLICATIONS_BASE>/instance is created at <APPLICATIONS_BASE>/provisioning/restart/backup_<phase>. For example, a .tar backup of /app/oracle/instance directory is created at /app/oracle/provisioning/restart/backup_configure/instance.tar.

Configure Secondary Phase

The Configure phase takes a few hours to complete. Once the Configure phase is complete on all hosts, click Next to proceed to the Configure-Secondary phase, as shown in Figure 10-20.

Figure 10-20. Configure Primary/Secondary phase status screen

The Configure-Secondary phase is also called Configure Primary/Secondary. It was shown on the screen as Configure Secondary in older releases but the name was changed to Configure Primary/Secondary. Once the Configure-Secondary phase has been kicked off from the primordial host, start it from the primary hosts (if available), secondary hosts (if available), and DMZ host (if available) using the following command-line interface scripts.

./runProvisioning.sh -responseFile <Response File path> -target configure-secondary

[-ignoreSysPrereqs true]

For example:

[fusion@primaryhost ]$ cd /app/fusion/provisioning/bin

[fusion@primaryhost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target configure-secondary

-ignoreSysPrereqs true

The following important actions are performed during the Configure-Secondary phase.

• If there are primary and/or secondary servers in your selected topology then this phase will run the same configure actions on those servers.

• Registers managed servers configured on primary and secondary hosts with the node manager of the respective host.

• If there are no primary or secondary hosts present in your selected topologies then it skips these actions.

• Creates web tier instance ohs1 under <APPLICATIONS_TOP>/CommonDomain_webtier on the web host. Note that this activity is done in this phase even if you have a single-node topology.

The actual ANT command executed behind the scenes is as follows.

/app/fusion/provisioning/ant/bin/ant

-f /app/fusion/provisioning/provisioning-build/orchestration-build.xml

-Dresponsefile.input=/app/fusion/provisioning/bin/provisioning.rsp

-Dconfigframework.lib.dir=/app/fusion/provisioning/lib

-Dtools.lib.dir=/app/fusion/provisioning/lib

-logger oracle.apps.fnd.provisioning.ant.taskdefs.util.logger.ProvisioningLogger

-lib /app/fusion/provisioning/lib/oracle-provisioning-antlogger.jar

-lib /app/fusion/provisioning/lib/ojdl.jar

-lib /app/fusion/provisioning/lib/dms.jar

-Dpreverify.ignore true

-Ddebug.timestamp 09_11_14_15_56_16

-Dprovisioning.target configure-secondary configure-secondary

The following are the important files created during the Configure-Secondary phase. If that are any issues with the phase you may need to refer to these files for troubleshooting.

Log files: Created at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. For example, /app/oracle/logs/provisioning/plan1415477981901/fahost.

runProvisioning-configure-secondary.log

runProvisioning-<product_family>-configure-secondary.log

runProvisioning-configure-logstatus-secondary.log

runProvisioning-configure-secondary.out

Phaseguards: Created at <APPLICATIONS_BASE>/provisioning/phaseguards. For example, /app/oracle/provisioning/phaseguards.

configure-secondary -fahost-STARTED.grd

configure-secondary -fahost-ENDED.grd

configure-secondary -fahost-COMPLETED.grd

pf/configure-secondary -fahost-<phase>-STARTED.grd

pf/configure-secondary -fahost-<phase>-COMPLETED.grd

Instance directory Backup: Back up of the instance directory <APPLICATIONS_BASE>/instance is created at <APPLICATIONS_BASE>/provisioning/restart/backup_<phase>. For example, a .tar backup of /app/oracle/instance directory is created as follows: /app/oracle/provisioning/restart/backup_configure-secondary/instance.tar.

Postconfigure Phase

The Configure Primary/Secondary phase may take a few minutes. Click Next to proceed to the Postconfigure phase, as shown in Figure 10-21.

Figure 10-21. Postconfigure phase status screen

The Postconfigure phase is the most error-prone phase if you do not have the right hardware or if the process parallelism does not initiate correctly. In such cases it may cause timeout errors. We will discuss that soon. The Postconfigure phase takes a very long time. Do not panic if you see errors during this phase since most of the errors are transient and can be fixed upon rerunning based on the error. In the previous example you saw that the CRM postconfigure failed and the error was related to a timeout during high CPU activity.

Once the Postconfigure phase has been kicked off from the primordial host, start it from the primary hosts (if available), secondary hosts (if available), and DMZ host (if available) using the following command-line interface scripts.

./runProvisioning.sh -responseFile <Response File path> -target postconfigure

[-ignoreSysPrereqs true]

For example:

[fusion@primaryhost ]$ cd /app/fusion/provisioning/bin

[fusion@primaryhost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target postconfigure -ignoreSysPrereqs true

The following important actions are performed during the Postconfigure phase.

• Performs tasks that require the components while they are online.

• Seeds policies and grants.

• Configures and deploys Oracle SOA composites.

• Performs post-deployment security configurations.

• Sets the value for FusionAppsFrontendHostUrl to the designated port on the Oracle HTTP Server for each domain.

• Assigns administrator privileges and function setup privileges on each Fusion Application offering to the designated super user.

The actual ANT command executed behind the scenes is as follows.

/app/fusion/provisioning/ant/bin/ant

-f /app/fusion/provisioning/provisioning-build/orchestration-build.xml

-Dresponsefile.input=/app/fusion/provisioning/bin/provisioning.rsp

-Dconfigframework.lib.dir=/app/fusion/provisioning/lib

-Dtools.lib.dir=/app/fusion/provisioning/lib

-logger oracle.apps.fnd.provisioning.ant.taskdefs.util.logger.ProvisioningLogger

-lib /app/fusion/provisioning/lib/oracle-provisioning-antlogger.jar

-lib /app/fusion/provisioning/lib/ojdl.jar

-lib /app/fusion/provisioning/lib/dms.jar

-Dpreverify.ignore true

-Ddebug.timestamp 10_11_14_10_06_17

-Dprovisioning.target postconfigure postconfigure

The following are the important files created during the Postconfigure phase. If you have any issues with the phase you may need to refer to these files for troubleshooting.

Log files: Created at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. For example, /app/oracle/logs/provisioning/plan1415477981901/fahost. You may notice that some startup log files are also created during this phase. This is because the Postconfigure phase brings up these managed servers for processing.

runProvisioning-postconfigure.log

runProvisioning-<product_family>-postconfigure.log

runProvisioning-postconfigure-logstatus.log

runProvisioning-postconfigure.out

runProvisioning-<product_family>-<managed_server>-startup.log

Phaseguards: Created at <APPLICATIONS_BASE>/provisioning/phaseguards. For example, /app/oracle/provisioning/phaseguards.

postconfigure-fahost-STARTED.grd

postconfigure-fahost-ENDED.grd

postconf/igure-fahost-COMPLETED.grd

pf/postconfigure-fahost-<phase>-STARTED.grd

pf/postconfigure-fahost-<phase>-COMPLETED.grd

Instance directory Backup: Back up of the instance directory <APPLICATIONS_BASE>/instance is created at <APPLICATIONS_BASE>/provisioning/restart/backup_<phase>. For example, a tar backup of /app/oracle/instance directory is created at /app/oracle/provisioning/restart/backup_postconfigure/instance.tar.

We can rerun the phase by clicking on Retry and it will do cleanup/restore to the previous step (only for the failed product domains).

Restarting the Installation After a Failure in a Phase

Fusion Applications provisioning allows granular restart functionality for each phase. If a phase fails due to errors in executing some tasks or a task timed out waiting for locks, you will see the product domain status for that phase marked as FAILED and it will stop any further processing of that particular product domain. However it will continue to process the remaining product domains until their completion. At the end of the processing, the installer will display successful and failed targets (product domains) with the relevant symbol with overall phase status also as FAILED. You will see appropriate phaseguard files being generated in <APPLICATIONS_BASE>/provisioning/phaseguards. At this stage, the wizard will activate the Retry button. Once you click on the Retry button, the wizard will initiate the cleanup and restore operations on the failed host, as shown in Figure 10-22.

Figure 10-22. Cleanup and Restore status screen

Sometimes, the cleanup or restore or both may fail to complete. In that case you may need to run the cleanup and restore from command-line tools even on the primordial host. Also for the other hosts, you will need to run cleanup and restore using the same command-line options. The syntax of running this using CLI is as follows. Note that once the cleanup operation completes on all hosts you can only initiate the Restore operation.

cd <FRAMEWORK_LOCATION>/provisioning/bin

./runProvisioning.sh -responseFile <Response File path> -target cleanup-<phase>

./runProvisioning.sh -responseFile <Response File path> -target restore-<phase>

For example:

[fusion@fahost ]$ cd /app/fusion/provisioning/bin

[fusion@fahost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target cleanup-postconfigure

[fusion@fahost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target restore -postconfigure

You can see the following cleanup and restore log files generated at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. The log files are moved to the archive directory upon restart.

runProvisioning-cleanup-<phase>.out

runProvisioning-cleanup-<phase>.log

runProvisioning-restore-<phase>.out

runProvisioning-restore-<phase>.log

During restore, the installer will restore the failed domains’ subdirectories from backup_<previous_phase>/instance.tar located at <APPLICATIONS_BASE>/provisioning/restart. It will also remove the phaseguard files for FAILED product families and the phase followed by restart of the same phase. On the primordial host once you have completed clean-up and restore and clicked OK on the confirmation screen, it will automatically restart the phase. For other hosts you need to run the command-line script to restart the phase on that host. During restart the installer will detect completed product domains and will only proceed to the previously failed targets.

Restarting Aborted or Crashed Installation

Note that if the host was restarted to resolve certain issues or if the installation was canceled in between or the installer crashed during the installation, you can restart the installation from same state as it was aborted. The phaseguards and restart directories provide a mechanism to restart the installation. When you restart the Provisioning wizard it will automatically detect where it had left off and display the prompt to resume provisioning, as shown in Figure 10-23.

Figure 10-23. Resume Provisioning prompt

As you can see in Figure 10-23, you have two options to select from by clicking Yes or No. Be very careful before choosing.

• Start provisioning from beginning

  If you select No the installer will reset all the status information and take you back to the first screen of installation location details. You must kill all running processes related to the Fusion Applications environment, clean up the <APPLICATIONS_BASE> directory, and restore the Fusion Applications transaction database to its post-RCU stage. If you do not have any backup of the database then you must create a fresh database and run RCU on that.

• Resume provisioning from previously running or failed phase

  If you select Yes then the installation will resume from where it left off. It could be an already running, failed, or successful phase. If the last phase was successful and the installation was aborted before proceeding to the next phase, you will see the success screen again and you will be able to click Next to proceed to the next phase. If the phase was failed or running while installation was aborted, it will show the failed phase screen and allow you to initiate cleanup and restore by clicking on the Retry button.

Before running the cleanup target, make sure that Identity Management environment is running and the Fusion Applications Transaction database is up. For the Configure phase onward, you must also ensure that the node manager has been started on the host. This also applies to the scenario when a phase had completed successfully and before starting the next phase you had restarted the host. Before any new provisioning target including cleanup or restore can start, the installer will need to connect to the node manager to check the status of the WebLogic servers status on that node. It will start them if required. You can start the node manager by running the following script. For all startup steps, including Identity Management and Fusion Applications components, refer to the components startup section in Chapter 12.

[fusion@fahost ∼]$ cd /app/oracle/instance/nodemanager/fahost/

[fusion@fahost fahost]$ nohup ./startNodeManagerWrapper.sh &

You can monitor the progress in the nohup.out file until you see the following message:

INFO: Secure socket listener started on port 5556

Let’s move the focus back to the Postconfigure phase error. As you saw in Figure 10-21, the CRM postconfigure encountered error while rest of the products postconfigure was successful. We clicked the Retry button and, as shown in Figure 10-22, the Provisioning wizard completed clean and restarted the operation. The Cleanup phase shut down any processes related to the failed product domain. The Restore phase deletes any identity and policy store-related entries for the CRM product and restores only the failed CRM domain directory from the <APPLICATIONS_BASE>/provisioning/restart/backup_configure-secondary/instace.tar backup file.

If the cleanup or restart fails to complete automatically, you may need to resolve any underlying errors followed by running cleanup and restore using the command-line or the wizard. Once Restore is complete, click OK to restart the failed phase. Figure 10-24 shows successful completion of the previously failed target (CRM product domain).

Figure 10-24. Postconfigure phase post-restart screen

Before activating the Next button, the wizard will take a full backup of instance directory and place the instance.tar backup file in the <APPLICATIONS_BASE>/provisioning/restart/backup-postconfigure directory. This will create the following phaseguard files to record the phase status as completed:

postconfigure-<hostname>-COMPLETED.grd

postconfigure-<hostname>-ENDED.grd

Before you proceed to the next phase, take a look at an an example of false errors during the provisioning phase. Figure 10-25 shows an example. This might not occur during your installation.

Figure 10-25. Ignorable errors example

Here you can see that, despite the red mark against various tasks in HCM postconfigure, the phase has not failed and it continues processing. This is due to known flexfield related errors that are not actually “errors” but the Provisioning wizard incorrectly shows them as so. This does not affect the phase at all and installation continues. For example, the demo installation did not face this error. These errors can be ignored and no action is necessary. Although the product family tree node will show the error symbol, the overall postconfigure phase will show a completed status.

Startup Phase

Once the Postconfigure phase is complete on all nodes, click Next in the wizard to proceed to the Startup phase shown in Figure 10-26.

Figure 10-26. Startup phase status screen

After completion of the Postconfigure phase your installation is near complete and there is no further backup taken from here onward. Once the Startup phase has been kicked off from the primordial host, start the same from primary hosts (if available), secondary hosts (if available), and DMZ host (if available) using following command-line interface scripts.

./runProvisioning.sh -responseFile <Response File path> -target startup

[-ignoreSysPrereqs true]

For example:

[fusion@primaryhost ]$ cd /app/fusion/provisioning/bin

[fusion@primaryhost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target startup -ignoreSysPrereqs true

The following important actions are performed during the Startup phase.

• Startup phase essentially brings up all domains administration servers and managed servers including middleware and Application managed servers for the host where the phase is running. Although these servers are supposed to be running from the Postconfigure phase, it does a clean restart of all required servers just in case the host was restarted after successful completion of postconfigure.

• Performs GUID reconciliation to make sure the seeded policies and grants are reconciled between the Oracle Fusion Data Security and policy store.

The actual ANT command executed behind the scenes is as follows.

/app/fusion/provisioning/ant/bin/ant

-f /app/fusion/provisioning/provisioning-build/orchestration-build.xml

-Dresponsefile.input=/app/fusion/provisioning/bin/provisioning.rsp

-Dconfigframework.lib.dir=/app/fusion/provisioning/lib

-Dtools.lib.dir=/app/fusion/provisioning/lib

-logger oracle.apps.fnd.provisioning.ant.taskdefs.util.logger.ProvisioningLogger

-lib /app/fusion/provisioning/lib/oracle-provisioning-antlogger.jar

-lib /app/fusion/provisioning/lib/ojdl.jar

-lib /app/fusion/provisioning/lib/dms.jar

-Dpreverify.ignore true

-Ddebug.timestamp 11_11_14_10_07_32

-Dprovisioning.target startup startup

The following are the important files created during the Startup phase. If you have any issues with the phase you may need to refer to these files for troubleshooting.

Log files: Created at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. For example, /app/oracle/logs/provisioning/plan1415477981901/fahost.

runProvisioning-startup.log

runProvisioning-<product_family>-startup.log

runProvisioning-<product_family>-<managed_server>-startup.log

runProvisioning-startup-logstatus.log

runProvisioning-startup.out

Phaseguards: Created at <APPLICATIONS_BASE>/provisioning/phaseguards. For example, /app/oracle/provisioning/phaseguards. You may notice that there are no product domains related phaseguard files created in this phase. Hence the cleanup and restore are done for complete phase instead of failed product domains.

startup-fahost-STARTED.grd

startup-fahost-ENDED.grd

startup-fahost-COMPLETED.grd

Validate Phase

Once the Startup phase is complete on all hosts, click Next in the wizard to proceed to the Validate phase, as shown in Figure 10-27.

Figure 10-27. Validation phase status screen

Once all the services are started, the installer will proceed to the final phase of provisioning—the Validate phase. You may see the errors shown in Figure 10-27 but be patient since these errors are expected on current release. We will discuss this in a little while. Once the Validate phase has been kicked off from the primordial host, start it from the primary hosts (if available), the secondary hosts (if available), and the DMZ host (if available) using the following command-line interface scripts.

./runProvisioning.sh -responseFile <Response File path> -target validate

[-ignoreSysPrereqs true]

For example,

[fusion@primaryhost ]$ cd /app/fusion/provisioning/bin

[fusion@primaryhost bin]$ ./runProvisioning.sh -responseFile /app/fusion/provisioning/bin/provisioning.rsp -target validate -ignoreSysPrereqs true

The Validate phase does a variety of checks to validate the installation. These checks include application URLs reachability, validation of data sources, and more. Similar to the Preverify phase, the Validate phase also does not stop processing if a particular build target or product domain validation if any errors or warnings are encountered. Instead it keeps track of the errors and displays a consolidated list of errors at the end. Also similar to the Startup phase, this phase needs to be restarted as a whole even when only specific product domains encountered errors.

The actual ANT command executed behind the scenes is as follows.

/app/fusion/provisioning/ant/bin/ant

-f /app/fusion/provisioning/provisioning-build/orchestration-build.xml

-Dresponsefile.input=/app/fusion/provisioning/bin/provisioning.rsp

-Dconfigframework.lib.dir=/app/fusion/provisioning/lib

-Dtools.lib.dir=/app/fusion/provisioning/lib

-logger oracle.apps.fnd.provisioning.ant.taskdefs.util.logger.ProvisioningLogger

-lib /app/fusion/provisioning/lib/oracle-provisioning-antlogger.jar

-lib /app/fusion/provisioning/lib/ojdl.jar

-lib /app/fusion/provisioning/lib/dms.jar

-Dpreverify.ignore false

-Ddebug.timestamp 11_11_14_17_11_07

-Dprovisioning.target validate validate

The following are the important files created during the Configure phase. If you have any issues with the phase, you may need to refer to these files for troubleshooting.

Log files: Created at <APPLICATIONS_BASE>/logs/provisioning/plan<timestamp>/<hostname>. For example, /app/oracle/logs/provisioning/plan1415477981901/fahost:

runProvisioning-validate.log

runProvisioning-validate-logstatus.log

runProvisioning-validate.out

Phaseguards : Created at <APPLICATIONS_BASE>/provisioning/phaseguards. For example, /app/oracle/provisioning/phaseguards. You may notice that there are no product domains related phaseguard files created in this phase. Hence the cleanup and restore are done for the complete phase instead of failed product domains.

validate-fahost-STARTED.grd

validate-fahost-FAILED.grd (if validate phase has failed)

validate-fahost-ENDED.grd (if validate phase is successful)

validate-fahost-COMPLETED.grd (if validate phase is successful)

As of the current release, the Validate phase may encounter some of the known errors as mentioned next. These and a few more expected error messages are documented in the Oracle Support Document ID 1487115.1 and 1404577.1. If there are any other validation errors you must resolve them before proceeding to the Summary phase.

MESSAGE=Failed connecting to http://fahost:7010/integration/worklistapp/faces/login.jspx , Server redirected too many times (20)!DETAIL=Failed connecting to http://fahost:7010/integration/worklistapp/faces/login.jspx , Server redirected too many times (20)

The following error is also ignorable.

The web page http://fahost:7001/em/faces/fa-faLogin;jsessionid=UUk-ZidyFeG2FHkJupePpadc6Jwez7Iy9yk5uqIxxteJK7VQDv_d!-1008637013?target=Farm_CommonDomain&type=oracle_ias_farm&FromContextInitFilter=true does not contain the text, html

After resolving all the validation errors, the Next button on the Provisioning wizard will still not be enabled as the status of the phase is still FAILED. Perform these steps from the command-line to enable the Next button and manually change the phase status to completed successfully.

cd <APPLICATIONS_CONFIG>/phaseguards

rm validate-<host>-FAILED.grd

touch validate-<host>-COMPLETED.grd

The previous command will change the phase status as completed successfully and disable the Retry button. The Next button will still be disabled.

touch validate-<host>-ENDED.grd

The previous command will change the phase status as ended and enable the Next button. For example,

[fusion@fahost ∼]$ cd /app/oracle/provisioning/phaseguards/

[fusion@fahost phaseguards]$ ls -ltr validate-fahost-*

-rwx—— 1 fusion dba 0 Nov 10 13:02 validate-fahost-STARTED.grd

-rwx—— 1 fusion dba 0 Nov 10 14:23 validate-fahost-FAILED.grd

[fusion@fahost phaseguards]$ rm validate-fahost-FAILED.grd

[fusion@fahost phaseguards]$ touch validate-fahost-COMPLETED.grd

[fusion@fahost phaseguards]$ touch validate-fahost-ENDED.grd

Now you can see that the Next button is enabled. Click Next to proceed to the final screen of post-installation summary, as shown in Figure 10-28.

Figure 10-28. Post-installation summary screen

The post-installation summary screen provides vital information about your Fusion Applications environment. The following are the few important details that the screen displays. You need not copy the content manually since once you click Finish, it will create a provisioning summary file that contains this information.

• Disk space information

• Response file details

• Applications transaction database host, port, and service name

• List of products and configurations provisioned

• Details of each domain, respective admin server, each managed server and related ports, URLs, and home directories

• Web tier host detail

• Identity Management environment details

  • Identity Management database host, port, and service name

  • Identity and OPSS policy store details

  • Identity Manager details including host, port, and URLs

  • Access Manager details including host, port, OAM AAA server details, and so on

Once you have reviewed the information, click Finish. This will create a file named provisioning-<timestamp>.summary in the same location as the existing response file and pre-installation summary file. You can back up this file for documentation purposes.

This concludes the provisioning of the Fusion Applications environment.