Skip Headers
Oracle® Fusion Applications Financials Enterprise Deployment Guide
11g Release 5 (11.1.5)

Part Number E27364-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

20 Managing the Topology

This chapter describes some operations that you can perform after you have set up the topology. These operations include monitoring, scaling, and backing up.

This chapter includes the following topics:

Note:

For Oracle WebCenter Content scale out only, use the procedure described in Section 10.4, "Creating a Common Location for the Oracle WebCenter Content Managed Servers."

20.1 Scaling the Topology for Additional Nodes

You can scale out and or scale up the enterprise topology. When you scale up the topology, you add new Managed Servers to nodes that are already running on one or more Managed Servers. When you scale out the topology, you add new Managed Servers to new nodes.

This section includes the topics:

20.1.1 Scaling Out the Topology (Adding Managed Servers to a New Node) for Oracle ADF Server

When scaling out the topology, you add new Managed Servers configured to new nodes.

Note:

The steps provided in this section also can be used to scale out additional hosts, such as FINHOST4, FINHOST5, and so on.

20.1.1.1 Prerequisites for Scaling Out the Topology for Oracle ADF Server

Before you begin, ensure the following:

  • Node Manager has been started in the Secure Sockets Layer (SSL) mode by following the instructions in Chapter 7, "Setting Up Node Manager for an Enterprise Deployment"

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

  • The /etc/hosts file has proper entries. To verify, ping this machine with the fully qualified name of the machine

  • The user created on FINHOST3 should the same as the user on FINHOST1

  • The directory structure /u01/oracle is mounted to same shared file system as FINHOST1

  • The directory structure /u02/local/oracle/config on FINHOST3 has been created

  • The initial Oracle Fusion Financials deployment on FINHOST1 has already been done and verified by provisioning

20.1.1.2 Adding a New Machine in the Oracle WebLogic Server Console

To add a new machine:

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

  2. Navigate to CommonDomain > Environment > Machines.

    LocalMachine is located in the right-hand pane.

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

  4. In the right-hand pane, first click New to add the remote machine, and then specify the following:

    • Name - enter FINHOST3

    • Machine operating system - Unix

  5. Click Next.

  6. In the window that opens, set the following attributes:

    • Type - SSL

    • Listen Address - <FINHOST3>

      Note:

      The "localhost" default value here is wrong.

    • Listen port - 5556

  7. Click Finish and activate the changes.

    Note:

    If you get an error when activating the changes, see Section 20.8.18, "Administration Console Redirects from Internal URL to Container URL after Activation" for the temporary solution.

20.1.1.3 Packing and Unpacking the Managed Server Domain Home

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

To pack and unpack the Managed Server domain home:

  1. Change directory to ORACLE_BASE/products/fusionapps/oracle_common/common/bin.

  2. Run the pack command. For CommonDomain, for example:

    FINHOST3> ./pack.sh -managed=true -domain=ORACLE_BASE/config/domains/
    FINHOST1/CommonDomain -template=ORACLE_BASE/user_templates/
    CommonDomain_managed.jar -template_name="Common_Managed_Server_Domain" 
    
  3. Ensure that /u02/local/oracle/config/domains/FINHOST3/CommonDomain is empty, and then run the unpack command:

    FINHOST3> ./unpack.sh -domain=/u02/local/oracle/config/domains/
    FINHOST3/CommonDomain -template=ORACLE_BASE/user_templates/
    CommonDomain_managed.jar
    

    Here, ORACLE_BASE is shared, and /u02/local is local to FINHOST3.

20.1.1.4 Cloning Managed Servers and Assigning Them to FINHOST3

To add a Managed Server and assign it to FINHOST3:

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

  2. Navigate to CommonDomain > Environment > Servers.

  3. Switch to Lock & Edit mode.

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

  5. Specify the following Server Identity attributes:

    • Server Name - HomePageServer_3

      Note:

      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 - <FINHOST3>

    • Server Listen Port - leave "as is"

      Note:

      For Oracle SOA Suite server, add a port value that is different than the soa_server1 server value. This will help in server migration.

  6. Click OK.

    You now should see the newly cloned server, HomePageServer_3.

  7. Click HomePageServer_3 and change the following attributes:

    • Machine - <FINHOST3>

    • Cluster Name - accept the default, HomePageCluster

      Note:

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

  8. Click Save and then Activate Changes.

  9. From the Name column, click the HomePageServer_3 scaled-out server link.

  10. Click Lock & Edit, and then select the Configuration tab.

  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 ORACLE_BASE/products/fusionapps/wlserver_10.3/server/lib/FINHOST3_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 Section 7.2, "Creating the Identity Keystore on FINHOST2."

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

    5. Ensure that the Confirm Custom Trust Keystore path is pointing to the ORACLE_BASE/products/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 Section 7.2, "Creating the Identity Keystore on FINHOST2."

    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 FINHOST3_fusion.

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

    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 your cloned Managed Server and make sure the server group is the correct cluster name. For example, you should see the following:

    -DJDBCProgramName\=DS/CommonDmain/HomePageServer_3
    -Dserver.group\=HomePageCluster
    
    
    

    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. Repeat Steps 2 to 17 for all the newly cloned Managed Servers on this domain.

  19. Set the following environment variable on FINHOST3:

    WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE/
    products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks"
    
  20. Restart the domain's Administration Server on FINHOST3:

    FINHOST3> ORACLE_BASE/products/fusionapps/wlserver_10.3/common/bin/wlst.sh
    
    FINHOST3> nmConnect(username='<username>', password='<password>',
    domainName='CommonDomain', host='FINHOST1',port='5556', 
    nmType='ssl', domainDir='ORACLE_BASE/config/domains/FINHOST1/CommonDomain')
    
    FINHOST3> nmStart('AdminServer')
    

    Note:

    The username and password used in the nmConnect are the Node Manager credentials (username and password) specified when creating the provisioning response file. This is shown in Figure 5-3 in "Using the Provisioning Process to Install Components for an Enterprise Deployment".

  21. Run the newly created Managed Servers:

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

    2. Navigate to CommonDomain > Environment > Servers > Control.

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

    4. Navigate to CommonDomain > Environment > Servers and check the State to verify that the newly created Managed Servers are running.

