9 Scaling Out the Oracle Fusion Customer Relationship Management Domain

This chapter describes how to scale out the Oracle Fusion Customer Relationship Management domain.

This chapter includes the following topics:

• Section 9.1, "Overview of the Oracle Fusion Customer Relationship Management Domain"

• Section 9.2, "Prerequisites for Scaling Out the Oracle Fusion Customer Relationship Management Domain"

• Section 9.3, "Configuring Oracle Coherence for the odi_server Managed Server"

• Section 9.4, "Adding a New Machine in the Oracle WebLogic Server Console"

• Section 9.5, "Packing and Unpacking the Managed Server Domain Home"

• Section 9.6, "Cloning Managed Servers and Assigning Them to FINHOST2"

• Section 9.7, "Oracle HTTP Server Configuration"

• Section 9.8, "Configuring Server Migration for the Managed Servers"

• Section 9.9, "Validating the System"

9.1 Overview of the Oracle Fusion Customer Relationship Management Domain

The Oracle Fusion Customer Relationship Management application is a very distributed and modularized one. Applications within Oracle Fusion Customer Relationship Management, which are deployed on the domain, are the following:

• Contract Management

• CRM Analytics

• CRM Common

In addition to the applications, the Oracle Fusion Customer Relationship Management domain also contains Oracle Fusion Customer Relationship Management Analytics, which is the Oracle BI Enterprise Edition broker application that interfaces with Oracle Application Development Framework, Oracle BI Enterprise Edition, and Oracle Data Integrator agent for data import flow.

Figure 2-4 in Chapter 2, "Introduction to the Enterprise Deployment Reference Topologies,"shows the topology for the Oracle Fusion Customer Relationship Management domain within the overall reference enterprise deployment topology.

9.2 Prerequisites for Scaling Out the Oracle Fusion Customer Relationship Management Domain

Before you begin, ensure that 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."

9.3 Configuring Oracle Coherence for the odi_server Managed Server

Oracle recommends using unicast communication in odi_server enterprise deployments, unless use of multicast is a must. Consider using multicast communication for large Oracle Data Integrator clusters with approximately 20 or more Oracle Data Integrator Managed Servers.

Note:

An incorrect configuration of the Oracle Coherence framework that is used for deployment may prevent the odi_server Managed Server from starting. Oracle recommends the configuration described in this section.

Unicast communication does not enable nodes to discover other cluster members automatically when a new Oracle Data Integrator server is added to a cluster. 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. Consequently, 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 Oracle Data Integrator 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 odi_server Managed Servers, specify enough nodes so that at least one of them is running at any given time.

Specify the nodes using the the -Doracle.odi.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. 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.

To add the virtual-host names to Oracle Coherence:

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

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

3. Click Servers.

   The Summary of Servers page appears.

4. Select odi_server1 (represented as a hyperlink) from the column of the table.

   The Settings page appears.

5. Click Lock & Edit.

6. Click the Server Start tab.

7. Change the existing properties if necessary, and enter new properties into the Arguments field:

   -Dtangosol.coherence.localport=9066
   -Dtangosol.coherence.localhost=FINHOST1
   -Doracle.odi.coherence.wka1=FINHOST1
   -Doracle.odi.coherence.wka1.port=9066
   -Doracle.odi.coherence.wka2=FINHOST2
   -Doracle.odi.coherence.wka2.port=9066
   -DJDBCProgramName=DS/CRMDomain/odi_server1
   -Dserver.group=ODICluster
   

   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.

9. Navigate to CRMDomain > Environment > Servers and select the Control tab.

10. Select the odi_server1 Managed Server in the table, click Shutdown, and then select the Force Shutdown Now option from dropdown list.

11. Start the odi_server1 Managed Server.

9.4 Adding a New Machine in the Oracle WebLogic Server Console

To add a new machine:

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

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

   • Machine operating system - Unix

5. Click Next.

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

   • Type - SSL

   • Listen Address - <FINHOST2>

     Note:

     The "localhost" default value here is wrong.

   • Listen port - 5556

7. Click Finish and activate the changes.

9.5 Packing and Unpacking the Managed Server Domain Home

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

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:

   FINHOST2> ./pack.sh -managed=true -domain=ORACLE_BASE/config/domains/
   FINHOST1/CRMDomain -template=ORACLE_BASE/user_templates/
   CRMDomain_managed.jar -template_name="CRM_Managed_Server_Domain" 
   

3. Ensure that /u02/local/oracle/config/domains/FINHOST2/CRMDomain is empty, and then run the unpack command:

   FINHOST2> ./unpack.sh -domain=/u02/local/oracle/config/domains/
   FINHOST2/CRMDomain -template=ORACLE_BASE/user_templates/CRMDomain_managed.jar
   

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

9.6 Cloning Managed Servers and Assigning Them to FINHOST2

