18 Complete Conditional Common High Availability Post-Installation Tasks for Oracle Fusion Applications

After scaling out the Oracle WebCenter Portal Managed Server, do the following:

Set the location for all persistence stores targeted to the IPM_server1 and IPM_server2 Managed Servers to a directory that is visible from both PROVISIONED_HOST and SCALED_OUT_HOST.

To configure the persistence stores:

Each server has a transaction log which stores information about committed transactions that are coordinated by the server that may not have been completed. Oracle WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence store:

1. Log in to the Oracle WebLogic Server Administration Console (http://commoninternal.mycompany.com/console).

2. In the Change Center, click Lock & Edit.

3. In the Domain Structure window, expand the Environment node and then click the Servers node.

   The Summary of Servers page displays.

4. Click the name of the server (represented as a hyperlink) in the IPM_server1 table. The settings page for the selected server opens with the Configuration tab active.

5. Open the Services tab.

6. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. For example, create a directory

   PROVISIONED_HOST> APPLICATIONS_CONFIG/domains/PROVISIONED_HOST
   /CommonDomain/tlogs
   

7. Click Save.

8. Repeat Steps 1 through 7 for the IPM_server2 Managed Server.

9. Click Activate Changes.

10. Restart the Managed Servers to activate the changes (ensure that Node Manager is up and running):

    1. Log in to the Oracle WebLogic Server Administration Console (http://commoninternal.mycompany.com/console).

    2. In the Summary of Servers screen, select the Control tab.

    3. Select IPM_server1 and IPM_server2 in the table and then click Shutdown.

    4. After the servers have shut down, select IPM_server1 and IPM_server2 in the table and click Start.

• To enable migration of the Transaction Recovery service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both IPM_server1 and IPM_server2 must be able to access this directory.

• Ensure the following the path exists on the machine:

  (Linux) /usr/share/X11/fonts/TTF

  (Solaris) /usr/X11/lib/X11/fonts/TrueType

Ensure that virtual IPs have been enabled on PROVISIONED_HOST and SCALED_OUT_HOST before setting the IPM_server1 and IPM_server2 listen addresses.

To set the listen address for the Managed Servers:

1. Log in to the Administration Console (http://commoninternal.mycompany.com/console).

2. In the Change Center, click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers.

   The Summary of Servers page displays.

5. Select IPM_server1 in the table.

   The Settings page for IPM_server1 Managed Server displays.

6. Set the listen address to COMMONIPMVH1 and click Save.

7. Navigate to the Summary of Servers page and select IPM_server2 in the table.

   The Settings page for the IPM_server2 Managed Server displays.

8. Set the listen address to COMMONIPMVH2 and click Save.

   Both COMMONIPMVH1 and COMMONIPMVH2 are pingable.

9. Click Activate Changes.

   The changes will not take effect until the IPM_server1 and IPM_server2 Managed Servers are restarted. To restart the Managed Servers, do the following:

   1. Ensure that Node Manager is up and running.

   2. On the Summary of Servers page, select the Control tab.

   3. Navigate to the Summary of Servers page, select IPM_server1 andIPM_server2 in the table, and then click Shutdown.

   4. After the servers have shut down, select IPM_server1 and IPM_server2 in the table and click Start.

Perform these steps to add the IPM_server1 and IPM_server2 virtual-host names to the SocketHostNameSecurityFilter parameter list:

Configure the location for the Java Message Service (JMS) file persistence store to a directory visible from both nodes. Change the persistent store to use this shared base directory.

1. Log in to the Administration Console (http://biinternal.mycompany.com/console).

2. In the Domain Structure window, expand the Services node.

3. In the Change Center, click Lock & Edit.

4. Click the Persistent Stores node.

   The Summary of Persistent Stores page displays.

5. Click JRFWSAsyncFileStore and enter a directory that is located in the shared storage. This shared storage is accessible from both BIHOST1 and BIHOST2:

   APPLICATIONS_CONFIG/domains/BIHOST1/BIDomain/JRFWSAsyncFileStore
   

6. Click Save.

7. Click Activate Changes.

   The changes will not take effect until the Managed Server is restarted.

8. Do the following:

   1. Ensure that Node Manager is up and running.

   2. On the Summary of Servers page, select the Control tab.

   3. Select bi_server1 in the table and then click Shutdown.

   4. After the server has shut down, select bi_server1 in the table and then click Start.

9. Run the following commands on BIHOST1 to restart the Oracle Business Intelligence system components:

   UNIX:

   $ cd APPLICATIONS_CONFIG/BIInstance/bin 
   $ ./opmnctl stopall
   $ ./opmnctl startall
   

Make sure that the steps described in Enable Virtual IPs on PROVISIONED_HOST and SCALED_OUT_HOST have been performed before setting the bi_server1 listen address.

To set the listen address for the Managed Server:

1. Log in to the Administration Console (http://biinternal.mycompany.com/console).

2. In the Change Center, click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers. The Summary of Servers page is displayed.

5. Select bi_server1 in the table. The Settings page for bi_server1 is displayed.

6. Set the Listen Address to BIVH1.

   Both BIVH1 and BIVH2 are pingable.

7. Click Save.

8. Click Activate Changes.

9. The changes do not take effect until the bi_server1 Managed Server is restarted (ensure that Node Manager is up and running):

   1. On the Summary of Servers page, select the Control tab.

   2. Select bi_server1 in the table and then click Shutdown.

   3. After the server has shut down, select bi_server1 in the table and then click Start.

10. Restart the Oracle Business Intelligence system components on BIHOST1:

    UNIX:

    $ cd APPLICATIONS_CONFIG/BIInstance/bin 
    $ ./opmnctl stopall
    $ ./opmnctl startall
    

To enable Oracle HTTP Server to route to bi_cluster, which contains the bi_servern Managed Servers, set the WebLogicCluster parameter to the list of nodes in the cluster:

To scale out the Oracle Business Intelligence system:

To start Node Manager in SSL mode:

1. Stop the default Node Manager running on BIHOST2 using one of the following methods:

   • Use CTRL+C in the shell where it was started

   • Use the standard process-identification and kill commands in the operating system appropriate to the product and the Oracle Fusion Applications enterprise deployment.

2. Start Node Manager in SSL mode on BIHOST2:

   UNIX:

   BIHOST2> cd APPLICATIONS_CONFIG/nodemanager/BIHOST2
   BIHOST2> ./startNodeManagerWrapper.sh &
   

3. Update the Node Manager for the BIHOST2 machine using the Oracle WebLogic Server Console by doing the following:

   1. Log in to the Administration Server: http://biinternal.mycompany.com/console.

   2. Navigate to BIDomain, Environment, Machines.

   3. In the left-hand pane, click Lock & Edit.

   4. In the right-hand pane, click BIHOST2.

   5. In the window that opens, click the Node Manager tab and set the following attributes:

      – Type - SSL

      – Listen Address - <BIHOST2>

      – Listen Port - 5556

4. Click Save and then Activate Changes.

   The changes will not take effect until the bi_server2 Managed Server is restarted.

5. Do the following:

   1. Stop the Administration Server:

      UNIX:

      BIHOST1> APPLICATIONS_CONFIG/domains/BIHOST1/BIDomain/bin/stopWebLogic.sh
      

   2. Connect to the Administration Server through nmConnect and start the Administration Server using nmstart.

      – Set the following environment variable:

      UNIX:

      export WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=
      APPLICATIONS_CONFIG/keystores/fusion_trust.jks"
      

      – Start the Administration Server:

      UNIX:

      BIHOST1> cd APPLICATIONS_BASE/fusionapps/
      wlserver_10.3/common/bin
      
      BIHOST1> ./wlst.sh
      

      – In the WLST shell, execute the following command:

      wls:/offline> nmConnect (username='Admin_User',password='Admin_
      Password',host='BIHOST1',port='5556', nmType='ssl', domainDir=
      'APPLICATIONS_CONFIG/domains/BIHOST1/BIDomain')
      
      wls:/nm/domain_name> nmStart ('AdminServer')
      wls:/nm/domain_name> exit ()
      

      The username and password used in nmConnect are the Node Manager credentials (user name and password) specified when creating the provisioning response file.

   3. Restart the bi_server2 Managed Server:

      – On the Summary of Servers page, select the Control tab.

      – Select bi_server2 in the table and then click Shutdown.

      – After the server has shut down, select bi_server2 in the table and then click Start.

To scale out the system components, do the following in Oracle Enterprise Manager Fusion Middleware Control:

Restart is not needed at this point, because a restart is performed after completing the steps in Configure Secondary Instances of Singleton Components.

Oracle Business Intelligence Scheduler and Oracle Business Intelligence Cluster Controller are singleton components that operate in active/passive mode. Configure a secondary instance of these components so that they are distributed for high availability.

To configure secondary instances, do the following in Fusion Middleware Control:

This section explains what to do to configure the bi_server2 Managed Server.

Setting the Listen Address for the bi_server2 Managed Server

Make sure that the steps described in Enable Virtual IPs on PROVISIONED_HOST and SCALED_OUT_HOST have been performed before setting the bi_server2 listen address.

To set the listen address for the Managed Server:

1. Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

2. In the Change Center, click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers. The Summary of Servers page is displayed.

5. Select bi_server2 in the table. The settings page for bi_server2 is displayed.

6. Set the Listen Address to BIVH2.

7. Click Save.

8. Click Activate Changes.

   The changes will not take effect until the Managed Server is restarted.

9. Do the following:

   1. Ensure that Node Manager is up and running.

   2. On the Summary of Servers page, select the Control tab.

   3. Select bi_server2 in the table and then click Shutdown.

   4. After the server has shut down, select bi_server2 in the table and then click Start.

Configuring Custom Identity and Custom Trust for the bi_server2 Managed Server

To configure custom identity and custom trust:

1. Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

2. In the Change Center, click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers.

   The Summary of Servers page displays.

5. Select bi_server2 in the table. The Settings page for bi_server2 displays.

6. Click Keystores, and then do the following:

   1. Click Change next to Demo Identity and Demo Trust.

   2. Select Custom Identity and Custom Trust from the Keystores dropdown list and click Save.

   3. Under Identity, do the following:

      – Change the Custom Identity Keystore entry to point to the APPLICATIONS_CONFIG/keystores/BIHOST2_fusion_identity.jks file.

      – Enter and confirm the Custom Identity Keystore Passphrase.

   4. Under Trust, do the following:

      – Change the Custom Identity Keystore entry to point to the APPLICATIONS_CONFIG/keystores/fusion_trust.jks file.

      – Enter and confirm the Custom Trust Keystore Passphrase.

      – Click Save.

7. Click SSL, and then do the following:

   1. Ensure that Identity and Trust Locations is set to Keystores.

   2. Under Identity, do the following:

      – Change the Private Key Alias to BIHOST2_fusion.

      – Enter and confirm the Private Key Passphrase to the keypassword.

      – Click Save.

8. Click Activate Changes.

9. (UNIX) Set the following property in APPLICATIONS_BASE/fusionapps/wlserver_10.3/common/bin/wlst.sh:

   WLST_PROPERTIES=" -Dweblogic.wlstHome='${WLST_HOME}'  
   -Dweblogic.security.SSL.trustedCAKeyStore=APPLICATIONS_CONFIG/keystores/
   fusion_trust.jks ${WLST_PROPERTIES}"
   

Disabling Host Name Verification for the bi_server2 Managed Server

This step is required if the appropriate certificates have not been set up to authenticate the different nodes with the Administration Server. If the server certificates have not been configured, errors are displayed during the management of the different WebLogic servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again after the topology configuration is complete.

To disable host name verification:

1. Log in to Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers. The Summary of Servers page is displayed.

5. Select bi_server2 in the table. The settings page for the server is displayed.

6. Click the SSL tab.

7. Expand the Advanced section of the page.

8. Set Host Name Verification to None.

9. Click Save.

10. Click Activate Changes.

11. The change will not take effect until the bi_server2 Managed Server is restarted (make sure that Node Manager is up and running):

    1. In the Summary of Servers screen, select the Control tab.

    2. Select bi_server2 in the table and then click Shutdown.

    3. Select bi_server2 in the table and then click Start.

12. Restart the Oracle Business Intelligence system components on BIHOST2:

    UNIX:

    $ cd APPLICATIONS_CONFIG/BIInstance1/bin
    $ ./opmnctl stopall
    $ ./opmnctl startall
    

Adding bi_server2 System Properties to the Server Start Tab

After scaling out the bi_server2 Managed Server, add a new system property to the Server Start tab of this Managed Server.

1. Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers.

   The Summary of Servers page displays.

5. Select bi_server2 in the table.

   The settings page for the server displays.

6. Click Server Start.

7. Add the following property to the arguments:

   -DJDBCProgramName=DS/BIDomain/bi_server2
   

8. Click Save and then Activate Changes.

9. Restart the bi_server2 Managed Server (ensure sure that Node Manager is up and running):

   1. In the Summary of Servers screen, select the Control tab.

   2. Select bi_server2 in the table and then click Shutdown.

   3. Select bi_server2 in the table and then click Start.

10. Restart the BI System Components on BIHOST2:

    UNIX:

    $ cd APPLICATIONS_CONFIG/BIInstance1/bin
    $ ./opmnctl stopall
    $ ./opmnctl startall
    

This section describes additional high availability configuration tasks for Oracle BI Enterprise Edition, Oracle Real-Time Decisions, Oracle BI Publisher, and Oracle Financial Reports.

Additional Configuration Tasks for Oracle BI Scheduler

If server-side scripts are used with Oracle BI Scheduler, it is recommended to configure a shared directory for the scripts so that they can be shared by all Oracle BI Scheduler components in a cluster.

Perform these steps only if server-side scripts are used.

To share Oracle BI Scheduler scripts:

1. Create an APPLICATIONS_CONFIG/BIShared/OracleBISchedulerComponent/coreapplication_obisch1 directory.

2. From BIHOST1, copy the default Oracle BI Scheduler scripts (for example, APPLICATIONS_CONFIG/BIInstance/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common) and custom Oracle BI Scheduler scripts (for example, APPLICATIONS_CONFIG /BIInstance/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler) to the following location:

   APPLICATIONS_CONFIG/BIShared/OracleBISchedulerComponent/coreapplication_obisch1

3. Update the SchedulerScriptPath and DefaultScriptPath elements of the Oracle BI Scheduler instanceconfig.xml file, as follows:

   • SchedulerScriptPath: Refers to the path where Oracle BI Scheduler-created job scripts are stored. Change this to the path of the shared BI Scheduler scripts location.

   • DefaultScriptPath: Specifies the path where user-created job scripts (not agents) are stored. Change this to the path of the shared BI Scheduler scripts location.

   The instanceconfig.xml files for Oracle BI Scheduler are in the following locations:

   On BIHOST1:: APPLICATIONS_CONFIG/BIInstance/config/OracleBISchedulerComponent/coreapplication_obisch1

   On BIHOST2: APPLICATIONS_CONFIG /BIInstance1/config/OracleBISchedulerComponent/coreapplication_obisch1

   Update these files for each Oracle BI Scheduler component in the deployment.

4. Restart the Oracle BI Scheduler component.

   On BIHOST1:

   UNIX:

   $ cd APPLICATIONS_CONFIG/BIInstance/bin
   $ ./opmnctl stopproc 
   ias-component=coreapplication_obisch1
   $ ./opmnctl startproc 
   ias-component=coreapplication_obisch1
   

   On BIHOST2:

   UNIX:

   $ cd APPLICATIONS_CONFIG/BIInstance1/bin
   $ ./opmnctl stopproc 
   ias-component=coreapplication_obisch1
   $ ./opmnctl startproc 
   ias-component=coreapplication_obisch1
   

Additional Configuration Tasks for Oracle Real-Time Decisions

This sections contains information about the following:

• Configuring Oracle Real-Time Decisions clustering

• Adding Oracle RTD system properties to the server start tab

Configuring Oracle Real-Time Decisions Clustering Properties

Perform these steps in Fusion Middleware Control to set up cluster-specific configuration properties for Oracle Real-Time Decisions (Oracle RTD). It is only necessary to perform the steps on one of the nodes in the deployment. It is not necessary to set cluster-specific configuration properties for Oracle RTD for subsequent nodes.

1. Log in to Fusion Middleware Control (http://biinternal.mycompany.com/em).

2. Expand the Application Deployments node in the Farm_BIDomain window.

3. Expand Oracle RTD(11.1.1)(bi_cluster).

4. Click any node under it. For example, Oracle RTD(11.1.1)(bi_server1).

5. In the right pane, click Application Deployment, and then select System MBean Browser.

6. In the System MBean Browser pane, expand Application Defined MBeans.

7. For any one of the servers under Oracle RTD, navigate to the MBean and set the attribute, as shown in the following table. Other servers automatically get updated with the value that is set.

   Table 18-2 Oracle RTD MBean Attributes and Values for Clustering

   MBean	Attribute	Value
   SDClusterPropertyManager -> Misc	DecisionServiceAddress	http://biinternal.mycompany.com

8. Click Apply.

Adding Oracle RTD System Properties to the Server Start Tab

After scaling out Oracle RTD, use the Administration Console to add three system properties to the Server Start tab of each Managed Server.

1. Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers.

   The Summary of Servers page displays.

5. Select bi_server<1,2> in the table.

   The settings page for the server displays.

6. Click Server Start.

7. Add the following property to the arguments:

   -Drtd.clusterRegistryJobIntervalMs=12000
   -Drtd.clusterDepartureThresholdMs=50000
   -Drtd.clusterDepartureThreshold2Ms=50000
   

8. Click Save and then Activate Changes.

9. Restart the bi_server<1,2> Managed Server (ensure sure that Node Manager is up and running):

   1. In the Summary of Servers screen, select the Control tab.

   2. Select bi_server<1,2> in the table and then click Shutdown.

   3. Select bi_server<1,2> in the table and then click Start.

10. Restart the BI System Components on BIHOST1 and BIHOST2:

    UNIX:

    $ cd APPLICATIONS_CONFIG/BIInstancen/bin
    $ ./opmnctl stopall
    $ ./opmnctl startall
    

Performing this task enables an instance of Oracle RTD to be migrated successfully from one host to another in the event of a failure of a Managed Server.

Even after these changes, if the server migration finishes in less than 50 seconds, the Oracle RTD batch framework is in an inconsistent state.

If the enterprise has deployed any RTD Inline Services that host Batch Job implementations, and if after a server migration the batch console command, "batch-names", or its brief name, "bn", shows no registered batch jobs, then the Oracle RTD Batch Manager service must be stopped and restarted. To do this, perform these steps:

1. In Fusion Middleware Control, expand the WebLogic Domain node in the left pane. Then, right-click BIDomain and select System MBean Browser.

2. Locate SDPropertyManager, Misc MBean under Application Defined MBeans, OracleRTD, Server:bi_server n.

   Be sure to select the Misc MBean that corresponds to the local node where the change is being made. For example, in case of connecting to APPHOST1, then make sure to update the attribute associated with bi_server1.

3. Set the BatchManagerEnabled attribute to false and click Apply.

4. Set the BatchManagerEnabled attribute back to true and click Apply. Performing this task causes the Batch Manager to stop and be restarted.

   When it restarts, it runs on either the same server as before, or on a different server.

5. After restarting Batch Manager, note that the corresponding MBean does not always immediately get refreshed on the server where Batch Manager comes back up, so this is not a concern. Instead, verify that Batch Manager is now operational by using the Batch Console tool:

   1. Locate the zip file for the Oracle RTD client tools in the following location:

      APPLICATIONS_BASE/fusionapps/bi/clients/rtd/rtd_client_11.1.1.zip
      

   2. Because most Oracle RTD client tools do not run on UNIX, unzip this file in a location on a Windows machine (referred to here as RTD_HOME). Then, locate the batch console jar file in:

      RTD_HOME/client/Batch/batch-console.jar
      

   3. Change to this directory and execute the jar, passing to it the URL and port of either the Managed Server, or of the cluster proxy:

      java -jar batch-console.jar -url http://SERVER:PORT
      

   4. When prompted, enter the user name and password of a user who is a member of the Administrator role, BI_Adminstrator role, or some other role authorized to administer Oracle RTD batch jobs.

   5. When prompted for a command, enter bn:

      Checking server connection...
      command: bn
          CrossSellSelectOffers
      command:quit
      

      If Batch Manager has successfully restarted, then the bn command lists the names of all batch implementations hosted by all deployed RTD Inline Services.

      The commonly deployed example, CrossSell, hosts a batch implementation named CrossSellSelectOffers, shown in the preceding example.

Additional Configuration Tasks for Oracle BI Publisher

Perform the steps in this section on each machine where Oracle BI Publisher is configured.

Configuring Integration with Oracle BI Presentation Services

To configure Oracle BI Publisher integration with Oracle BI Presentation Services:

1. Log in to Oracle BI Publisher (http://biinternal.mycompany.com/xmlpserver) with Administrator credentials and select the Administration tab.

2. Under Integration, select Oracle BI Presentation Services.

3. Verify and update the following:

   • Server Protocol: http

   • Server: biinternal.mycompany.com

   • Port: 80

   • URL Suffix: analytics-ws/saw.dll

4. Click Apply.

5. Under System Maintenance, select Server Configuration.

   In the Catalog section, change the BI Publisher Repository value to the shared location for the Configuration Folder. For example:

   APPLICATIONS_CONFIG/BIShared/BIPublisher/repository
   

6. Click Apply.

7. Restart the Oracle BI Publisher application:

   1. Log in to the Administration Console (http://biinternal.mycompany.com/console).

   2. Click Deployments in the Domain Structure window.

   3. Select bipublisher(11.1.1).

   4. Click Stop, and then select When Work Completes or Force Stop Now.

   5. After the application has stopped, click Start and then Start Servicing All requests.

Setting the Oracle BI Enterprise Edition Data Source

The Oracle BI EE Data Source must point to the clustered Oracle BI Servers through the Cluster Controllers. Perform this task in Oracle BI Publisher.

To set the Oracle BI EE data source in Oracle BI Publisher:

1. Log in to Oracle BI Publisher (http://biinternal.mycompany.com/xmlpserver) with Administrator credentials and select the Administration tab.

2. Under Data Sources, select JDBC Connection.

3. Update the Oracle BI EE data source setting by changing the Connection String parameter to the following:

   jdbc:oraclebi://primary_cluster_controller_host:primary_cluster_controller_
   port/PrimaryCCS=primary_cluster_controller_host;PrimaryCCSPort=primary_cluster_
   controller_port;SecondaryCCS=secondary_cluster_controller_host;
   SecondaryCCSPort=secondary_cluster_controller_port;
   

   For example:

   jdbc:oraclebi://BIHOST1:10212/PrimaryCCS=BIHOST1;PrimaryCCSPort=10212;
   SecondaryCCS=BIHOST2;SecondaryCCSPort=10212;
   

   Since the Cluster Controller Port may be different between BIHOST1 and BIHOST2, use the following procedure to check the port being used:

   1. Log in to the Oracle Enterprise Manager Console: http://biinternal.mycompany.com/em.

   2. Expand Farm_Domain, Business Intelligence, coreapplication.

   3. Navigate to Availability.

   4. Check the port number used by the Cluster Controller on BIHOST1 and BIHOST2.

4. Do one of the following:

   • Select Use System User.

   • Deselect Use System User and specify BIImpersonateUser credentials.

   See Credentials for Connecting to the Oracle BI Presentation Catalog in Oracle Fusion Middleware Developer's Guide for Oracle Business Intelligence Enterprise Edition.

5. Click Test Connection. A "Connection established successfully" message should be received.

6. Click Apply.

Configuring Java Message Service for Oracle BI Publisher

Configure the location for the persistence store to the Oracle Fusion Applications database.

On BIHOST2:

1. Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

2. In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page is displayed.

3. Click Lock & Edit.

4. Click New, and then Create JDBCStore.

5. Enter a name (for example, BipJDBCStore-bi_server2) and target (for example, bi_server2). Select bip_datasource as the data source, and enter Bip_bi_server2_ as the prefix name.

6. Click OK and then Activate Changes.

7. In the Domain Structure window, expand the Services node and then click the Messaging, JMS Servers node. The Summary of JMS Servers page is displayed.

8. Click Lock & Edit.

9. Click New.

10. Enter a name (for example, BipJmsServer-bi_server2) and in the Persistence Store drop-down list, select BipJDBCStore-bi_server2 and click Next.

11. Select bi_server2 as the target.

12. Click Finish and Activate Changes.

13. In the Domain Structure window, expand the Services node and then click the Messaging, JMS Modules node. The JMS Modules page is displayed.

14. In the Change Center, click Lock & Edit.

15. Click BipJmsResource and then click the Subdeployments tab.

16. Select BipJmsSubDeployment under Subdeployments.

17. Add the new Oracle BI Publisher JMS Server (BipJmsServer-bi_server2) as an additional target for the subdeployment.

18. Click Save and then Activate Changes.

To validate, do the following:

1. Log in to each Oracle BI Publisher URL.

2. Navigate to Administration, System Maintenance, Scheduler Diagnostics.

   All statuses should be in a Passed state and both instances should be visible.

Additional Configuration Tasks for Oracle Business Intelligence for Microsoft Office

The information in this section tells how to do the following:

• Configure Oracle Business Intelligence for Microsoft Office properties

• Validate Oracle Business Intelligence for Microsoft Office

Configuring Oracle Business Intelligence for Microsoft Office Properties

To perform additional configuration tasks for Oracle Business Intelligence for Microsoft Office:

1. Validate the Oracle BI Enterprise Edition Office Server setup by accessing http://biinternal.mycompany.com/bioffice/about.jsp.

   The About Oracle BI EE Office Server page displays.

2. Go to the Oracle BI Enterprise Edition Office Server directory. For example:

   APPLICATIONS_CONFIG/domains/BIHOST1/BIDomain/servers/bi_server1/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INF

   To locate the Oracle BI Enterprise Edition Office Server directory, check the LogDir parameter on the About Oracle BI EE Office Server page. The Oracle BI Enterprise Edition Office Server directory is the parent directory of the log directory.

   Determine the exact location for BIHOSTn by using the following URL: http://BIVHn:10217/bioffice/about.jsp.

3. On bothBIHOST1 and BIHOST2, open bioffice.xml for editing and modify the BI Office properties shown in the following table.

   Table 18-3 BI Office Properties in bioffice.xml

   Property Name	Valid Value	Description
   SawBaseURL	http://biinternal.mycompany.com/analytics/saw.dll or http://biinternal.mycompany.com/analytics-ws/saw.dll	Load Balancer Virtual Server Name URL for Oracle BI Presentation Services. Important: If SSO is enabled, then enter the URL for the protected analytics servlet deployed when configuring BI Office to integrate with the SSO-enabled Oracle BI Server. The URL that is specified for this property is used for Web services requests between the BI Office Server and Presentation Services.
   SawUseSSO	0 = No (Default) 1 = Yes	Set this property to 1 if the Oracle Business Intelligence implementation is enabled for SSO.
   SawWebURLforSSO	http://biinternal.mycompany.com/analytics/saw.dll	When SSO is enabled, use this property to enter the public URL that allows external users to access Oracle Business Intelligence using SSO from the Oracle BI Add-in for Microsoft Office.

4. Restart the BI Office application:

   1. Log in to the Administration Console (http://biinternal.mycompany.com/console).

   2. Click Deployments in the Domain Structure window.

   3. Select bioffice(11.1.1).

   4. Click Stop.

   5. After the application has stopped, click Start.

5. Validate that the SawBaseURL parameter has been updated on the About Oracle BI EE Office Server page.

Validating Oracle Business Intelligence for Microsoft Office

To validate configuration for Oracle Business Intelligence for Microsoft Office:

1. Log in to Oracle BI Presentation Services at:

   http://biinternal.mycompany.com/analytics

2. In the lower left pane, under the Get Started heading, select Download BI Desktop Tools and then select Oracle BI for MS Office.

3. Install Oracle BI for Microsoft by running the Oracle BI Office InstallShield Wizard.

4. Open Microsoft Excel or Microsoft PowerPoint.

5. From the Oracle BI menu, select Preferences.

6. In the Connections tab, select New.

7. Enter values for the following fields:

   • Server Name: Provide a name for the connection.

   • BI Office Server: Provide the URL for the Oracle BI Office Server.

   • Application Name: Enter the Application Name defined for the Oracle BI Office Server when the Oracle BI Office Server application was deployed to Oracle WebLogic Server. The default name is bioffice.

   • Port: Enter the Oracle BI Office Server port number.

   The following figure shows the New Connection dialog.

   Figure 18-1 New Connection Dialog for Oracle BI Office

   

8. Click Test Connection to test the connection between the add-in and the Oracle BI Office Server.

   Successful connections receive a "Test connection successful" message, as shown in the following figure.

   Figure 18-2 Test Connection Successful Message

   

9. Log in as an Administrator (for example, weblogic) and validate that it is possible to access the Oracle BI Task Pane, as shown in the following figure.

   Figure 18-3 Oracle BI Task Pane in Microsoft Excel

   

Additional Configuration Tasks for Oracle Financial Reporting

There are additional configuration tasks to perform for Oracle Financial Reporting. Do the following on BIHOST1 and BIHOST2:

1. Update the VARIABLE_VALUE_LIMIT from 4096 to 3072000 in the NQSConfig.INI file. For example,

   VARIABLE_VALUE_LIMIT = 3072000; 
   

   On BIHOST1, this file is located in APPLICATIONS_CONFIG/BIInstance/config/OracleBIServerComponent/coreapplication_obis1.

   On BIHOST2, this file is located in APPLICATIONS_CONFIG/BIInstance1/config/OracleBIServerComponent/coreapplication_obis1.

2. Run the following commands to restart the Oracle Business Intelligence system components on BIHOST1 and BIHOST2:

   UNIX:

   $ cd APPLICATIONS_CONFIG/BIInstancen/bin
   $ ./opmnctl stopall
   $ ./opmnctl startall
   

Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The Oracle WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction logs in the Oracle Fusion Applications database.

To set the location for the default persistence store:

1. Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

2. In the Change Center, click Lock & Edit.

3. In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page is displayed.

4. Click bi_server2 in the table. The Settings page for the selected server is displayed, and defaults to the Configuration tab.

5. Navigate to Configuration > Services.

6. In the Transaction Log Store section of the page, do the following:

   • For the type, select JDBC from the dropdown list. list.

   • For the data store, select bip_datasource from dropdown list.

   • For the prefix name, enter TLOG_bi_server2_.

7. Click Save.

8. Click Activate Changes.

9. Restart bi_server2 to activate the changes:

   1. Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

   2. In the Summary of Servers screen, select the Control tab.

   3. Select bi_server2 in the table and then click Shutdown.

   4. Start the bi_server2 server.

   5. Restart the Oracle Business Intelligence system components on BIHOST2:

      UNIX:

      $ cd APPLICATIONS_CONFIG/BIInstance1/bin
      $ ./opmnctl stopall
      $ ./opmnctl startall
      

This information in this section tells how to do the following:

• Start the bi_server2 Managed Server

• Start the Oracle Business Intelligence system components

• Validate Oracle Business Intelligence URLs

Starting the bi_server2 Managed Server

To start the bi_server2 Managed Server:

1. Start the bi_server2 Managed Server using the Oracle WebLogic Server Administration Console, as follows:

   1. Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console).

   2. Expand the Environment node in the Domain Structure window.

   3. Select Servers. The Summary of Servers page is displayed.

   4. Click the Control tab.

   5. Select bi_server2 and then click Start.

2. Verify that the server status is reported as Running in the Administration Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors.

Starting the Oracle Business Intelligence System Components

Control Oracle Business Intelligence system components using opmnctl commands.

To start the Oracle Business Intelligence system components using the opmnctl command-line tool:

1. Go to the directory that contains the Oracle Process Manager and Notification Server command-line tool, located in APPLICATIONS_CONFIG/BIInstance1/bin.

2. Run the opmnctl command to start the Oracle Business Intelligence system components

   • (UNIX)./opmnctl startall: Starts Oracle Process Manager and Notification Server and all Oracle Business Intelligence system components

   • (UNIX)./opmnctl start: Starts Oracle Process Manager and Notification Server only

   • (UNIX)./opmnctl startproc ias-component=component_name: Starts a particular system component. For example, where coreapplication_obips1 is the Presentation Services component:

     UNIX:

     ./opmnctl startproc ias-component=coreapplication_obips1
     

3. Check the status of the Oracle Business Intelligence system components:

   UNIX:

   ./opmnctl status
   

   UNIX:

   opmnctl status
   

Validating Oracle Business Intelligence URLs

Access the following URLs:

• Access http://BIVH2:10217/analytics to verify the status of bi_server2.

• Access http://BIVH2:10217/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data is displayed.

  WARNING: The configuration is incorrect if no policies or assertion templates appear.

• Access http://BIVH2:10217/xmlpserver to verify the status of the Oracle BI Publisher application.

• Access http://BIVH2:10217/ui to verify the status of the Oracle Real-Time Decisions application.

• Access http://BIVH2:10217/mapviewer to verify the status of the map view functionality in Oracle BI EE.

• Access http://BIVH2:10217/hr to verify Financial Reporting.

• Access http://BIVH2:10217/calcmgr/index.htm to verify Calculation Manager.

• Access http://BIVH2:10217/aps/Test to verify APS.

• Access http://BIVH2:10217/workspace to verify workspace.

Verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to bi_cluster. Perform these steps to verify the URLs:

Oracle recommends using host name verification for the communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses communicating with the Administration Server and other servers. See Scale Out Node Manager. for further details. The procedures in that section must be performed twice using the information provided in the following table.

If Node Manager is configured for the Managed Servers earlier, it is not necessary to configure it again.

Server migration is required for proper failover of the Oracle BI Publisher components in the event of failure in any of the BIHOST1 and BIHOST2 nodes. See Set Up Server Migration for Oracle Fusion Applications.

To add a Managed Server (SCALED_UP_MGD_SERVER) and assign it to SCALED_UP_HOST:

1. Log in to the Administration Server: http://domain_nameinternal.mycompany.com/console.

2. Navigate to Domain_Name ,Environment, Servers.

3. Switch to Lock & Edit mode.

4. Select the SCALED_UP_MGD_SERVER checkbox and then click Clone.

5. Specify the following Server Identity attributes:

   • Server Name - SCALED_UP_MGD_SERVER_n

     To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Increase the number of instances of SCALED_UP_MGD_SERVER by one and use that number to replace "n" at the end of the server name. Oracle recommends following the managed server naming convention NamedManagedServer_n.

   • Server Listen Address - <SCALED_UP_HOST> (This is the existing host where the new instance of SCALED_UP_MGD_SERVER is added.)

   • Server Listen Port - Give an unused port on the machine SCALED_UP_HOST

6. Click OK.

7. Navigate back to Domain_Name, Environment, Servers. See the newly cloned server, SCALED_UP_MGD_SERVER_n.

8. From SCALED_UP_MGD_SERVER_n, click Advanced and then select the WebLogic Plug-In Enabled checkbox.

9. Click Save and then click Activate Changes.

10. Run the newly created Managed Server:

    1. Navigate to Domain_Name, Environment.

    2. From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.

    3. Navigate to Domain_Name, Environment, Servers, Control.

    4. Check the newly created Managed Server and click Start.

    5. Navigate to Domain_Name, Environment, Servers and check the State to verify that the newly created Managed Server is running.

11. Log in to the Administration Server once again (http://domain_nameinternal.mycompany.com/console) and verify that all the Managed Servers, including the new instance of the scaled-up Managed Server, are running.

12. Do the following:

    1. Switch to Lock & Edit mode.

    2. Select the SCALED_UP_MGD_SERVER checkbox.

    3. Select the Server Start tab.

    4. Change the Arguments to reflect the name of the cloned Managed Server and make sure the server group is the correct cluster name. For example, the following should be seen:

       -DJDBCProgramName\=DS/domain_name/SCALED_UP_MGD_SERVER_n
       -Dserver.group\=SCALED_UP_MGD_SERVERCluster
       

       The naming convention of a SCALED_UP_MGT_SERVER_CLUSTER is the name of the managed server appended with "Cluster" after dropping "Server_n". For example, if SCALED_UP_MGD_SERVER_n is HomePageServer_4, its cluster (that is, server group) is HomePageCluster.

    5. Click Save.

13. Select the Logging tab, and then select the HTTP tab.

14. Do the following:

    1. Change the Log file name to logs/access.log.%yyyyMMdd%.

    2. Change the rotation type to By Time.

    3. Leave the Limit number of retained files option unchecked.

    4. Leave the Rotate log file on startup option unchecked.

    5. Click Save.

    6. Expand Advanced.

    7. Change the format to Extended.

    8. Change the extended logging format fields to the following:

       date time time-taken cs-method cs-uri 
       sc-status sc(X-ORACLE-DMS-ECID) 
       cs(ECID-Context) cs(Proxy-Remote-User) 
       cs(Proxy-Client-IP)
       

    9. Click Save.

15. Click Activate Changes.

16. Restart the SCALED_UP_MGD_SERVER_n for the changes to take affect.

Verify URLs to ensure that the appropriate routing and failover are working.

To verify the URLs:

1. Log in to the domain's Oracle WebLogic Server Administration Console and stop all the instances of SCALED_UP_MGD_SERVER currently running in SCALED_UP_HOST, PROVISIONED_HOST, and SCALED_OUT_HOST, where applicable. (Also stop SCALED_UP_MGD_SERVER_n that are just added.)

2. Do the following:

   1. Edit the FusionVirtualHost_domain.conf file where domain takes the value of fs (Common domain), crm, fin, hcm, ic, scm, and so on, depending on the domain used.

      If the SCALED_UP_HOST's host and port do not already exist in the SCALED_UP_MGT_SERVER entry, complete Steps b and c. Otherwise, skip to Step 3.

   2. Locate the name (in lower case) of the scaled-up Managed Server in the file. Add the value SCALED_UP_HOST:port to the WebLogicCluster property. Note that there are two parts, internal and external, in the FusionVirtualHost_domain.conf file on WEBHOST. The SCALED_UP_HOST:port must be added to both the internal and external parts. If scaling out web tier to WEBHOST2 and others, do the same on these hosts as well.

      The following is an example of scaling up the HomePage Managed Server, and what the SCALED_UP_HOST:port looks like in the <Location> xml element in the FusionVirtualHost_fs.conf file

      <Location /homepage>
         SetHandler weblogic-handler
         WebLogicCluster <PROVISIONED_HOST:port>,<SCALED_UP_HOST:port>,
         <SCALED_OUT_HOST:port>
         WLProxySSL ON
         WLProxySSLPassThrough ON
         RewriteEngine On
         RewriteOptions inherit
      </Location>
      

   3. Restart Oracle HTTP Server on both WEBHOST1 and all other web-tier hosts, where applicable.

3. Log in to the domain's Oracle WebLogic Server Administration Console and start the SCALED_UP_MGD_SERVER_n Managed Server. Begin with n=1.

4. Access the URL of the application deployed to the SCALED_UP_MGD_SERVER from a different machine to verify that routing and failover are functioning properly.

   Close all browser windows then open a new one to ensure that the Oracle Fusion Applications login window displays correctly. The URL for the HomePage Managed Server for example, is:

   https://domainexternal.mycompany.com/homePage/faces/AtkHomePageWelcome

5. Log in to the domain's Oracle WebLogic Server Administration Console and stop the SCALED_UP_MGD_SERVER_n Managed Server started in Step 3.

6. Repeat Steps 3 through 5 for the other instances of the SCALED_UP_MGD_SERVER.

7. After completing validation, start all instances of SCALED_UP_MGD_SERVER.

To add a Managed Server and assign it to SCALED_UP_HOST:

1. Log in to the Administration Server: http://domain_nameinternal.mycompany.com/console.

2. Navigate to Domain_Name, Environment, Servers.

3. Switch to Lock & Edit mode.

4. Select the Managed_Servers checkbox (for example, soa_server1) and then click Clone.

5. Specify the following Server Identity attributes:

   • Server Name - soa_servern

     To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Increase the total number of instances of soa_server in this domain by one and use that number to replace n at the end of the server name. Oracle recommends following the Oracle SOA Suite server naming convention soa_servern.

   • Server Listen Address - <SCALED_UP_HOST>

   • Server Listen Port - Give an unused port on the machine SCALED_UP_HOST

6. Click OK.

7. Navigate back to Domain_Name. See the newly cloned SOA server, soa_servern.

8. Do the following:

   1. Click soa_servern.

   2. From the General tab, select Advanced and then select the WebLogic Plug-In Enabled checkbox.

9. Click Save and then Activate Changes.

10. Run the newly created Managed Servers:

    1. Navigate to Domain_Name.

    2. From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.

    3. Navigate to Domain_Name.

    4. Check the newly created Managed Servers and click Start.

    5. Navigate to Domain_Name and check the State to verify that the newly created Managed Servers are running.

11. Log in to the Administration Server once again (http://domain_nameinternal.mycompany.com/console) and verify that all the Managed Servers, including scaled-up servers, are running.

12. Do the following:

    1. Switch to Lock & Edit mode.

    2. Select the Managed_Server checkbox (for example, soa_servern).

    3. Select the Server Start tab.

    4. Change the Arguments to reflect the name of the cloned Managed Server and make sure the server group is the correct cluster name. For example, the following should be seen:

       -DJDBCProgramName\=DS/CommonDomain/soa_servern
       -Dserver.group\=SOACluster
       

    5. Click Save.

13. Select the Logging tab, and then select the HTTP tab.

14. Do the following:

    1. Change the Log file name to logs/access.log.%yyyyMMdd%.

    2. Change the rotation type to By Time.

    3. Leave the Limit number of retained files option unchecked.

    4. Leave the Rotate log file on startup option unchecked.

    5. Click Save.

    6. Expand Advanced.

    7. Change the format to Extended.

    8. Change the extended logging format fields to the following:

       date time time-taken cs-method cs-uri 
       sc-status sc(X-ORACLE-DMS-ECID) 
       cs(ECID-Context) cs(Proxy-Remote-User) 
       cs(Proxy-Client-IP)
       

    9. Click Save.

15. Click Activate Changes.

16. Restart the Managed Server for the changes to take affect.

Verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to the domain's SOACluster.

To verify the URLs:

1. Log in to the domain's Oracle WebLogic Server Administration Console and stop all the instances of soa_server currently running in SCALED_UP_HOST, PROVISIONED_HOST, and SCALED_OUT_HOST, where applicable. (Also stop soa_servern that are just added.)

2. Do the following:

   1. Edit the FusionVirtualHost_domain.conf file where domain takes the value of fs (Common domain), crm, fin, hcm, ic, scm, and so on, depending on the domain used.

      If the SCALED_UP_HOST's host and port do not already exist in the/soa/composer entry, complete Steps b and c. Otherwise, skip to Step 3.

   2. Locate/soa/composer in the file. Add the value SCALED_UP_HOST:port to the WebLogicCluster property. Note that there are two parts, internal and external, in the FusionVirtualHost_domain.conf file on WEBHOST. The SCALED_UP_HOST:port must be added to both the internal and external parts. If scaling out web tier to WEBHOST2 and others, do the same on these hosts as well.

      The following is an example of scaling up the HomePage Managed Server, and what the SCALED_UP_HOST:port looks like in the <Location> xml element in the FusionVirtualHost_fs.conf file

      <Location /homepage>
         SetHandler weblogic-handler
         WebLogicCluster <DOMAINHOSTSOAVH1:port>, <DOMAINHOSTSOAVH2:port>
         WLProxySSL ON
         WLProxySSLPassThrough ON
         RewriteEngine On
         RewriteOptions inherit
      </Location>
      

   3. Restart Oracle HTTP Server on both WEBHOST1 and all other web-tier hosts, where applicable.

3. Log in to the domain's Oracle WebLogic Server Administration Console and start the soa_servern Managed Server. Begin with n=1.

4. Access the URL http://domain_nameinternal.mycompany.com/soa-infra to verify that routing and failover are functioning properly.

   Close all browser windows then open a new one to ensure that the Oracle Fusion Applications login window displays correctly.

5. Log in to the domain's Oracle WebLogic Server Administration Console and stop the soa_servern Managed Server started in Step 3.

6. Repeat Steps 3 through 5 for the other instances of the soa_servern .

7. After completing validation, start all instances of soa_servern.

To scale up Oracle Business Intelligence on SCALED_UP_HOST:

Before beginning, ensure the following:

• SCALED_OUT_HOST Node Manager has been started in the Secure Sockets Layer (SSL) mode

• Start with a clean machine if it is the first time it is being used for a scale out

• The UNIX /etc/hosts file has proper entries. To verify this from the clean machine, ping the hosts listed in /etc/hosts files with the fully qualified name of the hosts.

• The user created on SCALED_OUT_HOST should the same as the user on PROVISIONED_HOST

• The directory structure APPLICATIONS_BASE is mounted on SCALED_OUT_HOST, and is the same shared file system as used by PROVISIONED_HOST

• The directory structure APPLICATIONS_CONFIG on SCALED_OUT_HOST has been created

• The initial deployment on PROVISIONED_HOST has already been done and verified by provisioning

To add a new machine:

Since the PROVISIONED_HOST domain directory file system is also available from SCALED_OUT_HOST, both the pack and unpack commands can be executed from the SCALED_OUT_HOST.

To pack and unpack the Managed Server domain home:

To add a Managed Server and assign it to SCALED_OUT_HOST:

1. Log in to the Administration Server: http://domain_nameinternal.mycompany.com/console.

2. Navigate to Domain_Name, Environment, Servers.

3. Switch to Lock & Edit mode.

4. Select the Managed_Server checkbox (for example, soa_server1) and then click Clone.

5. Specify the following Server Identity attributes:

   • Server Name - soa_server3

     To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Then change the number to "3".

   • Server Listen Address - <SCALED_OUT_HOST>

   • Server Listen Port - leave "as is"

6. Click OK.

7. Navigate back to Domain_Name, Environment, Servers. See the newly cloned server, soa_server3.

8. Click soa_server3 and change the following attributes:

   • Machine - <SCALED_OUT_HOST>

   • Cluster Name - accept the default, SOACluster

     Ensure that this cluster name is the same as the cluster name of the original Managed Server.

9. From soa_server3, click Advanced and then select the WebLogic Plug-In Enabled checkbox.

10. Click Save.

11. Select the Keystores tab, and then ensure that the keystores value is Custom Identity and Custom Trust.

12. Do the following:

    1. Change the Custom Identity Keystore path to point to the APPLICATIONS_BASE/fusionapps/wlserver_10.3/server/lib/SCALED_OUT_HOST_fusion_identity.jks file.

    2. Leave the Custom Identity Keystore type blank.

    3. Change the Custom Identity Keystore Passphrase entry. This should be the same as the keystorepassword field described in the first bullet in Step 4 in Create the Identity Keystore on SCALED_OUT_HOST.

    4. Re-enter the Confirm Custom Identity Keystore Passphrase.

    5. Ensure that the Confirm Custom Trust Keystore path is pointing to the APPLICATIONS_BASE/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks file.

    6. Leave the Custom Trust Keystore type blank.

    7. Change the Custom Trust Keystore Passphrase entry. This should be the same as the keystorepassword field described in the first bullet in Step 4 in Creating the Identity Keystore on SCALED_OUT_HOST.

    8. Re-enter the Custom Trust Keystore Passphrase.

    9. Click Save.

13. Select the SSL tab.

    1. Make sure that Identity and Trust Locations is set to Keystores.

    2. Change the Private Key Alias to SCALED_OUT_HOST_fusion.

    3. Change the Private Key Passphrase to the keypassword, as described in the second bullet in Step 4 in Creating the Identity Keystore on SCALED_OUT_HOST.

    4. Re-enter the keypassword from Step c for the Confirm Private Key Passphrase.

    5. Click Save.

14. Select the Server Start tab.

    Change the Arguments to reflect the name of the cloned Managed Server and make sure the server group is the correct cluster name. For example, the following should be seen:

    -DJDBCProgramName\=DS/domain_nameDomain/soa_server3
    -Dserver.group\=SOACluster
    

    Click Save.

15. Select the Logging tab, and then select the HTTP tab.

16. Do the following:

    1. Change the Log file name to logs/access.log.%yyyyMMdd%.

    2. Change the rotation type to By Time.

    3. Leave the Limit number of retained files option unchecked.

    4. Leave the Rotate log file on startup option unchecked.

    5. Click Save.

    6. Expand Advanced.

    7. Change the format to Extended.

    8. Change the extended logging format fields to the following:

       date time time-taken cs-method cs-uri 
       sc-status sc(X-ORACLE-DMS-ECID) 
       cs(ECID-Context) cs(Proxy-Remote-User) 
       cs(Proxy-Client-IP)
       

    9. Click Save.

17. Click Activate Changes.

18. Run the newly created Managed Server:

    1. Navigate to Domain_Name, Environment.

    2. From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.

    3. Navigate to Domain_Name, Environment, Servers, Control.

    4. Check the newly created Managed Server and click Start.

    5. Navigate to Domain_Name, Environment, Servers, and check the State to verify that the newly created Managed Servers are running.

Verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to the domain's SOACluster.

To verify the URLs:

1. Log in to the domain's Oracle WebLogic Server Administration Console and stop the soa_server1 Managed Server on PROVISIONED_HOST while the Managed Servers on SCALED_OUT_HOST are running.

2. Do the following:

   1. Edit the FusionVirtualHost file, adding the scaled-out soa_server3 Managed Server's host and port.

   2. Add the code shown in the following example to both the Internal and External part of the FusionVirtualHost file on WEBHOST1 and WEBHOST2.

      <Location /soa/composer>
         SetHandler weblogic-handler
         WebLogicCluster <DOMAINHOSTSOAVH1:port>,<DOMAINHOSTSOAVH2:port>,
         WLProxySSL ON
         WLProxySSLPassThrough ON
         RewriteEngine On
         RewriteOptions inherit
      </Location>
      

   3. Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2.

3. Access http://domain_nameinternal.mycompany.com/soa-infra to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)

4. Log in to the domain's Oracle WebLogic Server Administration Console and stop the soa_server3 Managed Server on SCALED_OUT_HOST.

5. Start the soa_server1 Managed Server on PROVISIONED_HOST.

6. Repeat Step 3. (Ensure the log in prompt is visible.)

7. Start the soa_server3 Managed Server on SCALED_OUT_HOST and verify that soa_server1 and soa_server3 are running.

Ensure the following:

• The Administration Server is configured to listen on a domain-specific administrative virtual host, and not on any address

• When failover happens, the Administration Server is failed over from PROVISIONED_HOST to SCALED_OUT_HOST and the two nodes have the following IPs:

  • PROVISIONED_HOST: 100.200.140.165

  • SCALED_OUT_HOST: 100.200.140.205

  • DOMAINADMINVH: 100.200.140.206. This is the VIP where the domain-specific Administration Server is running, assigned to ethX:Y, available in PROVISIONED_HOST and SCALED_OUT_HOST.

  • The domain directory where the Administration Server is running on PROVISIONED_HOST is on shared storage and is mounted from SCALED_OUT_HOST

The following procedure explains how to fail over the Administration Server to a different node (SCALED_OUT_HOST) with the Administration Server still using the same Oracle WebLogic Server machine. (This machine is a logical machine, not a physical one.)

To fail over the Administration Server:

1. Stop the Administration Server.

2. Migrate the IP to the second node:

   1. Run the following command as root on PROVISIONED_HOST to (where X:Y is the current interface used by DOMAINADMINVH):

      PROVISIONED_HOST> /sbin/ifconfig ethX:Y down
      

   2. Run the following command as root on SCALED_OUT_HOST:

      SCALED_OUT_HOST> /sbin/ifconfig interface:index IP_Address netmask netmask
      

      For example:

      /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
      

      Ensure that the netmask and interface to be used to match the available network configuration in SCALED_OUT_HOST.

3. Update the routing tables with arping. For example, run the following command as root:

   SCALED_OUT_HOST> /sbin/arping -q -U -c 3 -I eth0 100.200.140.206
   

4. Validate that the address is available by pinging it from another node. For example:

   /bin/ping 100.200.140.206
   

5. Start the Administration Server on SCALED_OUT_HOST using the procedure in Enable an Administration Server to Listen on the Virtual IP Address.

6. Test access to the Administration Server on SCALED_OUT_HOST:

   1. Ensure that it is possible to access the domain-specific Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control. For example, for the Oracle Fusion Customer Relationship Management domain, use these URLs:

      • http://crminternal.mycompany.com/console

      • http://crminternal.mycompany.com/em

   2. Repeat Step 6.a for other domain by replacing the domain-specific URL.

The Administration Server does not use Node Manager for failing over. After a manual failover, the machine name that appears in the Current Machine field in the Administration Console for the server is PROVISIONED_HOST, and not the failover machine, SCALED_OUT_HOST. Since Node Manager does not monitor the Administration Server, the machine name that appears in the Current Machine field, is not relevant and can be ignored.