20.1.1.5 Validating the System

You should verify URLs to ensure that the appropriate routing and failover are working.

To verify the URLs:

  1. Log in to the CommonDomain Oracle WebLogic Server Administration Console and stop all the Managed Servers on the FINHOST1 while the Managed Servers on FINHOST3 while the are running.

  2. Access the following URL to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)

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

  3. Log in to the CommonDomain Oracle WebLogic Server Administration Console and stop all the Managed Servers on FINHOST3.

  4. Start the Managed Servers on FINHOST1.

  5. Repeat Step 2. (Ensure the log in prompt is visible.)

  6. Start all the Managed Servers on FINHOST3 and verify that they are running on FINHOST1 and FINHOST3.

20.1.2 Scaling Up the Topology (Adding Managed Servers to an Existing Node) for Oracle ADF Server

Before performing the procedures in this section, ensure that CommonDomain and its Managed Servers are running.

20.1.2.1 Cloning Managed Servers and Assigning Them to FINHOST3

To add a Managed Server and assign it to FINHOST3:

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

  2. Navigate to CommonDomain > Environment > Servers.

  3. Switch to Lock & Edit mode.

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

  5. Specify the following Server Identity attributes:

    • Server Name - HomePageServer_4

      Note:

      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 "_4".

    • Server Listen Address - <FINHOST3>

    • Server Listen Port - leave "Give an unused port on the machine FINHOST3"

  6. Click OK.

  7. Navigate back to CommonDomain > Environment > Servers. You now should see the newly cloned server, HomePageServer_4.

  8. Click HomePageServer_4 and change the following attributes:

    • Machine - <FINHOST3>

    • Cluster Name - accept the default, HomePageCluster

      Note:

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

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

  10. Click Save.

  11. Run the newly created Managed Server:

    1. Navigate to CommonDomain > Environment.

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

    3. Navigate to CommonDomain > Environment > Servers > Control.

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

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

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

  13. Select the Server Start tab.

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

    -DJDBCProgramName\=DS/CommonDmain/HomePageServer_4
    -Dserver.group\=HomePageCluster
    
    
    

    Click Save.

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

  15. 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.

  16. Click Activate Changes.

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

20.1.2.2 Validating the System

You should verify URLs to ensure that the appropriate routing and failover are working.

To verify the URLs:

  1. Log in to the CommonDomain Oracle WebLogic Server Administration Console and stop the HomePageServer_1, HomePageServer_2, and HomePageServer_3 Managed Servers on FINHOST1, FINHOST2, and FINHOST3.

  2. Perform Step 2 in Section 9.6, "Oracle HTTP Server Configuration," for the scaled-up server.

  3. Access the following URL to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)

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

  4. Log in to the CommonDomain Oracle WebLogic Server Administration Console and stop the HomePageServer_4 Managed Server on FINHOST3.

  5. Start the HomePageServer_1 Managed Server on FINHOST1.

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

  7. Start all the Managed Servers on FINHOST3 and verify that they are running on FINHOST1 and FINHOST3.

20.1.3 Scaling Out the Topology (Adding Managed Servers to a New Node) for Oracle SOA Suite Server

When scaling out the topology, you add new Managed Servers configured to new nodes.

20.1.3.1 Prerequisites for Scaling Out the Topology for Oracle SOA Suite Server

Before you begin, ensure the following:

  • Node Manager has been started in the Secure Sockets Layer (SSL) mode by following the instructions in Chapter 7, "Setting Up Node Manager for an Enterprise Deployment"

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

  • The /etc/hosts file has proper entries. To verify, ping this machine with the fully qualified name of the machine

  • The user created on FINHOST3 should the same as the user on FINHOST1

  • The directory structure /u01/oracle is mounted to same shared file system as FINHOST1

  • The directory structure /u02/local/oracle/config on FINHOST3 has been created

  • The initial Oracle Fusion Financials deployment on FINHOST1 has already been done and verified by provisioning

20.1.3.2 Adding a New Machine in the Oracle WebLogic Server Console

If you have not already addedFINHOST3, follow these steps:

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

  2. Navigate to FinancialDomain > Environment > Machines.

    LocalMachine is located in the right-hand pane.

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

  4. In the right-hand pane, first click New to add the remote machine, and then specify the following:

    • Name - enter FINHOST3

    • Machine operating system - Unix

  5. Click Next.

  6. In the window that opens, set the following attributes:

    • Type - SSL

    • Listen Address - <FINHOST3>

      Note:

      The "localhost" default value here is wrong.

    • Listen port - 5556

  7. Click Finish and activate the changes.

    Note:

    If you get an error when activating the changes, see Section 20.8.18, "Administration Console Redirects from Internal URL to Container URL after Activation" for the temporary solution.

20.1.3.3 Packing and Unpacking the Managed Server Domain Home

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

To pack and unpack the Managed Server domain home:

  1. Change directory to ORACLE_BASE/products/fusionapps/oracle_common/common/bin.

  2. Run the pack command. For example, for FinancialDomain:

    FINHOST3> ./pack.sh -managed=true -domain=ORACLE_BASE/config/domains/
    FINHOST1/FinancialDomain -template=ORACLE_BASE/user_templates/
    FinancialDomain_managed.jar -template_name="Financial_Managed_Server_Domain" 
    
  3. Run the unpack command:

    FINHOST3> ./unpack.sh -domain=/u02/local/oracle/config/domains/
    FINHOST3/FinancialDomain -template=ORACLE_BASE/user_templates/FinancialDomain_managed.jar
    

    Here, ORACLE_BASE is shared, and /u02/local is local to FINHOST3.

20.1.3.4 Cloning Managed Servers and Assigning Them to FINHOST3