To add a Managed Server and assign it to FINHOST2:

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

2. Navigate to FinancialDomain > Environment > Servers.

3. Switch to Lock & Edit mode.

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

5. Specify the following server identity attributes:

   • Server Name - ContractManagementServer_2

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

   • Server Listen Address - <FINHOST2>

   • Server Listen Port - leave "as is"

6. Click OK.

   You now should see the newly cloned sales server, ContractManagementServer_2.

7. Click ContractManagementServer_2 and change the following attributes:

   • Machine - <FINHOST2>

   • Cluster Name - accept the default, ContractManagementCluster

     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. Navigate to CRMDomain > Environment > Servers.

10. From the Name column, click the ContractManagementServer_2 scaled-out server link.

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

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

13. Do the following:

    1. Change the Custom Identity Keystore path to point to the ORACLE_BASE/config/keystores/FINHOST2_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.3, "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/config/keystores/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.3, "Creating the Identity Keystore on FINHOST2."

    8. Re-enter the Custom Trust Keystore Passphrase.

    9. Click Save.

14. Select the SSL tab.

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

    2. Change the Private Key Alias to FINHOST2_fusion.

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

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

    5. Click Save.

15. Select the Server Start tab and do the following:

    1. 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/ICDomain/ContractManagementServer_2
       -Dserver.group=ContractManagementCluster
       

    2. When cloning the odi_server2 Managed Server only, ensure that the local coherence host and the coherence well known address (wka) properties are changed to the following:

       -Dtangosol.coherence.localport=9066
       -Dtangosol.coherence.localhost=FINHOST2
       -Doracle.odi.coherence.wka1=FINHOST2
       -Doracle.odi.coherence.wka1.port=9066
       -Doracle.odi.coherence.wka2=FINHOST1
       -Doracle.odi.coherence.wka2.port=9066
       -DJDBCProgramName=DS/CRMDomain/odi_server2
       -Dserver.group=ODICluster
       

    3. Click Save.

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

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

18. Click Activate Changes.

19. Repeat Steps 2 to 18 for all the Managed Servers on this domain.

20. Stop the domain's Administration Server:

    FINHOST1> ORACLE_BASE/config/domains/FINHOST1/CRMDomain/bin/stopWebLogic.sh
    

21. Set the following environment variable on FINHOST2:

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

22. Start the domain's Administration Server:

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

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

23. Run the newly created Managed Servers:

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

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

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

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

9.7 Oracle HTTP Server Configuration

To configure Oracle HTTP Server:

1. Do the following: :

   • On WEBHOST1, change directory to ORACLE_BASE/config/CommonDomain_webtier/config/OHS/ohs1/moduleconf

   • On WEBHOST2, change directory to ORACLE_BASE/config/CommonDomain_webtier1/config/OHS/ohs2/moduleconf

2. Copy FusionVirtualHost_crm.conf to FusionVirtualHost_crm.conf.org.

3. Edit the FusionVirtualHost_crm.conf file, adding the scaled-out host and port to all the WebLogic Application Clusters. Add this to both the Internal and External part of the FusionVirtualHost_crm.conf file. Example 9-1 shows sample code for ContactManagementServer.

   Notes:

   • Do not add these values for Oracle Enterprise Manager, Oracle WebLogic Server Administration Console, or Oracle Authorization Policy Manager.

   • If the Managed Servers are running on VIPs, replace FINHOST1 and FINHOST2 with the VIP addresses in Example 9-1.

   Example 9-1 Sample "ContractManagementServer" Code

   <Location /contractManagement>
           SetHandler weblogic-handler
           WebLogicCluster <FINHOST1:port>,<FINHOST2:port> 
       </Location>
   

4. Repeat Step 3 for all applications.

5. Do the following to restart Oracle HTTP Server:

   On WEBHOST1:

   • Change directory to ORACLE_BASE/config/CommonDomain_webtier/bin

   • Enter the following:

     WEBHOST1> ./opmnctl stopall
     WEBHOST1> ./opmnctl startall
     

   On WEBHOST2:

   • Change directory to ORACLE_BASE/config/CommonDomain_webtier1/bin

   • Enter the following:

     WEBHOST2> ./opmnctl stopall
     WEBHOST2> ./opmnctl startall
     

9.8 Configuring Server Migration for the Managed Servers

Server migration is required for proper failover of Oracle Fusion Financials components in the event of failure in any of the FINHOST1 and FINHOST2 nodes. For more information, see Chapter 18, "Setting Up Server Migration for an Enterprise Deployment."

9.9 Validating the System

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

To verify the URLs:

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

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

   • https://crmexternal.mycompany.com/contractManagement/faces/ContractsDashboard

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

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 FINHOST2 and verify that they are running on FINHOST1 and FINHOST2.