To add a Managed Server and assign it to FINHOST3:

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

  2. Navigate to FinancialDomain > 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

      Note:

      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 - <FINHOST3>

    • Server Listen Port - leave "as is"

      Note:

      For Oracle SOA Suite server, add a port value that is different than the soa_server1 server value. This will help in server migration.

  6. Click OK.

  7. Navigate back to FinancialDomain > Environment > Servers. You now should see the newly cloned sales server, soa_server3.

  8. Click soa_server3 and change the following attributes:

    • Machine - <FINHOST3>

    • Cluster Name - accept the default, SOACluster

      Note:

      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. Run the newly created Managed Server:

    1. Navigate to FinancialDomain > Environment.

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

    3. Navigate to FinancialDomain > Environment > Servers > Control.

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

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

  11. From the Name column, select the scaled-out server, soa_server3.

  12. Click Lock & Edit, and then select the Configuration tab.

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

  14. Do the following:

    1. Change the Custom Identity Keystore path to point to the ORACLE_BASE/products/fusionapps/wlserver_10.3/server/lib/FINHOST3_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 Section 7.2, "Creating the Identity Keystore on FINHOST2."

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

    5. Ensure that the Confirm Custom Trust Keystore path is pointing to the ORACLE_BASE/products/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 Section 7.2, "Creating the Identity Keystore on FINHOST2."

    8. Re-enter the Custom Trust Keystore Passphrase.

    9. Click Save.

  15. Select the SSL tab.

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

    2. Change the Private Key Alias to FINHOST3_fusion.

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

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

    5. Click Save.

  16. Select the Server Start tab.

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

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

    Click Save.

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

  18. 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.

  19. Click Activate Changes.

  20. Set the following variable:

    WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE/
    products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks"
    
  21. Restart the domain's Administration Server on FINHOST3:

    FINHOST3> ORACLE_BASE/products/fusionapps/wlserver_10.3/common/bin/wlst.sh
    
    FINHOST3> nmConnect(username='username', password='password',
    domainName='FinancialDomain', host='FINHOST1',port='5556', 
    nmType='ssl', domainDir='/u01/oracle/config/domains/FINHOST1/FinancialDomain')
    
    FINHOST3> nmStart('AdminServer')
    

    Note:

    The username and password used in the nmConnect are the Node Manager credentials (username and password) specified when creating the provisioning response file. This is shown in Figure 5-3 in "Using the Provisioning Process to Install Components for an Enterprise Deployment".

20.1.3.5 Validating the System

You should verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to the SalesCluster.

To verify the URLs:

  1. Log in to the FinancialDomain Oracle WebLogic Server Administration Console and stop all the Managed Servers on the FINHOST1 while the Managed Servers on FINHOST3 are running.

  2. Access the following URLs to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)

    • http://fininternal.mycompany.com:7777/soa-infra

  3. Log in to the FinancialDomain Oracle WebLogic Server Administration Console and stop all the Managed Servers on FINHOST3.

  4. Start the Managed Servers on FINHOST1.

  5. Repeat Step 2. (Ensure the log in prompt is visible.)

  6. Start all the Managed Servers on FINHOST3 and verify that they are running on FINHOST1 and FINHOST3.

20.1.3.6 Additional Configuration Procedures for Scaling Out Oracle SOA Suite Server

At this point, soa_server1 and soa_server3 are running on FINHOST1 and FINHOST3.

Note:

For Oracle Fusion Customer Relationship Management, the Oracle SOA Suite virtual IPs for FINHOST1 and FINHOST3 are called FINSOAVH1 and FINSOAVH3.

This section includes the following topics:

20.1.3.6.1 Enabling Virtual IPs on FINHOST3

To enable the virtual IPs on Linux:

Note:

In this example ethX is the ethernet interface (eth0 or eth1) and Y is the index (0, 1, 2, and so on).

  1. Run the ifconfig command as root:

    /sbin/ifconfig interface:index IPAddress netmask netmask
    

    For example:

    /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
    
  2. Enable your network to register the new location of the virtual IP:

    /sbin/arping -q -U -c 3 -I interface IPAddress
    

    For example:

    /sbin/arping -q -U -c 3 -I ethX 100.200.140.206
    
  3. Validate that the address is available by pinging it from another node.

    For example:

    /bin/ping 100.200.140.206
    
20.1.3.6.2 Setting the Listen Address for soa_server3

Ensure that you have performed the steps described in Section 16.1 before setting the soa_server3 listen address.

To set the listen address for the Managed Server:

  1. Log in to the Administration 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 soa_server3 in the table. The Settings page for soa_server3 is displayed.

  6. Set the Listen Address to FINSOAVH3.

  7. Click Save.

  8. Click Activate Changes.

  9. The changes will not take effect until the soa_server3 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 soa_server3 in the table and then click Shutdown.

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

20.1.3.6.3 Updating the FusionVirtualHost_fin.conf Configuration File

For information, see Section 16.4, "Updating the FusionVirtualHost_fin.conf Configuration File."

20.1.3.6.4 Configuring JMS for the Oracle SOA Suite Server

After FINHOST1has been provisioned, the JMS server and file store are set up and configured for FINHOST1. You now must configure the file store for FINHOST3. Configure the location for all persistence stores to a directory visible from both nodes.

To configure the file store for FINHOST3:

  1. Log in to the Oracle WebLogic ServerAdministration Console.

  2. In the Domain Structure window, expand the Services node and then click the Persistence Stores node.

    The Summary of Persistence Stores page appears.

  3. Click Lock & Edit.

  4. Click New, and then Create File Store.

  5. Enter a name (for example, SOAJMSFileStore_auto_3), and a target, soa_server3:

    ORACLE_BASE/config/domains/FINHOST1/FinancialDomain
    
  6. Click OK and activate the 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 appears.

  8. Click Lock & Edit.

  9. Click New.

  10. Enter a name (for example, SOAJMSServer_3), then select SOAJMSFileStore_auto_3 in the Persistence Store dropdown list.

  11. Click Next.

  12. Select soa_server3 as the target.

  13. Click Finish and Activate Changes.

  14. In the Domain Structure window, expand the Services node and then click the Messaging > JMS Modules node.

    The JMS Modules page appears.

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

  16. Click SOAJMSModule and then click the Subdeployments tab.

  17. Select SOAJMSServer under Subdeployments.

  18. Add the new SOAJMSServer_3 as additional targets for the subdeployment.

  19. Click Save and Activate Changes.

20.1.3.6.5 Configuring Oracle Coherence for Deploying Composites

Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication instead in SOA enterprise deployments. Use unicast if you disable multicast communication for security reasons.

Note:

An incorrect configuration of the Oracle Coherence framework that is used for deployment may prevent the SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA system runs. Oracle recommends the configuration described in this section.

Multicast communication enables Oracle Fusion Middleware SOA to discover all of the members of a cluster to which it deploys composites dynamically. However, unicast communication does not enable nodes to discover other cluster members in this way. Consequently, you must specify the nodes that belong to the cluster. You do not need to specify all of the nodes of a cluster, however. You need only specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as SOA enterprise deployments, where multiple IPs are available in the same box, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.

Tip:

To guarantee high availability during deployments of SOA composites, specify enough nodes so that at least one of them is running at any given time.

Specify the nodes using the tangosol.coherence.wka n system property, where n is the number for each Oracle HTTP Server. The numbering starts at 1. This numbering must be sequential and must not contain gaps. In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost system property. This local host name should be the virtual host name used by the SOA server as the listener addresses. Set this property by adding the -Dtangosol.coherence.localhost parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab, shown in Figure 20-1.

Note:

FINSOAVH1 is the virtual host name that maps to the virtual IP where soa_server1 is listening (in FINHOST1). FINSOAVH3 is the virtual host name that maps to the virtual IP where soa_server3 is listening (in FINHOST3).

Figure 20-1 Setting the Host Name

Setting the Host Name

To add the host name used by Oracle Coherence:

  1. Log in to the Oracle WebLogic Server Administration Console.

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

  3. Click Servers.

    The Summary of Servers page appears.

  4. Select soa_server1 (represented as a hyperlink) in the table.

    The Settings page appears.

  5. Click Lock & Edit.

  6. Click the Server Start tab (shown in Figure 20-1).

  7. Enter the following for soa_server1 and soa_server3 into the Arguments field.

    For soa_server1, enter the following:

    -Dtangosol.coherence.wka1=FINSOAVH1
    -Dtangosol.coherence.wka2=FINSOAVH3
    -Dtangosol.coherence.localhost=FINSOAVH1
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    

    For soa_server3, enter the following:

    -Dtangosol.coherence.wka1=FINSOAVH3 
    -Dtangosol.coherence.wka2=FINSOAVH1
    -Dtangosol.coherence.localhost=FINSOAVH3
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    

    Note:

    There should be no breaks in lines between the different -D parameters. Do not copy or paste the code from above to your Administration Console's Arguments text field. This may result in HTML tags being inserted in the Java arguments. The code should not contain other characters than those included in the example above.

  8. Click Save and Activate Changes.

Note:

You must ensure that these variables are passed to the Managed Server correctly. (They should be reflected in the server's output log.) Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.

Note:

The multicast and unicast addresses are different from the ones used by the Oracle WebLogic Server cluster for cluster communication. Oracle SOA Suite guarantees that composites are deployed to members of a single Oracle WebLogic Server cluster even though the communication protocol for the two entities (the Oracle WebLogic Server cluster and the groups to which composites are deployed) are different.

Note:

The Oracle Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying the -Dtangosol.coherence.wkaX.port startup parameter.

20.1.3.6.6 Disabling Host Name Verification for the soa_servern Managed Servers

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. By default, Host Name Verification should be set to None. If it is not, follow the steps below.

If you have not configured the server certificates, you will receive errors when managing the different WebLogic servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the enterprise deployment topology configuration is complete.

To disable Host Name Verification:

  1. Log in to Oracle WebLogic Server Administration Console. For example, http:/fininternal.mycompany.com:777/console.

  2. Click Lock & Edit.

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

  4. Click Servers.

    The Summary of Servers page appears.

  5. Select soa_server3 (represented as a hyperlink) in the table.

    The Settings page appears.

  6. Select the SSL tab.

  7. Expand the Advanced section of the page.

  8. Set Hostname Verification to None.

  9. Click Save and activate the changes.

20.1.3.6.7 Restarting Node Manager on FINHOST3

To restart Node Manager on FINHOST3, follow the steps in Section 16.9, "Restarting Node Manager on FINHOST1."

20.1.3.6.8 Starting and Validating soa_server3 on FINHOST3

To start the soa_server3 Managed Server on FINHOST3 and ensure that it is configured correctly:

  1. From the Administration Console, start the soa_server3 Managed Server.

  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.

  3. Access http://FINSOAVH3:9024/soa-infra and http://fininternal .mycompany.com:7777/soa-infra.

20.1.4 Scaling Up the Topology (Adding Managed Servers to an Existing Node) for Oracle SOA Suite Server

Before performing the procedures in this section, ensure that CommonDomain and its Managed Servers are running.

20.1.4.1 Cloning Managed Servers and Assigning Them to FINHOST3

To add a Managed Server and assign it to FINHOST3:

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

  2. Navigate to FinancialDomain > Environment > Servers.

  3. Switch to Lock & Edit mode.

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

  5. Specify the following Server Identity attributes:

    • Server Name - soa_server4

      Note:

      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 "_4".

    • Server Listen Address - <FINHOST3>

    • Server Listen Port - leave "Give an unused port on the machine FINHOST3"

  6. Click OK.

  7. Navigate back to FinancialDomain > Environment > Servers. You now should see the newly cloned SOA server, soa_server4.

  8. Click soa_server4 and change the following attributes:

    • Machine - <FINHOST3>

    • Cluster Name - Default, FIN_SOACluster

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

  10. Click Save.

  11. Run the newly created Managed Servers:

    1. Navigate to FinancialDomain > Environment.

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

    3. Navigate to FinancialDomain > Environment > Servers > Control.

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

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

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

20.1.4.2 Validating the System

You should verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to the SalesCluster.

To verify the URLs:

  1. Log in to the FinancialDomain Oracle WebLogic Server Administration Console and stop the soa_server1, soa_server2, and soa_server3 Managed Servers on FINHOST1, FINHOST2, and FINHOST3.

  2. Perform Step 2 in Section 9.6, "Oracle HTTP Server Configuration," for the scaled-up server.

  3. Access the following URLs to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)

    • http://fininternal.mycompany.com:7777/soa-infra

  4. Log in to the FinancialDomain Oracle WebLogic Server Administration Console and stop the soa_server4 Managed Server on FINHOST3.

  5. Start the Managed Servers on FINHOST1.

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

  7. Start all the Managed Servers on FINHOST2 and verify that they are running on FINHOST1.

20.1.5 Scaling Out the Topology (Adding Managed Servers to a New Node) for Oracle Business Intelligence

When scaling out the topology, you add a new Managed Server and set of system components to a new node in your topology (FINHOST3). This procedure assumes that you already have an enterprise topology that includes two nodes, with a Managed Server and a full set of system components on each node.

20.1.5.1 Prerequisites for Scaling Out the Topology for Oracle Business Intelligence

Before performing the steps in this section, ensure that you meet these requirements:

  • There must be existing nodes running Oracle Business Intelligence Managed Servers within the topology.

  • The new node (FINHOST3) can access the existing home directories for Oracle WebLogic Server and Oracle Business Intelligence.

  • When an FA_MW_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_BASE/products/fusionapps/bi/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the ORACLE_BASE/products/fusionapps/.home file. See the steps below.

  • You must ensure that all shared storage directories are available on the new node. Ensure that all shared directories are available on all nodes, except for the ORACLE_INSTANCE directory and the domain directory for the scaled-out Managed Server.

    Also, if you are using shared storage for the identity keystore and trust keystore that hold your host name verification certificates, make sure that the shared storage directory is accessible from the scaled-out node (FINHOST3). If you are using local directories for your keystores, follow the steps in Section 7.2, "Creating the Identity Keystore on FINHOST2." to create and configure a local identity keystore for the scaled-out node.

    For example, mount the following directories:

    • Transaction Log directory

    • JMS Persistence Store

    • Global Cache

    • BI Presentation Catalog

    • BI Repository Publishing directory

    • BI Publisher Catalog

    • BI Publisher Configuration Keystore (certs)

    • MW_HOME

20.1.5.2 Scale-Out Procedure for Oracle Business Intelligence

To scale out Oracle Business Intelligence on FINHOST3:

  1. On FINHOST3, mount the existing Middleware home, which should include the Oracle Business Intelligence installation and (optionally, if the domain directory for Managed Servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.

  2. Run the following command to attach ORACLE_BASE/products/fusionapps/oracle_common in shared storage to the local Oracle Inventory:

    FINHOST3> cd ORACLE_BASE/products/fusionapps/oracle_common/oui/bin/
    FINHOST3> ./attachHome.sh -jreLoc ORACLE_BASE/products/fusionapps/jdk6
    

    To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the ORACLE_BASE/products/fusionapps/.home file and add ORACLE_BASE/products/fusionapps to it.

  3. Start Node Manager:

    1. Stop any Node Manager running on FINHOST3.

    2. Change directory to ORACLE_BASE/products/fusionapps/wlserver_10.3/common/nodemanager and edit the nodemanager.properties file with the following:

      SecureListener=false
      
    3. Change directory to ORACLE_BASE/products/fusionapps/oracle_common/common/bin and run the following script:

      ./setNMProps.sh
      
    4. Change directory to ORACLE_BASE/products/fusionapps/wlserver_10.3/server/bin and run the following script:

      ./startNodeManager.sh 
      

      Node Manager starts on FINHOST3.

      Note:

      Steps b through d will enable Node Manager on FINHOST3 and the Administrator Console to communicate on Plain Socket.

  4. Run the Configuration Assistant from one of the shared Oracle homes, using the steps in Section 15.5.1, "Scaling Out the Oracle Business Intelligence System on FINHOST2"as a guide.

  5. Scale out the system components on FINHOST3, using the steps in Section 15.5.3, "Scaling Out the System Components" as a guide.

  6. Configure the bi_server3 Managed Server by setting the Listen Address and disabling host name verification, using the steps in Section 15.5.5, "Configuring the bi_server2 Managed Server" as a guide.

  7. Configure JMS for Oracle BI Publisher, as described in Section 15.5.6.3.3, "Configuring JMS for BI Publisher."

  8. Configure Oracle BI for Microsoft Office on FINHOST3, as described in Section 15.5.6.4, "Additional Configuration Tasks for Oracle BI for Microsoft Office."

  9. Set the location of the default persistence store for bi_server3, as described in Section 15.5.7, "Configuring a Default Persistence Store for Transaction Recovery."

  10. Configure Oracle HTTP Server for BIVH3 using the steps in Section 15.4.3, "Updating the FusionVirtualHost_bi.conf Configuration File"as a guide.

  11. Start the bi_server3 Managed Server and the system components running on FINHOST3. See Section 15.5.8, "Starting and Validating Oracle Business Intelligence on FINHOST2"for details.

  12. Set up server migration for the new node, as described in the following sections:

  13. Access the following URLS to validate the configuration:

    • http://BIVH3:10217/analytics to verify the status of bi_server3.

    • http://BIVH3: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.

      Note:

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

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

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

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

    • http://BIVH3:10217/hr to verify Financial Reporting.

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

    • http://BIVH3:10217/aps/Test to verify APS.

    • http://BIVH3:10217/workspace to verify workspace

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 Chapter 7, "Setting Up Node Manager for an Enterprise Deployment" for further details.

20.1.6 Scaling Up the Topology for Oracle Business Intelligence

This procedure assumes that you already have an enterprise topology that includes two nodes, with a Managed Server and a full set of system components on each node. To scale up the topology, you increase the number of system components running on one of your existing nodes.

Note that it is not necessary to run multiple Managed Servers on a given node.

20.1.6.1 Scale-Up Procedure for Oracle Business Intelligence

To scale up Oracle Business Intelligence on FINHOST3:

  1. Log in to Fusion Middleware Control.

  2. Expand the Business Intelligence node in the Farm_BIDomain window.

  3. Click coreapplication.

  4. Click Capacity Management, then click Scalability.

  5. Click Lock & Edit and then change the number of BI Servers, Presentation Servers, or Java Hosts using the arrow keys.

    Note:

    To avoid port conflicts for the system components being scaled within the given Oracle WebLogic Server instance, enter a different range of available ports in the Port Range From and Port Range To fields. For example, change Port Range From to 10221 and Port Range To to 10300.

  6. Click Apply, then click Activate Changes.

  7. Click Restart to apply recent changes.

  8. Click Restart under Manage System.

  9. Click Yes in the confirmation dialog.

20.2 Performing Backups and Recoveries

Table 20-1 lists the static artifacts to back up in the 11g Oracle Fusion Financials enterprise deployment.

Table 20-1 Static Artifacts to Back Up in the 11g CRM Enterprise Deployment

Type Host Location Tier

ORACLE HOME (DB)

FUSIONDBHOST1 and FUSIONDBHOST2

The location is user-defined. Generally, /u01/oracle.

Data tier

MW HOME (Oracle HTTP Server)

WEBHOST1 and WEBHOST2

ORACLE_BASE/products

ORACLE_BASE/config

Web tier

MW HOME
(/APPS_HOME)

FINHOST1 and FINHOST2

ORACLE_BASE/products

ORACLE_BASE/config

Application tier

Installation-related files

 

/u01/oracle/repository, OraInventory, .home, oraInst.loc, oratab

N/A


Table 20-2 lists the run-time artifacts to back up in the 11g Oracle Fusion Financials enterprise deployment.

Table 20-2 Run-Time Artifacts to Back Up in the 11g CRM Enterprise Deployment

Type Host Location Tier

DOMAIN HOME

FINHOST1 and FINHOST2

/u02/local/oracle/config/domains/HOSTNAME/domain_name

Application tier

Application artifacts (EAR and WAR files)

FINHOST1 and FINHOST2

Find the application artifacts by viewing all of the deployments through the administration console.

Application tier

Oracle HTTP Server instance home

WEBHOST1 and WEBHOST2

ORACLE_BASE/config/CommonDomain_webtier

Web tier

Oracle RAC databases

FUSIONDBHOST1 and FUSIONDBHOST2

The location is user-defined.

Data tier


For more information on backup and recovery of Oracle Fusion Middleware components, see Oracle Fusion Middleware Administrator's Guide.

20.3 Monitoring the Topology

For information on monitoring the Oracle Fusion Customer Relationship Management topology, see the following documents:

20.4 Migrating from a Test Environment to a Production Environment

For information, see "Moving Components for Oracle Fusion Applications Across Environments" in the Oracle Fusion Applications Administrator's Guide.

20.5 Configuring Log File Rotation

An ODL log is a set of log files that includes the current ODL log file and zero or more ODL Archives (segment files) that contain older messages. As the log file grows, new information is added to the end of the log file, server_name-diagnostic.log. When the log file reaches the rotation point, it is renamed and a new log file, server_name-diagnostic.log is created. You specify the rotation point, by specifying the maximum ODL segment size, or, for the log files of some components, the rotation time and rotation frequency.

Segment files are created when the ODL log file server_name-diagnostic.log reaches the rotation point. That is, the server_name-diagnostic.log is renamed to server_name-diagnostic-n.log, where n is an integer, and a new server_name-diagnostic.log file is created when the component generates new diagnostic messages.

To limit the size of the ODL log, you can specify:

Note:

After you change the log file rotation, the configuration is reloaded dynamically. It may take 1 or 2 seconds to reload the configuration.

The following topics describe how to change the rotation:

20.5.1 Specifying Log File Rotation Using Oracle Enterprise Manager

To configure log file rotation using Oracle Enterprise Manager for a component:

  1. Log in to the component (for example, http://crminternal.mycompany.com/em).

  2. From the navigation pane, select the component (for example, navigate to Farm_CommonDomain > WebLogic Domain >CommonDomain > ESSCluster > ess_server1).

  3. Select ess_server1.

  4. From the WebLogic Server dropdown list, select Logs > Log Configuration, then select the Log Files tab.

    Note:

    The WebLogic Server dropdown list is located at the top left corner of the right panel.

  5. In the table, select the logger and click Edit Configuration.

    The Edit Log File dialog box is displayed.

  6. In the Rotation Policy section, you can select one of the following:

    • Size Based: If you select this, enter the following:

      • For Maximum Log File Size, enter the size in MB, for example, 15.

      • For Maximum Size of All Log Files, enter the size in MB, for example, 150.

    • Time Based: If you select this, enter the following:

      • For Start Time, enter the date when you want the rotation to start. For example, enter 10-SEP-2009.

      • For Frequency, you can select Minutes and enter the number of minutes, or you can select Hourly, Daily, or Weekly.

      • For Retention Period, you can specify how long the log files are kept. You can select Minutes and enter the number of minutes, or you can specify Day, Week, Month, or Year.

        Specifying a shorter period means that you use less disk space, but are not able to retrieve older information.

  7. Click OK.

  8. In the confirmation window, click Close.

20.5.2 Specifying Log File Rotation Using WLST

To specify log file rotation using WLST, use the configureLogHandler command. You can specify size-based rotation or time-based rotation.

For example, to specify that the log files rotate daily and that they are retained for a week, use the following command:

configureLogHandler(name='odl-handler', rotationFrequency='daily',
                    retentionPeriod='week')

To specify that the size of a log file does not exceed 5MB and rotates when it reaches that size, use the following command:

configureLogHandler(name='odl-handler', maxFileSize='5M')

20.6 Patching the Topology

For information, see the Oracle Fusion Applications Patching Guide.

20.7 Auditing

Oracle Fusion Middleware Audit Framework is a new service in Oracle Fusion Middleware 11g, designed to provide a centralized audit framework for the middleware family of products. The framework provides audit service for platform components such as Oracle Platform Security Services (OPSS) and Oracle Web Services. It also provides a framework for JavaEE applications, starting with Oracle's own JavaEE components. JavaEE applications will be able to create application-specific audit events. For non-JavaEE Oracle components in the middleware, such as C or JavaSE components, the audit framework also provides an end-to-end structure similar to that for JavaEE applications.

Figure 20-2 is a high-level architectural diagram of the Oracle Fusion Middleware Audit Framework.

Figure 20-2 Audit Event Flow

Audit Event Flow

The Oracle Fusion Middleware Audit Framework consists of the following key components:

For more introductory information for the Oracle Fusion Middleware Audit Framework, see the "Introduction to Oracle Fusion Middleware Audit Framework" chapter in the Oracle Fusion Middleware Application Security Guide.

For information on how to configure the repository for Oracle Fusion Middleware Audit Framework, see the "Configuring and Managing Auditing" chapter in the Oracle Fusion Middleware Application Security Guide.

The enterprise deployment topology does not include Oracle Fusion Middleware Audit Framework configuration. The ability to generate audit data to the bus-stop files and the configuration of the audit loader will be available once the products are installed. The main consideration is the audit database repository where the audit data is stored. Because of the volume and the historical nature of the audit data, it is strongly recommended that customers use a separate database from the operational store or stores being used for other middleware components.

20.8 Troubleshooting

This section covers the following topics:

20.8.1 Page Not Found When Accessing soa-infra Application Through Load Balancer

Problem: A 404 "page not found" message is displayed in the web browser when you try to access the soa-infra application using the load balancer address. The error is intermittent and Oracle SOA Suite servers appear as "Running" in the WLS Administration Console.

Solution: Even when the Oracle SOA Suite Managed Servers may be up and running, some of the applications contained in them may be in Admin, Prepared or other states different from Active. The soa-infra application may be unavailable while the Oracle SOA Suite server is running. Check the Deployments page in the Administration Console to verify the status of the soa-infra application. It should be in "Active" state. Check the Oracle SOA Suite server's output log for errors pertaining to the soa-infra application and try to start it from the Deployments page in the Administration Console.

20.8.2 soa-infra Application Fails to Start Due to Deployment Framework Issues (Coherence)

Problem: The soa-infra application fails to start after changes to the Coherence configuration for deployment have been applied. The Oracle SOA Suite server output log reports the following:

Cluster communication initialization failed. If you are using multicast, Please make sure multicast is enabled on your network and that there is no interference on the address in use. Please see the documentation for more details.

Solutions:

  • When using multicast instead of unicast for cluster deployments of Oracle SOA Suite composites, a message similar to the above may appear if a multicast conflict arises when starting the soa-infra application (that is, starting the Managed Server on which Oracle SOA Suite runs). These messages, which occur when Oracle Coherence throws a run-time exception, also include the details of the exception itself. If such a message appears, check the multicast configuration in your network. Verify that you can ping multicast addresses. In addition, check for other clusters that may have the same multicast address but have a different cluster name in your network, as this may cause a conflict that prevents soa-infra from starting. If multicast is not enabled in your network, you can change the deployment framework to use unicast as described in Oracle Coherence Developer's Guide.

  • When entering well-known address list for unicast (in server start parameters), make sure that the node's addresses entered for the localhost and clustered servers are correct. Error messages like the following are reported in the server's output log if any of the addresses is not resolved correctly:

    oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence
    

20.8.3 Incomplete Policy Migration After Failed Restart of SOA Server

Problem: The SOA server fails to start through the administration console before setting Node Manager property startScriptEnabled=true. The server does not come up after the property is set either. The SOA Server output log reports the following:

SEVERE: <.> Unable to Encrypt data
Unable to Encrypt data.
Check installation/post-installation steps for errors. Check for errors during SOA server startup.

ORABPEL-35010
 .
Unable to Encrypt data.
Unable to Encrypt data.
Check installation/post-installation steps for errors. Check for errors
 during SOA server startup.
 .
 at oracle.bpel.services.common.util.EncryptionService.encrypt(EncryptionService.java:56)
...

Solution: Incomplete policy migration results from an unsuccessful start of the first SOA server in a cluster. To enable full migration, edit the <jazn-policy> element the system-jazn-data.xml file to grant permission to bpm-services.jar:

<grant>
  <grantee>
    <codesource>
<url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar

</url>
    </codesource>
  </grantee>
  <permissions>
    <permission>
      <class>java.security.AllPermission</class>
    </permission>
  </permissions>
</grant>

20.8.4 Oracle SOA Suite Server Fails to Start Due to Maximum Number of Processes Available in Database

Problem: A Oracle SOA Suite server fails to start. The domain has been extended for new types of Managed Server or the system has been scaled up (added new servers of the same type). The Oracle SOA Suite server output log reports the following:

<Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "SOADataSource-rac0": Listener refused the connection with the following error:

ORA-12516, TNS:listener could not find available handler with matching protocol stack >

Solution: Verify the number of processes in the database and adjust accordingly. As the SYS user, issue the SHOW PARAMETER command:

SQL> SHOW PARAMETER processes

Set the initialization parameter using the following command:

SQL> ALTER SYSTEM SET processes=greater than 2500 SCOPE=SPFILE

Restart the database.

Note:

The method that you use to change a parameter's value depends on whether the parameter is static or dynamic, and on whether your database uses a parameter file or a server parameter file. See the Oracle Database Administrator's Guide for details on parameter files, server parameter files, and how to change parameter values.

20.8.5 Administration Server Fails to Start After a Manual Failover

Problem: Administration Server fails to start after the Administration Server node failed and manual failover to another nodes is performed. The Administration Server output log reports the following:

<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/edg_domain/aserver/edg_domain/servers/AdminServer/data/ldap/ldapfiles. Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>

Solution: When restoring a node after a node crash and using shared storage for the domain directory, you may see this error in the log for the Administration Server due to unsuccessful lock cleanup. To resolve this error, remove the file ORACLE_HOME/config/domains/FINHOST1/DomainName/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok.

20.8.6 Error While Activating Changes in Administration Console

Problem: Activation of changes in Administration Console fails after changes to a server's start configuration have been performed. The Administration Console reports the following when clicking Activate Changes:

An error occurred during activation of changes, please see the log for details.
 [Management:141190]The commit phase of the configuration update failed with an exception:
In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean

Solution: This may happen when start parameters are changed for a server in the Administration Console. In this case, provide user name/password information in the server start configuration in the Administration Console for the specific server whose configuration was being changed.

20.8.7 SOA Server Not Failed Over After Server Migration

Problem: After reaching the maximum restart attempts by local Node Manager, Node Manager in the failover node tries to restart it, but the server does not come up. The server seems to be failed over as reported by Node Manager's output information. The VIP used by the SOA server is not enabled in the failover node after Node Manager tries to migrate it (if config in the failover node does not report the VIP in any interface). Executing the command sudo ifconfig $INTERFACE $ADDRESS $NETMASK does not enable the IP in the failover node.

Solution: The rights and configuration for sudo execution should not prompt for a password. Verify the configuration of sudo with your system administrator so that sudo works without a password prompt.

20.8.8 SOA Server Not Reachable From Browser After Server Migration

Problem: Server migration is working (SOA server is restarted in the failed over node), but the Virtual_Hostname:8001/soa-infra URL cannot be accessed in the web browser. The server has been "killed" in its original host and Node Manager in the failover node reports that the VIP has been migrated and the server started. The VIP used by the SOA server cannot be pinged from the client's node (that is, the node where the browser is being used).

Solution: The arping command executed by Node Manager to update ARP caches did not broadcast the update properly. In this case, the node is not reachable to external nodes. Either update the nodemanager.properties file to include the MACBroadcast or execute a manual arping:

/sbin/arping -b -q -c 3 -A -I INTERFACE ADDRESS > $NullDevice 2>&1

Where INTERFACE is the network interface where the virtual IP is enabled and ADDRESS is the virtual IP address.

20.8.9 Oracle Access Manager Configuration Tool Does Not Remove URLs

Problem: The Oracle Access Manager Configuration Tool has been used and a set of URLs was added to the policies in Oracle Access Manager. One of multiple URLs had a typo. Executing the Oracle Access Manager Configuration Tool again with the correct URLs completes successfully; however, when accessing Policy Manager, the incorrect URL is still there.

Solution: The Oracle Access Manager Configuration Tool only adds new URLs to existing policies when executed with the same app_domain name. To remove a URL, use the Policy Manager Console in Oracle Access Manager. Log on to the Access Administration site for Oracle Access Manager, click on My Policy Domains, click on the created policy domain (SOA_EDG), then on the Resources tab, and remove the incorrect URLs.

20.8.10 Redirecting of Users to Login Screen After Activating Changes in Administration Console

Problem: After configuring Oracle HTTP Server and LBR to access the Oracle WebLogic Administration Console, some activation changes cause the redirection to the login screen for the Administration Console.

Solution: This is the result of the console attempting to follow changes to port, channel, and security settings as a user makes these changes. For certain changes, the console may redirect to the Administration Server's listen address. Activation is completed regardless of the redirection. It is not required to log in again; users can simply update the URL to fin.mycompany.com/console/console.portal and directly access the home page for the Administration Console.

Note:

This problem will not occur if you have disabled tracking of the changes described in this section.

20.8.11 Redirecting of Users to Administration Console's Home Page After Activating Changes to OAM

Problem: After configuring OAM, some activation changes cause the redirection to the Administration Console's home page (instead of the context menu where the activation was performed).

Solution: This is expected when OAM SSO is configured and the Administration Console is set to follow configuration changes (redirections are performed by the Administration Server when activating some changes). Activations should complete regardless of this redirection. For successive changes not to redirect, access the Administration Console, select Preferences, then Shared Preferences, and deselect the "Follow Configuration Changes" check box.

20.8.12 Configured JOC Port Already in Use

Problem: Attempts to start a Managed Server that uses the Java Object Cache (JOC), such as OWSM Managed Servers, fail. The following errors appear in the logs:

J2EE JOC-058 distributed cache initialization failure
J2EE JOC-043 base exception:
J2EE JOC-803 unexpected EOF during read.

Solution: Another process is using the same port that JOC is attempting to obtain. Either stop that process, or reconfigure JOC for this cluster to use another port in the recommended port range.

20.8.13 Out-of-Memory Issues on Managed Servers

Problem: You are experiencing out-of-memory issues on Managed Servers.

Solution: Increase the size of the memory heap allocated for the Java VM to at least one gigabyte:

  1. Log in to the Oracle WebLogic Administration Console.

  2. Click Environment, then Servers.

  3. Click on a Managed Server name.

  4. Open the Configuration tab.

  5. Open the Server Start tab in the second row of tabs.

  6. Include the memory parameters in the Arguments box, for example:

    -Xms3072m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m
    

    Note:

    Please note that the memory parameter requirements may differ between various Java Virtual Machines (Sun, JRockit, or others). See "Increasing the Java VM Heap Size for Managed Servers" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite for further details.

  7. Save the configuration changes.

  8. Restart all running Managed Servers.

20.8.14 JDBC Connection Reset Appears When on OEL 5.4

Problem: When you are on Oracle Enterprise Linux (OEL) 5.4, a Java Database Connectivity (JBDC) connection reset appears.

Solutions:

  • Upgrade to OEL 5.6.

  • As root, do the following:

    1. Download and install the rngd tool.

    2. Execute the following commands (in order):

      rngd -r /dev/urandom -o /dev/random
      
      cat /proc/sys/kernel/random/entropy_avail 
      
    3. Ensure that entropy returns a number greater than 1000.

20.8.15 Missing JMS Instances on Oracle BI Publisher Scheduler Diagnostics Page

In some cases, only one JMS instance is visible on the Oracle BI Publisher Scheduler diagnostics page, rather than all instances in the cluster. This issue is most likely caused by clocks being out of sync. For more information on the importance of synchronizing clocks on all nodes in the cluster, see "Clock Synchronization" in the chapter "Database and Environment Preconfiguration" in Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence.

20.8.16 Oracle BI Publisher Jobs in Inconsistent State After Managed Server Shutdown

Before shutting down the Managed Server on which Oracle BI Publisher is running, it is a best practice (but not mandatory) to wait for all running Oracle BI Publisher jobs to complete, or to cancel any unfinished jobs using the Report Job History page. Otherwise, the shutdown might cause some jobs to incorrectly stay in a running state.

20.8.17 JMS Instance Fails in an Oracle BI Publisher Cluster

On rare occasions, a JMS instance is missing from an Oracle BI Publisher Scheduler cluster. To resolve this issue, restart the Oracle BI Publisher application from the Oracle WebLogic Server Administration Console.

To restart Oracle BI Publisher:

  1. Log in to the Administration Console.

  2. Click Deployments in the Domain Structure window.

  3. Select bipublisher(11.1.1).

  4. Click Stop.

  5. After the application stops, click Start.

20.8.18 Administration Console Redirects from Internal URL to Container URL after Activation

Log in to the Administration Console and do the following:

  1. Click Preferences in the top navigation bar.

  2. Select the Shared Preferences tab.

  3. De-select Follow Configuration Changes.

  4. Click Save.