PK
]@oa, mimetypeapplication/epub+zipPK ]@ iTunesMetadata.plist~
This chapter describes how to scale out the Oracle Fusion Customer Relationship Management domain.
This chapter includes the following topics:
Section 8.1, "Overview of the Oracle Fusion Customer Relationship Management Domain"
Section 8.3, "Adding a New Machine in the Oracle WebLogic Server Console"
Section 8.4, "Packing and Unpacking the Managed Server Domain Home"
Section 8.5, "Cloning Managed Servers and Assigning Them to CRMHOST2"
Section 8.8, "Configuring Server Migration for the Managed Servers"
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:
Marketing
Sales
Territory Management
Customer Management
Order Capture
Email Marketing
OutLook/Mobile
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-3 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.
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 CRMHOST2
should be the same as the user on CRMHOST1
The directory structure /u01/oracle
is mounted to same shared file system as CRMHOST1
The directory structure /u02/local/oracle/config
on CRMHOST2
has been created
The initial Oracle Fusion Customer Relationship Management deployment on CRMHOST1
has already been done and verified by provisioning
To add a new machine:
Log in to the Administration Server: http://
crminternal
.mycompany.com:7777/console
.
Navigate to CRMDomain > Environment > Machines.
LocalMachine is located in the right-hand pane.
In the left-hand pane, click Lock & Edit.
In the right-hand pane, first click New to add the remote machine, and then specify the following:
Name - enter CRMHOST2
Machine operating system - Unix
Click Next.
In the window that opens, set the following attributes:
Type - SSL
Listen Address - <CRMHOST2
>
Note: The "localhost" default value here is wrong. |
Listen port - 5556
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. |
Since the CRMHOST1
domain directory file system is also available from CRMHOST2
, both the pack
and unpack
commands can be executed from CRMHOST2
.
To pack and unpack the Managed Server domain home:
Change directory to ORACLE_BASE
/products/fusionapps/oracle_common/common/bin
.
Run the pack
command:
CRMHOST2
> ./pack.sh -managed=true -domain=ORACLE_BASE
/config/domains/CRMHOST1
/CRMDomain -template=ORACLE_BASE/
user_templates/ CRMDomain_managed.jar -template_name="CRM_Managed_Server_Domain"
Ensure that /u02/local/oracle/config/domains/
CRMHOST2
/CRMDomain
is empty, and then run the unpack
command:
CRMHOST2
> ./unpack.sh -domain=/u02/local/oracle/config/domains/CRMHOST2
/CRMDomain -template=ORACLE_BASE
/user_templates/CRMDomain_managed.jar
Here, ORACLE_BASE
is shared, and /u02/local
is local to CRMHOST2
.
To add a Managed Server and assign it to CRMHOST2
:
Log in to the Administration Server: http://
crminternal
.mycompany.com:7777/console
.
Navigate to CRMDomain > Environment > Servers.
Switch to Lock & Edit mode.
Select the Managed_Server checkbox (for example, SalesServer_1) and then click Clone.
Specify the following server identity attributes:
Server Name - SalesServer_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 - <CRMHOST2
>
Server Listen Port - leave "as is"
Click OK.
You now should see the newly cloned sales server, SalesServer_2
.
Click SalesServer_2 and change the following attributes:
Machine - <CRMHOST2
>
Cluster Name - accept the default, SalesCluster
Note: Ensure that this cluster name is the same as the cluster name of the original Managed Server. |
Click Save and then Activate Changes.
Navigate to CRMDomain > Environment > Servers.
From the Name column, click the SalesServer_2 scaled-out server link.
Click Lock & Edit, and then select the Configuration tab.
Select the Keystores tab, and ensure that the keystores value is Custom Identity and Custom Trust.
Do the following:
Change the Custom Identity Keystore path to point to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/
CRMHOST2
_fusion_identity.jks
file.
Leave the Custom Identity Keystore type blank.
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 CRMHOST2."
Re-enter the Confirm Custom Identity Keystore Passphrase.
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.
Leave the Custom Trust Keystore type blank.
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 CRMHOST2."
Re-enter the Custom Trust Keystore Passphrase.
Click Save.
Select the SSL tab.
Make sure that Identity and Trust Locations is set to Keystores.
Change the Private Key Alias to CRMHOST2
_fusion
.
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 CRMHOST2."
Re-enter the keypassword from Step c for the Confirm Private Key Passphrase.
Click Save.
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/CRMDomain/SalesServer_2 -Dserver.group=SalesCluster
Click Save.
Select the Logging tab, and then select the HTTP tab.
Do the following:
Change the Log file name to logs/access.log.%yyyyMMdd%
.
Change the rotation type to By Time.
Leave the Limit number of retained files option unchecked.
Leave the Rotate log file on startup option unchecked.
Click Save.
Expand Advanced.
Change the format to Extended.
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)
Click Save.
Click Activate Changes.
Repeat Steps 2 to 18 for all the Managed Servers on this domain.
Set the following environment variable on CRMHOST2
:
WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE
/
products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks"
Stop the domain's Administration Server:
CRMHOST1
>ORACLE_BASE
/config/domains/CRMHOST1
/CRMDomain/bin/stopWebLogic.sh
Restart the domain's Administration Server:
CRMHOST2
>ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/bin/wlst.shCRMHOST2
> nmConnect(username='username
', password='password
', domainName='CRMDomain', host='CRMHOST1
',port='5556', nmType='ssl', domainDir='ORACLE_BASE
/config/domains/CRMHOST1
/CRMDomain')CRMHOST2
> nmStart('AdminServer')
Note: The username and password used in the |
Run the newly created Managed Servers:
Log in to the Administration Server: http://
crminternal
.mycompany.com:7777/console
.
Navigate to CRMDomain > Environment > Servers > Control.
Select the newly created Managed Servers and click Start.
Navigate to CRMDomain > Environment > Servers and check the State to verify that the newly created Managed Servers are running.
Data Quality is an Informatica tool that provides the following:
A matching function, which allows you to search, match, and identify duplicate customer records based on key customer attributes such as name, address, date of birth, Social Security Number, or tax ID number. It also includes data quality connector, a generalized interface that is capable of making real-time and batch requests to an external data-cleansing engine.
An address-cleansing feature, which corrects and validates address data based on postal requirements.
Implementing Data Quality requires four steps:
Obtaining postal reference data and license keys.
Setting up the Data Quality Engine, also known as Informatica Identity Resolution (IIR).
Configuring Data Quality Connector and IIR in Oracle Fusion Functional Setup Manager.
Creating a second Data Quality server on CRMHOST2
.
Prior to configuring data quality for scale out, you must obtain postal reference data and license key files from AddressDoctor. For information about how to obtain these, see the licensing documentation.
To set up the data quality engine:
On CRMHOST1
, change directory to ORACLE_BASE
/products/InformaticaIR/bin
.
Run the following commands:
CRMHOST1
> bashCRMHOST1
> . ./setfusionEnv.shCRMHOST1
> ./liupCRMHOST1
> ./idsup
Start ./idsconc -a
.
On the launched console, select Rulebase Type=SSA and Alias=rtunitrb and click OK. Then click Yes to create a new rulebase.
In the IIR console, navigate to System > New > Create a system from SDF.
Enter the following system information:
System Name - FusionDQRealtime
System Definition File - ORACLE_BASE
/products/InformaticaIR/ids/FusionDQRealtime.sdf
DB Type - SSA
Alias - fusion_s01
Click OK, and then click Close to dismiss the Create/System window.
Navigate to System menu > Select > System Name: FusionDQRealtime and click OK.
Navigate to System menu > Load IDT to start loading the individual IDT tables, one by one, until the following IDTs are completed:
load_location load_organization load_org_address load_person load_per_address load_per_phone
Close the IIR Console started in Step 2 and run the following commands to stop the IIR server:
CRMHOST1
>ORACLE_BASE
/products/InformaticaIR/bin/idsdownCRMHOST1
>ORACLE_BASE
/products/InformaticaIR/bin/lidown
Assuming you have received the postal reference data and license key files from AddressDoctor (that you requested in Section 8.6.1), run the following commands:
CRMHOST1
> cd ORACLE_BASE/products/InformaticaIR/ssaas/ad5/ad/dbCRMHOST1
> cpmylocation
/key .CRMHOST1
> cpmylocation
/*.MD .
mylocation
is the directory where you copied the license key and the postal reference data.
*.MD
is the postal data reference file. key
is a text file that contains the AddressDoctor license.
AddressDoctor supports 248 countries. Each *.MD
file is per country or a group of countries. Each of these files should be copied to the *.MD
directory.
Run the following commands to start the IIR server:
CRMHOST1
>ORACLE_BASE
/products/InformaticaIR/bin/liupCRMHOST1
>ORACLE_BASE
/products/InformaticaIR/bin/idsup
From the IIR Console, do the following to start the UPD Synchronizer:
Run the following command:
CRMHOST1
>ORACLE_BASE
/products/InformaticaIR/bin/idsconc -a
On the launched console, select Rulebase Type=SSA and Alias=rtunitrb, and click OK to go the RuleBase.
In the IIR console, go to System > Select and select FusionDQRealtime.
Go to Tools > Synchronizer > Run Synchronizer and click OK to accept all the defaults shown in the Update Synchronizer popup window.
Note: Ensure that the IDT Name=(all) option is selected. |
To configure the data quality connector and IIR:
Log in to Oracle Fusion Functional Setup Manager as an administrator. For example, http://
commoninternal
.mycompany.com:7777/homePage/faces/AtkHomePageWelcome
.
Search for the task "Manage Data Quality Server Configuration."
Click Go to Task to open the Manage Data Quality Server Configurations page, and then click Search to find all existing configurations.
Select Realtime and Batch Basic Server and click Edit.
Enter the server IP address and port of the IIR search server you set up as the IIR matching server.
Select Realtime Cleanse Server, click Edit, and repeat Step 5.
Select Batch Cleanse Server, click Edit, and repeat Step 5.
Search for the task "Manage Data Quality Synchronization Configuration".
Click Refresh Identity Table Information to refresh IDT repository information.
Select Enable for Sync for each IDT.
Click Schedule Synchronization Process and then Advanced.
Select Using a schedule.
Select Hourly/Minute from the Frequency dropdown list. (This frequency should be determined by the business requirement.)
Enter "every 5 minutes" for this example. (This "every 5 minutes" sample should be determined by the business requirement.)
Select a "next few days" end date from the calender. (This "few days" sample should be determined by the business requirement.)
Submit the scheduled Sync ESS job.
Do the following to validate that Data Quality is up and running:
Ensure that the Customer Center application is running.
In Customer Center, create a unique organization and then try to create that same organization again.
If Data Quality is working correctly, a popup window will display telling you that you cannot create that organization because it already exists.
To create a second data quality server:
Run the following command:
CRMHOST2
> cdORACLE_BASE
/repository/installers/iir/fusion_iir
Edit the install.props
file to include the following values:
############################################## # USE ABSOLUTE PATHS FOR ALL ############################################## # These environment variables are required to be set for # IIR to be able to use the ORACLE DB CLIENT ############################################## ORACLE_HOME=ORACLE_BASE/products/dbclient TNS_ADMIN=ORACLE_BASE/products/dbclient/network/admin LD_LIBRARY_PATH=ORACLE_BASE/products/dbclient/lib ############################################## # These properties are required to be set for # IIR to be installed in the right directory ############################################## FUSION_STAGE_DIR=ORACLE_BASE/repository/installers/iir IIR_STAGE_DIR=ORACLE_BASE/repository/installers/iir IIR_VERSION=IIR_901sp1_linux_amd64 IIR_TOP=ORACLE_BASE/products/IIR2 ############################################## # These properties are required to be set for IIR to be # able to connect to the Oracle DB to install Schema Objects ############################################## IIR_DB_HOSTNAME=FUSIONDBHOST1 IIR_DB_PORT=1521 IIR_DB_SID=fusiondb1 IIR_DB_USER=fusion_dq IIR_DB_PASSWD=PASSWORD ################################################# # ALL THESE PROPERTIES ARE NEEDED BY THE INSTALLER # DO NOT MODIFY THESE UNLESS NECESSARY ################################################# IIR_INSTALL_LOG_LOC=ORACLE_BASE/repository/installers/iir/fusion_iir IIR_INSTALL_TYPE=all IIR_INCLUDE_DOC=yes ############################################## # Default is one Server Instance ############################################## IIR_INSTANCE_1_PORT=1660 ############################################## # Not Implemented yet ############################################## IIR_IN+xSTANCE_2_PORT= ############################################## # This option is needed if you want Search to be accessible through a Browser ############################################## IIR_HTTP=Y ############################################## # This is for Installing the IIR Control and Sync Objects ( needed only for the #first time) ############################################## INSTALL_IIR_OBJECTS=N ############################################## # This is needed for OEM Key ############################################## SSALI_MZXPQRS=STANISLAUS
Run the following command:
./runInstaller.sh install.props > test_console
The installation is now complete.
Run the create_secondary_server.sql
script in ORACLE_BASE
/installers/iir/fusion_iir/iir/sql
, passing the following parameters when prompted:
Host - CRMHOST2
Port - IIR Secondary Port
Server Operation Code - IIR_RT_AND_BT_BASIC_MATCH
Server Number - 1
Create Server Only - N
(this creates all required Secondary IIR Server related parameters)
If Cleansing needs to be load balanced, run the create_secondary_server.sql
script twice using the same parameters detailed in this step each time. However, run the Server Operation Code parameter with the following values:
Server Operation Code - IIR_RT_CLEANSE
Server Operation Code - IR_BT_CLEANSE
Also make sure that all the Postal Directories and the License code are set up on CRMHOST2
, as per the Cleansing Setup.
Start IIR on CRMHOST1
, first by starting the Rulebase server, and then by starting the Search server:
CRMHOST1
> cdORACLE_BASE
/products/InformaticaIR/binCRMHOST1
> bashCRMHOST1
> . ./setfusionEnv.shCRMHOST1
> . ../env/isssCRMHOST1
> ./ssasrsv –m{RBPORT1} -gFusionRBSG,ssa:rtunitrb -w1 -1$SSATOP/iirlog/ priRB.log -2$SSATOP/iirlog/priRB.err -3$SSATOP/iirlog/priRB.dbgCRMHOST1
> ./ssasrsv -n{SEPORT1} -gFusionRBSG,ssa:rtunitrb -1$SSATOP/iirlog/ priSE.log -2$SSATOP/iirlog/priSE.err -3$SSATOP/iirlog/priSE.dbg
Start IIR on CRMHOST2
, first by starting the Rulebase server, and then by starting the Search server:
CRMHOST2
> cdORACLE_BASE
/products/InformaticaIR/binCRMHOST2
> bashCRMHOST2
> . ./setfusionEnv.shCRMHOST2
> . ../env/isssCRMHOST2
> ./ssasrsv –m{RBPORT2} -gFusionRBSG,ssa:rtunitrb -w1 -1$SSATOP/iirlog/ secRB.log -2$SSATOP/iirlog/secRB.err -3$SSATOP/iirlog/secRB.dbgCRMHOST2
> ./ssasrsv -n{SEPORT2} -gFusionRBSG,ssa:rtunitrb -1$SSATOP/iirlog/ secSE.log -2$SSATOP/iirlog/secSE.err -3$SSATOP/iirlog/secSE.dbg
Restart the Oracle Fusion Applications instances (which require DQ) so that the DQ Connector can do load balancing and failover.
Notes:
|
For more information about data quality and IIR, see the following sections in the "Customer Relationship Management" chapter in the Oracle Fusion Applications Post-Installation Guide:
"Setting Up Informatica Identity Resolution"
"Informatica Identity Resolution Setup: Procedures"
To configure Oracle HTTP Server:
On WEBHOST1
:
Change directory to ORACLE_BASE
/config/CommonDomain_webtier/config/OHS/ohs1/moduleconf
.
Copy FusionVirtualHost_crm.conf
to FusionVirtualHost_crm.conf.org
.
Edit the FusionVirtualHost_crm.conf
file, adding the scaled-out host and port to all the WebLogic Application Clusters. Example 8-1 shows sample code for SalesServer.
Notes:
|
Repeat Step 2 for all applications.
Restart Oracle HTTP Server: cd
to ORACLE_BASE
/config/CommonDomain_webtier/bin
and enter the following:
WEBHOST1
> ./opmnctl stopallWEBHOST1
> ./opmnctl startall
Server migration is required for proper failover of Oracle Fusion Customer Relationship Management components in the event of failure in any of the CRMHOST1
and CRMHOST2
nodes. For more information, see Chapter 17, "Setting Up Server Migration for an Enterprise Deployment."
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:
Log in to the CRMDomain
Oracle WebLogic Server Administration Console and stop all the Managed Servers on CRMHOST1
while the Managed Servers on CRMHOST2
are running.
Access the following URLs to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
https://crmexternal.mycompany.com/sales/faces/mooOpportunityHome
https://crmexternal.mycompany.com/crmPerformance/faces/TerritoriesMain
https://crmexternal.mycompany.com/contractManagement/faces/ContractsDashboard
https://crmexternal.mycompany.com/customer/faces/CustomerCtrWorkarea
https://crmexternal.mycompany.com/marketing/faces/LeadsDashboard
https://crmexternal.mycompany.com/orderCapture/faces/SalesCatalogAdmin
Log in to the CRMDomain
Oracle WebLogic Server Administration Console and stop all the Managed Servers on CRMHOST2
.
Start the Managed Servers on CRMHOST1
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the Managed Servers on CRMHOST2
and verify that they are running on CRMHOST1
and CRMHOST2
.
This chapter describes how to scale out the Oracle Business Intelligence domain.
This chapter includes the following topics:
Section 14.1, "Overview of the Oracle Business Intelligence Domain"
Section 14.2, "Prerequisites for Scaling Out the Oracle Business Intelligence Domain"
Section 14.4, "Prerequisites for Scaling Out Oracle Business Intelligence on CRMHOST2"
Section 14.5, "Scaling Out Oracle Business Intelligence Components"
Oracle Fusion Customer Relationship Management Sales and Marketing offerings use following Oracle Business Intelligence components from the Oracle Business Intelligence domain:
Oracle Business Intelligence Analytics
Essbase
Oracle Real-Time Decisions
Oracle Business Intelligence Publisher
Key components of Oracle Fusion Customer Relationship Management, such as Territory (which is the core component of Oracle Fusion Customer Relationship Management), rely on Oracle Business Intelligence Analytics as the source data for planning and optimization.
Oracle Business Intelligence Analytics is the mandatory underlying component for Territory Management, Sales Predictor Engine, and Opportunity Landscape, as they are analytic-centric applications.
Oracle Fusion Customer Relationship Management Sales and Marketing offerings use following Oracle Business Intelligence components from the Oracle Business Intelligence domain:
Oracle Business Intelligence Analytics
Essbase
Oracle Real-Time Decisions
Oracle Business Intelligence Publisher
Figure 2-9 in Chapter 2, "Introduction to the Enterprise Deployment Reference Topologies," shows the topology for the Oracle Business Intelligence domain within the overall reference enterprise deployment topology.
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 CRMHOST2
should the same as the user on CRMHOST1
The directory structure /u01/oracle
is mounted to same shared file system as CRMHOST1
The directory structure /u02/local/oracle/config
on CRMHOST2
has been created
The initial Oracle Fusion Customer Relationship Management deployment on CRMHOST1
has already been done and verified by provisioning
The Administration Console's Follow Configuration Changes feature has been disabled (to eliminate redirections):
Log into the Administration Console (http://biinternal.mycompany.com:7777/console
) and go to Preferences > Shared Preferences.
Deselect Follow Configuration Changes and click Save.
To start the default Node Manager:
Stop any Node Manager running on CRMHOST2
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 Oracle Fusion Customer Relationship Managementand the Oracle Fusion Applications enterprise deployment.
Change directory to ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/nodemanager
and edit the nodemanager.properties
file with the following:
SecureListener=false
Change directory to ORACLE_BASE
/products/fusionapps/oracle_common/common/bin
and run the following script:
./setNMProps.sh
Change directory to ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/bin
and run the following script:
./startNodeManager.sh
Node Manager starts on CRMHOST2
.
Prerequisites include the following:
You must configure the location for all persistence stores to a directory visible from both nodes. Change all persistent stores to use this shared base directory.
Log in to the Administration Console (http://biinternal.mycompany.com:7777/console
).
In the Domain Structure window, expand the Services node and then click the Persistent Stores node. The Summary of Persistent Stores page is displayed.
In the Change Center, click Lock & Edit.
Click BipJmsStore and enter a directory that is located in the shared storage. This shared storage is accessible from both CRMHOST1
and CRMHOST2
:
ORACLE_BASE
/config/domains/CRMHOST1
/BIDomain/BipJmsStore
Click Save and then click Activate Changes.
The changes will not take effect until the Managed Server is restarted.
Do the following:
Ensure that Node Manager is up and running.
On the Summary of Servers page, select the Control tab.
Select bi_server1 in the table and then click Shutdown.
After the server has shut down, select bi_server1 in the table and then click Start.
Run the following commands to restart the Oracle Business Intelligence system components:
$ cd /u02/local/oracle/config/BIInstance/bin $ ./opmnctl stopall $ ./opmnctl startall
Make sure that you have performed the steps described in Section 15.1, "Enabling Virtual IPs on CRMHOST1 and CRMHOST2" before setting the bi_server1
listen address.
To set the listen address for the Managed Server:
Log in to the Administration Console (http://biinternal.mycompany.com:7777/console
).
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select bi_server1 in the table. The Settings page for bi_server1
is displayed.
Set the Listen Address to BIVH1
.
Click Save.
Click Activate Changes.
The changes will not take effect until the bi_server1
Managed Server is restarted (ensure that Node Manager is up and running):
On the Summary of Servers page, select the Control tab.
Select bi_server1 in the table and then click Shutdown.
After the server has shut down, select bi_server1 in the table and then click Start.
Restart the Oracle Business Intelligence system components, as follows:
$ cd /u02/local/oracle/config/BIInstance/bin $ ./opmnctl stopall $ ./opmnctl startll
To enable Oracle HTTP Server to route to bi_cluster
, which contains the bi_server
n
Managed Servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster:
On WEBHOST1
and WEBHOST2
, update the WebLogicCluster parameter in the ORACLE_BASE
/config/CommonDomain_webtier
n
/config/OHS/ohs1/moduleconf/FusionVirtualHost_bi.conf
file to contain a cluster list of virtual host:port entries.
Note: You must update the
|
For example, for the internal virtual host:
<LocationMatch ^/analytics/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 </LocationMatch>
For the external virtual host:
<LocationMatch ^/analytics/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 WLProxySSL ON WLProxySSLPassThrough ON RewriteEngine ON RewriteOptions inherit </LocationMatch>
On WEBHOST1
and WEBOST2
, add the following context roots to the ORACLE_BASE
/config/CommonDomain_webtier
n
/config/OHS/ohs1/moduleconf/FusionVirtualHost_bi.conf
file:
Example 14-1 # Internal Virtual Host Section
RedirectMatch 301 ^/biofficeclient$ /biofficeclient/ RedirectMatch 301 ^/bimiddleware$ /bimiddleware/ RedirectMatch 301 ^/rtis$ /rtis/ RedirectMatch 301 ^/bisearch$ /bisearch/ <LocationMatch ^/biofficeclient/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 </LocationMatch> <LocationMatch ^/bimiddleware/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 </LocationMatch> <LocationMatch ^/rtis/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 </LocationMatch> <LocationMatch ^/bisearch/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 </LocationMatch>
Example 14-2 # External Virtual Host Section
RedirectMatch 301 ^/biofficeclient$ /biofficeclient/ RedirectMatch 301 ^/bimiddleware$ /bimiddleware/ RedirectMatch 301 ^/rtis$ /rtis/ RedirectMatch 301 ^/bisearch$ /bisearch/ <LocationMatch ^/biofficeclient/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 WLProxySSL ON WLProxySSLPassThrough ON RewriteEngine ON RewriteOptions inherit </LocationMatch> <LocationMatch ^/bimiddleware/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 WLProxySSL ON WLProxySSLPassThrough ON RewriteEngine ON RewriteOptions inherit </LocationMatch> <LocationMatch ^/rtis/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 WLProxySSL ON WLProxySSLPassThrough ON RewriteEngine ON RewriteOptions inherit </LocationMatch> <LocationMatch ^/bisearch/> SetHandler weblogic-handler WebLogicClusterBIVH1
:10217,BIVH2
:10217 WLProxySSL ON WLProxySSLPassThrough ON RewriteEngine ON RewriteOptions inherit </LocationMatch>
Restart Oracle HTTP Server on both WEBHOST1
and WEBHOST2
, as follows:
WEBHOST1
>ORACLE_BASE
/config/CommonDomain_webtier/bin/opmnctl restartproc ias-component=ohs1WEBHOST2
>ORACLE_BASE
/config/CommonDomain_webtier1/bin/opmnctl restartproc ias-component=ohs1
The servers specified in the WebLogicCluster parameters are only important at startup time for the plug-in. The list must provide at least one running cluster member for the plug-in to discover other members in the cluster. The listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.
Sample scenarios include:
Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered dynamically at run time.
Example 2: You have a three-node cluster, but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.
If you list all the members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started. For more information on configuring the WebLogic Server plug-in, see Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server.
This section describes how to scale out the Oracle Business Intelligence system using the Configuration Assistant. It is assumed that an Oracle Business Intelligence ORACLE_BASE (binaries) has already been installed and is available from CRMHOST1
and CRMHOST2
, and that a domain with an Administration Server has been created. This is the domain that will be extended in this chapter to support Oracle Business Intelligence components.
Important: Oracle strongly recommends that you read the Oracle Fusion Middleware release notes for any additional installation and deployment considerations before starting the setup process. |
This section includes the following topics:
Section 14.5.1, "Scaling Out the Oracle Business Intelligence System on CRMHOST2"
Section 14.5.4, "Configuring Secondary Instances of Singleton System Components"
Section 14.5.7, "Configuring a Default Persistence Store for Transaction Recovery"
Section 14.5.8, "Starting and Validating Oracle Business Intelligence on CRMHOST2"
Section 14.5.9, "Validating Access Through Oracle HTTP Server"
Section 14.5.10, "Configuring Node Manager for the Managed Servers"
Section 14.5.11, "Configuring Server Migration for the Managed Servers"
To scale out the Oracle Business Intelligence system:
Ensure that the bi_server1
server is running.
In the ORACLE_BASE
/products/fusionapps/registry.xml
file, change
<component name="WebLogic Server" version="10.3.6.0"
InstallDir="ORACLE_BASE
/products/fusionapps/wlserver_10.3">
to
<component name="WebLogic Server" version="Temporary"
InstallDir="ORACLE_BASE
/products/fusionapps/wlserver_10.3">
Change directory to the location of the Configuration Assistant:
CRMHOST2
>ORACLE_BASE
/products/fusionapps/bi/bin
Start the Oracle Business Intelligence Configuration Assistant:
CRMHOST2
> ./config.sh
In the Welcome screen, click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully, and then click Next.
In the Create or Scale out BI System screen, select Scale Out BI System and enter the following:
Host Name: CRMHOST1
Port: 10201
User name: WLS_Administrator
User Password: WLS_Administrator_password
Click Next.
In the Scale Out BI System Details screen, enter the following:
Middleware Home: ORACLE_BASE
/products/fusionapps
(dimmed)
Oracle Home: ORACLE_BASE
/products/fusionapps/bi
(dimmed)
WebLogic Server Home: ORACLE_BASE
/products/fusionapps/wlserver_10.3
(dimmed)
Domain Home: /u02/local/oracle/config/domains/
CRMHOST1
/BIDomain
Applications Home: /u02/local/oracle/config/applications/
CRMHOST1
/BIDomain
Instance Home: Defaults to /u02/local/oracle/config/BIInstance1
Instance Name: BIInstance1
(dimmed)
Click Next.
In the Configure Ports screen, select "Specify Ports using Configuration File."
Use the bi_staticports.ini
file from the ORACLE_BASE
/products/ports
directory.
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle support and if you do, enter your e-mail address.
Click Next.
In the Summary screen, click Configure.
In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.
In the Complete screen, click Finish.
To start Node Manager in SSL mode:
Stop the default Node Manager running on CRMHOST2
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 Oracle Fusion Customer Relationship Managementand the Oracle Fusion Applications enterprise deployment.
Start Node Manager in SSL mode on CRMHOST2
:
CRMHOST2
> cdORACLE_BASE
/products/fusionapps/wlserver_10.3/common/nodemanager/CRMHOST2
CRMHOST2
> ./startNodeManagerWrapper.sh
Update the Node Manager for the CRMHOST2
machine using the Oracle WebLogic Server Console by doing the following:
Log in to the Administration Server: http://biinternal.mycompany.com:7777/console
.
Navigate to BIDomain> Environment > Machines.
In the left-hand pane, click Lock & Edit.
In the right-hand pane, click CRMHOST2
.
In the window that opens, click the Node Manager tab and set the following attributes:
– Type - SSL
– Listen Address - <CRMHOST2
>
– Listen Port - 5556
Click Save and then Activate Changes.
The changes will not take effect until the bi_server2
Managed Server is restarted.
Do the following to 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:
Log in to Fusion Middleware Control (http://biinternal.mycompany.com:7777/em
).
Expand the Business Intelligence node in the Farm_BIDomain window.
Click coreapplication.
Click Capacity Management, then click Scalability.
Click Lock and Edit Configuration.
For the CRMHOST2
BIInstance1 Oracle instance, increment the Oracle Business Intelligence components by 1:
BI Servers
Presentation Servers
JavaHosts
Change the Port Range From and Port Range To to be the same as the CRMHOST1
BIInstance Oracle instance.
Port Range To on both instances must be increased from 10214 to 10215.
Click Apply.
Click Activate Changes.
You do not need to restart at this point, because you will perform a restart after completing the steps in Section 14.5.4, "Configuring Secondary Instances of Singleton System 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 fo r high availability.
To configure secondary instances, do the following in Fusion Middleware Control:
Log in to Fusion Middleware Control (http://biinternal.mycompany.com:7777/em
).
Expand the Business Intelligence node in the Farm_BIDomain window.
Click coreapplication.
Click Availability, then click Failover.
Click Lock and Edit Configuration to activate the Primary/Secondary Configuration section of the Availability tab.
Specify the Secondary Host/Instance for BI Scheduler and BI Cluster Controller.
Click Apply.
Under Potential Single Points of Failure, no problem should be reported for BI Scheduler and BI Cluster Controller.
Click Activate Changes.
Click Restart to apply recent changes.
From Manage System, click Restart.
Click Yes when prompted to confirm that you want to restart all Business Intelligence components.
This section explains how to configure the bi_server2
Managed Server, and contains the following topics:
Section 14.5.5.1, "Setting the Listen Address for the bi_server2 Managed Server"
Section 14.5.5.2, "Configuring Custom Identity and Custom Trust for the bi_server2 Managed Server"
Section 14.5.5.3, "Disabling Host Name Verification for the bi_server2 Managed Server"
Section 14.5.5.4, "Adding bi_server2 System Properties to the Server Start Tab"
Make sure that you have performed the steps described in Section 15.1, "Enabling Virtual IPs on CRMHOST1 and CRMHOST2" before setting the bi_server2
listen address.
To set the listen address for the Managed Server:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
).
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select bi_server2 in the table. The settings page for bi_server2
is displayed.
Set the Listen Address to BIVH2
.
Click Save.
Click Activate Changes.
The changes will not take effect until the Managed Server is restarted.
Do the following:
Ensure that Node Manager is up and running.
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 configure custom identity and custom trust:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
).
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page displays.
Select bi_server2 in the table. The Settings page for bi_server2
displays.
Click Keystores, and then do the following:
Click Change next to Demo Identity and Demo Trust.
Select Custom Identity and Custom Trust from the Keystores dropdown list and click Save.
Under Identity, do the following:
– Change the Custom Identity Keystore entry to point to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/
CRMHOST2
_fusion_identity.jks
file.
– Enter and confirm the Custom Identity Keystore Passphrase. 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 CRMHOST2."
Under Trust, do the following:
– Change the Custom Identity Keystore entry to point to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks
file.
– Enter and confirm the Custom Trust Keystore Passphrase. 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 CRMHOST2."
– Click Save.
Click SSL, and then do the following:
Ensure that Identity and Trust Locations is set to Keystores.
Under Identity, do the following:
– Change the Private Key Alias to CRMHOST2
_fusion
.
– Enter and confirm 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 CRMHOST2."
– Click Save.
Click Activate Changes.
Set the following property in ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/bin/wlst.sh
:
WLST_PROPERTIES=" -Dweblogic.wlstHome='${WLST_HOME}'
-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE
/
products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks ${WLST_
PROPERTIES}"
This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 7, "Setting Up Node Manager for an Enterprise Deployment"). 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 as described in Chapter 7, "Setting Up Node Manager for an Enterprise Deployment."
To disable host name verification:
Log in to Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
).
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select bi_server2 in the table. The settings page for the server is displayed.
Click the SSL tab.
Expand the Advanced section of the page.
Set Host Name Verification to None.
Click Save.
Click Activate Changes.
The change will not take effect until the bi_server2
Managed Server is restarted (make sure that Node Manager is up and running):
In the Summary of Servers screen, select the Control tab.
Select bi_server2 in the table and then click Shutdown.
Restart bi_server2.
Restart the Oracle Business Intelligence system components:
$ cd /u02/local/oracle/config/BIInstance1/bin $ ./opmnctl stopall $ ./opmnctl startall
After scaling out the bi_server2
Managed Server, you must add a new system property to the Server Start tab of this Managed Server.
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
.
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page displays.
Select bi_server2 in the table.
The settings page for the server displays.
Click Server Start.
Add the following propery to the arguments:
-DJDBCProgramName=DS/BIDomain/bi_server2
Click Save and then Activate Changes.
Restart the bi_server2
Managed Server (ensure sure that Node Manager is up and running):
In the Summary of Servers screen, select the Control tab.
Select bi_server2 in the table and then click Shutdown.
Restart bi_server2
.
Restart the BI System Components:
$ cd /u02/local/oracle/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. It includes the following topics:
Section 14.5.6.1, "Additional Configuration Tasks for Oracle BI Scheduler"
Section 14.5.6.2, "Additional Configuration Tasks for Oracle Real-Time Decisions"
Section 14.5.6.3, "Additional Configuration Tasks for Oracle BI Publisher"
Section 14.5.6.4, "Additional Configuration Tasks for Oracle BI for Microsoft Office"
Section 14.5.6.5, "Additional Configuration Tasks for Oracle Financial Reporting"
If you use server-side scripts with Oracle BI Scheduler, it is recommended that you 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 you are using server-side scripts.
To share Oracle BI Scheduler scripts:
Create an ORACLE_BASE
/config/BIShared/OracleBISchedulerComponent/coreapplication_obisch1
directory.
From CRMHOST1
,copy the default Oracle BI Scheduler scripts (for example, /u02/local/oracle/config/BIInstance/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common
) and custom Oracle BI Scheduler scripts (for example, /u02/local/oracle/config/BIInstance/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler
) to the following location:
ORACLE_BASE
/config/BIShared/OracleBISchedulerComponent/coreapplication_obisch1
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 CRMHOST1: /u02/local/oracle/config/BIInstance/config/OracleBISchedulerComponent/coreapplication_obisch1
On CRMHOST2: /u02/local/oracle/config/BIInstance1/config/OracleBISchedulerComponent/coreapplication_obisch1
You must update these files for each Oracle BI Scheduler component in the deployment.
Restart the Oracle BI Scheduler component.
On CRMHOST1:
$ cd /u02/local/oracle/config/BIInstance/bin $ ./opmnctl stopproc ias-component=coreapplication_obisch1 $ ./opmnctl startproc ias-component=coreapplication_obisch1
On CRMHOST2:
$ cd /u02/local/oracle/config/BIInstance1/bin $ ./opmnctl stopproc ias-component=coreapplication_obisch1 $ ./opmnctl startproc ias-component=coreapplication_obisch1
This sections contains the following topics:
Section 14.5.6.2.1, "Configuring Oracle Real-Time Decisions Clustering Properties"
Section 14.5.6.2.2, "Adding Oracle RTD System Properties to the Server Start Tab"
Perform these steps in Fusion Middleware Control to set up cluster-specific configuration properties for Oracle RTD. You only need to perform the steps on one of the nodes in your deployment. You do not need to set cluster-specific configuration properties for Oracle RTD for subsequent nodes.
Log in to Fusion Middleware Control (http://biinternal.mycompany.com:7777/em
).
Expand the Application Deployments node in the Farm_BIDomain window.
Expand OracleRTD(11.1.1)(bi_cluster).
Click any node under it. For example, OracleRTD(11.1.1)(bi_server1).
In the right pane, click Application Deployment, and then select System MBean Browser.
In the System MBean Browser pane, expand Application Defined MBeans.
For any one of the servers under OracleRTD, navigate to the MBean and set the attribute, as shown in Table 14-1. Other servers automatically get updated with the value you set.
Click Apply.
After scaling out Oracle RTD, use the Administration Console to add three system properties to the Server Start tab of each Managed Server.
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
.
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page displays.
Select bi_server<1,2> in the table.
The settings page for the server displays.
Click Server Start.
Add the following propery to the arguments:
-Drtd.clusterRegistryJobIntervalMs=12000 -Drtd.clusterDepartureThresholdMs=50000 -Drtd.clusterDepartureThreshold2Ms=50000
Click Save and then Activate Changes.
Restart the bi_server<1,2>
Managed Server (ensure sure that Node Manager is up and running):
In the Summary of Servers screen, select the Control tab.
Select bi_server<1,2> in the table and then click Shutdown.
Restart bi_server<1,2>
.
Restart the BI System Components:
$ cd /u02/local/oracle/config/BIInstance1/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 will be 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:
In Fusion Middleware Control, expand the WebLogic Domain node in the left pane. Then, right-click bifoundation_domain and select System MBean Browser.
Locate SDPropertyManager > Misc MBean under Application Defined MBeans > OracleRTD > Server:bi_servern.
Be sure to select the Misc MBean that corresponds to the local node where you are making the change. For example, if you are connecting to APPHOST1
, then make sure to update the attribute associated with bi_server1
.
Set the BatchManagerEnabled attribute to false and click Apply.
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 will be running on either the same server as before, or on a different server.
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:
Locate the zip file for the Oracle RTD client tools in the following location:
ORACLE_BASE
/products/fusionapps/bi/clients/rtd/rtd_client_11.1.1.zip
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
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
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.
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 preceeding example.
Perform the steps in this section on each machine where Oracle BI Publisher is configured.
This section includes the following topics:
To configure Oracle BI Publisher integration with Oracle BI Presentation Services:
Log in to Oracle BI Publisher (http://biinternal.mycompany.com:7777/xmlpserver
) with Administrator credentials and select the Administration tab.
Under Integration, select Oracle BI Presentation Services.
Verify and update the following:
Server Protocol: http
Server: biinternal.mycompany.com
Port: 7777
URL Suffix: analytics-ws/saw.dll
Click Apply.
Restart your Oracle BI Publisher application:
Log in to the Administration Console (http://biinternal.mycompany.com:7777/console
).
Click Deployments in the Domain Structure window.
Select bipublisher(11.1.1).
Click Stop, and then select When Work Completes or Force Stop Now.
After the application has stopped, click Start and then Start Servicing All requests.
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:
Log in to Oracle BI Publisher (http://biinternal.mycompany.com:7777/xmlpserver
) with Administrator credentials and select the Administration tab.
Under Data Sources, select JDBC Connection.
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://CRMHOST1
:10212/PrimaryCCS=CRMHOST1
;PrimaryCCSPort=10212; SecondaryCCS=CRMHOST2
;SecondaryCCSPort=10212;
Note: Since the Cluster Controller Port may be different between
|
Do one of the following:
Select Use System User.
Deselect Use System User and specify BIImpersonateUser credentials.
For more information, see "Credentials for Connecting to the Oracle BI Presentation Catalog" in Oracle Fusion Middleware Developer's Guide for Oracle Business Intelligence Enterprise Edition.
Click Test Connection. You should receive a "Connection established successfully" message.
Click Apply.
You must configure the location for all persistence stores to a directory visible from both nodes. Change all persistent stores to use this shared base directory.
On CRMHOST2:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
).
In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page is displayed.
Click Lock & Edit.
Click New, and then Create File Store.
Enter a name (for example, BipJmsStore2
) and target (for example, bi_server2
). Enter a directory that is located in shared storage so that it is accessible from both CRMHOST1
and CRMHOST2
:
ORACLE_BASE
/config/domains/
CRMHOST1
/BIDomain/BipJmsStore
Click OK and then Activate Changes.
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.
Click Lock & Edit.
Click New.
Enter a name (for example, BipJmsServer2
) and in the Persistence Store drop-down list, select BipJmsStore2 and click Next.
Select bi_server2 as the target.
Click Finish and Activate Changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Modules node. The JMS Modules page is displayed.
In the Change Center, click Lock & Edit.
Click BIPJmsResource and then click the Subdeployments tab.
Select BipJmsSubDeployment under Subdeployments.
Add the new Oracle BI Publisher JMS Server (BipJmsServer2) as an additional target for the subdeployment.
Click Save and then Activate Changes.
To validate, do the following:
Log in to each Oracle BI Publisher URL.
Navigate to System Maintenance > Administration > Scheduler Diagonistics.
All statuses should be in a Passed state and both instances should be visible.
This section includes the following topics:
Section 14.5.6.4.1, "Configuring Oracle BI for Microsoft Office Properties"
Section 14.5.6.4.2, "Validating Oracle BI for Microsoft Office"
To perform additional configuration tasks for Oracle BI for Microsoft Office:
Validate the Oracle BI Enterprise Edition Office Server setup by accessing http://biinternal.mycompany.com:7777/bioffice/about.jsp
.
The About Oracle BI EE Office Server page is displayed, as shown in Figure 14-1.
Go to the Oracle BI Enterprise Edition Office Server directory. For example:
/u02/local/config/domains/
CRMHOST1
/BIDomain/servers/bi_server1/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INF
If you are not sure how 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.
Note: You can determine the exact location for CRMHOSTn by using the following URL: |
On both CRMHOST1
and CRMHOST2
, open bioffice.xml for editing and modify the BI Office properties shown in Table 14-2.
Table 14-2 BI Office Properties in bioffice.xml
Property Name | Valid Value | Description |
---|---|---|
SawBaseURL |
http://biinternal.mycompany.com:7777/analytics/saw.dll or http://biinternal.mycompany.com:7777/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 that you 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 |
SawWebURLforSSO |
http://biinternal.mycompany.com:7777/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. |
Restart the BI Office application:
Log in to the Administration Console (http://biinternal.mycompany.com:7777/console
).
Click Deployments in the Domain Structure window.
Select bioffice(11.1.1).
Click Stop.
After the application has stopped, click Start.
Validate that the SawBaseURL parameter has been updated on the About Oracle BI EE Office Server page.
To validate configuration for Oracle BI for Microsoft Office:
Log in to Oracle BI Presentation Services at:
http://biinternal.mycompany.com:7777/analytics
In the lower left pane, under the Get Started heading, select Download BI Desktop Tools and then select Oracle BI for MS Office.
Install Oracle BI for Microsoft by running the Oracle BI Office InstallShield Wizard.
Open Microsoft Excel or Microsoft PowerPoint.
From the Oracle BI menu, select Preferences.
In the Connections tab, select New.
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 that you defined for the Oracle BI Office Server when you deployed the Oracle BI Office Server application to WLS. The default name is bioffice.
Port: Enter the Oracle BI Office Server port number.
Figure 14-2 shows the New Connection dialog.
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 Figure 14-3.
Log in as an Administrator (for example, weblogic
) and validate that you can access the Oracle BI Task Pane, as shown in Figure 14-4.
There are additional configuration tasks to perform for Oracle Financial Reporting. Do the following on CRMHOST1
and CRMHOST2
:
Update the VARIABLE_VALUE_LIMIT
from 30720 to 3072000 in the NQSConfig.INI
file. For example,
VARIABLE_VALUE_LIMIT = 3072000;
On CRMHOST1
, this file is located in /u02/local/oracle/config/BIInstance/config/OracleBIServerComponent/coreapplication_obis1
.
On CRMHOST2
, this file is located in /u02/local/oracle/config/BIInstance1/config/OracleBIServerComponent/coreapplication_obis1
.
Run the following commands to restart the Oracle Business Intelligence system components:
$ cd /u02/local/oracle/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 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.
Note: 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:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
).
In the Change Center, click Lock & Edit.
In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page is displayed.
Click bi_server1 in the table. The Settings page for the selected server is displayed, and defaults to the Configuration tab.
Navigate to Configuration > Services.
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:
CRMHOST1
>ORACLE_BASE
/config/domains/CRMHOST1
/BIDomain/tlogs
Click Save.
Click Activate Changes.
Start the Managed Servers to activate the changes (ensure that Node Manager is up and running):
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
).
In the Summary of Servers screen, select the Control tab.
Select bi_server1 and bi_server2 in the table and then click Shutdown.
Start the bi_server1
and bi_server2
servers.
Restart the Oracle Business Intelligence system components:
$ cd /u02/local/oracle/config/BIInstancen
/bin
$ ./opmnctl stopall
$ ./opmnctl startall
Note: 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 |
This section includes the following topics:
Section 14.5.8.2, "Starting the Oracle Business Intelligence System Components"
Section 14.5.8.3, "Validating Oracle Business Intelligence URLs"
To start the bi_server2
Managed Server:
Start the bi_server2
Managed Server using the Oracle WebLogic Server Administration Console, as follows:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com:7777/console
).
Expand the Environment node in the Domain Structure window.
Select Servers. The Summary of Servers page is displayed.
Click the Control tab.
Select bi_server2 and then click Start.
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.
You can control Oracle Business Intelligence system components using opmnctl
commands.
To start the Oracle Business Intelligence system components using the opmnctl
command-line tool:
Go to the directory that contains the Oracle Process Manager and Notification Server command-line tool, located in /u02/local/oracle/config/BIInstance1/bin
.
Run the opmnctl
command to start the Oracle Business Intelligence system components:
./opmnctl startall
: Starts Oracle Process Manager and Notification Server and all Oracle Business Intelligence system components
./opmnctl start
: Starts Oracle Process Manager and Notification Server only
./opmnctl startproc ias-component=
component_name
: Starts a particular system component. For example, where coreapplication_obips1
is the Presentation Services component:
./opmnctl startproc ias-component=coreapplication_obips1
Check the status of the Oracle Business Intelligence system components:
./opmnctl status
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.
Note: 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.
You should 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:
While bi_server2
is running, stop bi_server1
using the Oracle WebLogic Server Administration Console.
Access the following URLs to verify that routing and failover is functioning properly:
http://WEBHOST1:10621/analytics
http://WEBHOST1:10621/xmlpserver
http://WEBHOST1:10621/ui
(access only available on Microsoft Internet Explorer 7 or 8)
http://WEBHOST1:10621/hr
http://WEBHOST1:10621/calcmgr/index.htm
http://WEBHOST1:10621/aps/Test
http://WEBHOST1:10621/workspace
Start bi_server1
from the Oracle WebLogic Server Administration Console.
Stop bi_server2
from the Oracle WebLogic Server Administration Console.
Access the following URLs to verify that routing and failover is functioning properly:
http://WEBHOST1:10621/analytics
http://WEBHOST1:10621/xmlpserver
http://WEBHOST1:10621/ui
(access only available on Microsoft Internet Explorer 7 or 8)
http://WEBHOST1:10621/hr
http://WEBHOST1:10621/calcmgr/index.htm
http://WEBHOST1:10621/aps/Test
http://WEBHOST1:10621/workspace
Start bi_server2
from the Oracle WebLogic ServerAdministration Console.
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. The procedures in that chapter must be performed twice using the information provided in Table 14-3.
Table 14-3 Details for Host Name Verification for Node Manager and Servers
Run | Host Name (Host) | Server Name (WLS_SERVER) |
---|---|---|
Run1: |
|
|
Run2: |
|
|
Note: If you configured Node Manager for the Managed Servers earlier, you do not need 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 CRMHOST1
and CRMHOST2
nodes. For more information, see Chapter 17, "Setting Up Server Migration for an Enterprise Deployment."
This section describes how to configure secondary instances of Oracle Essbase Agent so that they are distributed for high availability.
Prerequisite steps for configuring Oracle Essbase clustering:
On CRMHOST1
or CRMHOST2
, delete or rename the EssFOConfig.properties
file in the Essbase shared folder under ORACLE_BASE
/config/BIShared/Essbase/essbaseserver1
.
On CRMHOST1
, update the following properties in the /u02/local/oracle/config/BIInstance/bin/essbase_ha/EssFOConfig.properties
file:
SYSTEM_HOST=CRMHOST1
SYSTEM_HOST1=CRMHOST1
SYSTEM_HOST2=CRMHOST2
SYSTEM_CLUSTER_NAME=essbasecluster1 SYSTEM_CLUSTER_INST1=essbasecluster1-inst1 SYSTEM_CLUSTER_INST2=essbasecluster1-inst2 SYSTEM_CLUSTER_INSTANCE1=BIInstance SYSTEM_CLUSTER_INSTANCE2=BIInstance1 SYSTEM_AGENT_PORTNUMBER1=10215 SYSTEM_AGENT_PORTNUMBER2=10215
Perform the following steps in Fusion Middleware Control:
Log in to Fusion Middleware Control (http://biinternal.mycompany.com:7777/em
).
Expand the Business Intelligence node in the Farm_BIDomain window.
Click coreapplication.
Click Availability, then click Failover.
Click Lock and Edit Configuration to activate the Primary/Secondary Configuration section of the Availability tab.
Specify the Secondary Host/Instance for Oracle Essbase Agent.
Ensure the shared folder is located at ORACLE_BASE
/config/BIShared/Essbase/essbaseserver1
and click Apply.
Under Potential Single Points of Failure, no problems should be reported for Oracle Essbase Agent.
Click Activate Changes.
Under Manage System, click Restart.
Click Yes in the confirmation dialog.
Do the following to validate Essbase clustering:
Check the APS (Hyperion Provider Services) test URL:
http://biinternal.mycompany.com:7777/aps/Test
Run the following command on CRMHOST1
:
/u02/local/oracle/config/BIInstance/bin/opmnctl stopproc ias-component=essbasecluster1
Ensure that Essbase starts on CRMHOST2
:
/u02/local/oracle/config/BIInstance1/bin/opmnctl status
The status should be init
then Alive
.
Check the APS test URL again:
http://biinternal.mycompany.com:7777/aps/Test
You should 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:
While bi_server2
is running, stop bi_server1
using the Oracle WebLogic Server Administration Console.
Access the following URLs to verify that routing and failover is functioning properly:
http://WEBHOST1:10621/analytics
http://WEBHOST1:10621/xmlpserver
http://WEBHOST1:10621/ui
(access only available on Microsoft Internet Explorer 7 or 8)
http://WEBHOST1:10621/hr
http://WEBHOST1:10621/workspace
http://WEBHOST1:10621/calcmgr/index.htm
http://WEBHOST1:10621/aps/Test
Start bi_server1
from the Oracle WebLogic Server Administration Console.
Stop bi_server2
from the Oracle WebLogic Server Administration Console.
Access the following URLs to verify that routing and failover is functioni+ng properly:
http://WEBHOST1:10621/analytics
http://WEBHOST1:10621/xmlpserver
(access only available on Microsoft Internet Explorer 7 or 8)
http://WEBHOST1:10621/ui
http://WEBHOST1:10621/hr
http://WEBHOST1:10621/workspace
http://WEBHOST1:10621/calcmgr/index.htm
http://WEBHOST1:10621/aps/Test
Start bi_server1
from the Oracle WebLogic ServerAdministration Console.
This chapter describes how to scale out the Oracle Fusion Incentive Compensation domain.
This chapter includes the following topics:
Section 13.1, "Overview of the Oracle Fusion Incentive Compensation Domain"
Section 13.2, "Prerequisites for Scaling Out the Oracle Fusion Incentive Compensation Domain"
Section 13.3, "Adding a New Machine in the Oracle WebLogic Server Console"
Section 13.4, "Packing and Unpacking the Managed Server Domain Home"
Section 13.5, "Cloning Managed Servers and Assigning Them to CRMHOST2"
Section 13.7, "Configuring Server Migration for the Managed Servers"
The Oracle Fusion Incentive Compensation domain provides Oracle Fusion Customer Relationship Management with a comprehensive solution that integrates with Quota Management to ensure consistent and accurate incentive compensation plan goals and enables organizations to measure and pay for performance that aligns with organizational strategies. Embedded participant and manager dashboards support sales performance management by enable salespeople to easily track their performance achievements against objectives and allowing them to focus on customers instead of shadow accounting.
Figure 2-8 in Chapter 2, "Introduction to the Enterprise Deployment Reference Topologies," shows the topology for the Oracle Fusion Incentive Compensation domain within the overall reference enterprise deployment topology.
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 CRMHOST2
should be the same as the user on CRMHOST1
The directory structure /u01/oracle
is mounted to same shared file system as CRMHOST1
The directory structure /u02/local/oracle/config
on CRMHOST2
has been created
The initial Oracle Fusion Customer Relationship Management deployment on CRMHOST1
has already been done and verified by provisioning
To add a new machine:
Log in to the Administration Server: http://
icinternal
.mycompany.com:7777/console
.
Navigate to ICDomain > Environment > Machines.
LocalMachine is located in the right-hand pane.
In the left-hand pane, click Lock & Edit.
In the right-hand pane, first click New to add the remote machine, and then specify the following:
Name - enter CRMHOST2
Machine operating system - Unix
Click Next.
In the window that opens, set the following attributes:
Type - SSL
Listen Address - <CRMHOST2
>
Note: The "localhost" default value here is wrong. |
Listen port - 5556
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. |
Since the CRMHOST1
domain directory file system is also available from CRMHOST2
, both the pack
and unpack
commands can be executed from the CRMHOST2
.
To pack and unpack the Managed Server domain home:
Change directory to ORACLE_BASE
/products/fusionapps/oracle_common/common/bin
.
Run the pack
command:
CRMHOST2
> ./pack.sh -managed=true -domain=ORACLE_BASE
/config/domains/CRMHOST1
/ICDomain -template=ORACLE_BASE/
user_templates/ICDomain_managed.jar -template_name="IC_Managed_Server_Domain"
Ensure that /u02/local/oracle/config/domains/
CRMHOST2
/ICDomain
is empty, and then run the unpack
command:
CRMHOST2
> ./unpack.sh -domain=/u02/local/oracle/config/domains/CRMHOST2
/ICDomain -template=ORACLE_BASE
/user_templates/ICDomain_managed.jar
Here, ORACLE_BASE
is shared, and /u02/local
is local to CRMHOST2
.
To add a managed server and assign it to CRMHOST2
:
Log in to the Administration Server: http://
icinternal
.mycompany.com:7777/console
.
Navigate to ICDomain > Environment > Servers.
Switch to Lock & Edit mode.
Select the Managed_Server checkbox (for example, IncentiveCompensationServer_1) and then click Clone.
Specify the following Server Identity attributes:
Server Name - IncentiveCompensationServer_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 - <CRMHOST2
>
Server Listen Port - leave "as is"
Click OK.
You now should see the newly cloned server, IncentiveCompensationServer_2
.
Click IncentiveCompensationServer_2 and change the following attributes:
Machine - <CRMHOST2
>
Cluster Name - accept the default, IncentiveCompensationCluster
Note: Ensure that this cluster name is the same as the cluster name of the original managed server. |
Click Save and then Activate Changes.
Navigate to ICDomain > Environment > Servers.
From the Name column, click the IncentiveCompensationServer_2 scaled-out server link.
Click Lock & Edit, and then select the Configuration tab.
Select the Keystores tab, and ensure that the keystores value is Custom Identity and Custom Trust.
Do the following:
Change the Custom Identity Keystore path to point to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/
CRMHOST2
_fusion_identity.jks
file.
Leave the Custom Identity Keystore type blank.
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 CRMHOST2."
Re-enter the Confirm Custom Identity Keystore Passphrase.
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.
Leave the Custom Trust Keystore type blank.
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 CRMHOST2."
Re-enter the Custom Trust Keystore Passphrase.
Click Save.
Select the SSL tab.
Make sure that Identity and Trust Locations is set to Keystores.
Change the Private Key Alias to CRMHOST2
_fusion
.
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 CRMHOST2."
Re-enter the keypassword from Step c for the Confirm Private Key Passphrase.
Click Save.
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/ICDomain/IncentiveCompensationServer_2 -Dserver.group=Incentive CompensationCluster
Click Save.
Select the Logging tab, and then select the HTTP tab.
Do the following:
Change the Log file name to logs/access.log.%yyyyMMdd%
.
Change the rotation type to By Time.
Leave the Limit number of retained files option unchecked.
Leave the Rotate log file on startup option unchecked.
Click Save.
Expand Advanced.
Change the format to Extended.
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)
Click Save.
Click Activate Changes.
Repeat Steps 2 to 18 for all the managed servers on this domain.
Set the following environment variable on CRMHOST2
:
WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE
/
products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks"
Stop the domain's Administration Server:
CRMHOST1
>ORACLE_BASE
/config/domains/CRMHOST1
/ICDomain/bin/stopWebLogic.sh
Restart the domain's Administration Server:
CRMHOST2
>ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/bin/wlst.shCRMHOST2
> nmConnect(username='<username>', password='<password>', domainName='ICDomain', host='CRMHOST1
',port='5556', nmType='ssl', domainDir='ORACLE_BASE
/config/domains/CRMHOST1
/ICDomain')CRMHOST2
> nmStart('AdminServer')
Note: The username and password used in the |
Run the newly created managed servers:
Log in to the Administration Server: http://
icinternal
.mycompany.com:7777/console
.
Navigate to ICDomain > Environment > Servers > Control.
Select the newly created managed servers and click Start.
Navigate to ICDomain > Environment > Servers and check the State to verify that the newly created managed servers are running.
To configure Oracle HTTP Server:
On WEBHOST1
:
Change directory to ORACLE_BASE
/config/CommonDomain_webtier/config/OHS/ohs1/moduleconf
.
Copy FusionVirtualHost_ic.conf
to FusionVirtualHost_ic.conf.org
.
Edit the FusionVirtualHost_ic.conf
file, adding the scaled-out host and port to all the WebLogic Application Clusters. Example 13-1 shows sample code for IncentiveCompensationServer.
Notes:
|
Repeat Step 2 for all applications.
Restart Oracle HTTP Server: cd
to ORACLE_BASE
/config/CommonDomain_webtier/bin
and enter the following:
WEBHOST1
> ./opmnctl stopallWEBHOST1
> ./opmnctl startall
Server migration is required for proper failover of Oracle Fusion Customer Relationship Management components in the event of failure in any of the CRMHOST1 and CRMHOST2 nodes. For more information, see Chapter 17, "Setting Up Server Migration for an Enterprise Deployment."
You should verify URLs to ensure that the appropriate routing and failover are working.
To verify the URLs:
Log in to the ICDomain
Oracle WebLogic Server Administration Console and stop all the managed servers on the CRMHOST1
while the managed servers on CRMHOST2
are running.
Access the following URL to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
https://icexternal.mycompany.com/incentiveCompensation/faces/IcCnCompPlanWorkarea
Log in to the ICDomain
Oracle WebLogic Server Administration Console and stop all the managed servers on CRMHOST2
.
Start the managed servers on CRMHOST1
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the managed servers on CRMHOST2
and verify that they are running on CRMHOST1
and CRMHOST2
.
This chapter describes how to configure server migration according to enterprise deployment recommendations.
This chapter includes the following topic:
Before migrating Oracle Fusion Applications domains, ensure you have completed the steps in Section 15.1, "Enabling Virtual IPs on CRMHOST1 and CRMHOST2," Section 15.2, "Setting the Listen Address for soa_server1," and Section 15.3, "Setting the Listen Address for soa_server2" for all Managed Servers needing to be migrated.
Note: This prerequisite does not apply to the Oracle Business Intelligence domain. |
The procedures in this section apply to these domains and applications:
Oracle SOA Suite in the Oracle Fusion Customer Relationship Management domain
Oracle SOA Suite in the Oracle Fusion Financials domain
Oracle SOA Suite in the Oracle Fusion Common domain
Oracle SOA Suite in the Oracle Business Intelligence domain
Oracle SOA Suite in the Oracle Fusion Human Capital Management domain
Oracle SOA Suite in the Oracle Fusion Supply Chain Management domain
Oracle SOA Suite in the Oracle Incentive Compensation domain
The procedures described in this chapter must be performed for various components of the enterprise deployment topology outlined in Section 2.1, "Overview of Reference Enterprise Deployment Topologies." Variables are used in this chapter to distinguish between component-specific items:
WLS_SERVER1 and WLS_SERVER2 refer to the managed WebLogic servers for the enterprise deployment component
CRMHOST1 and CRMHOST2 refer to the host machines for the enterprise deployment component
CLUSTER refers to the cluster associated with the enterprise deployment component.
The values to be used to these variables are provided in the component-specific chapters in this guide.
In this enterprise topology, you must configure server migration for the WLS_SERVER1 and WLS_SERVER2 Managed Servers. The WLS_SERVER1 Managed Server is configured to restart on CRMHOST2 should a failure occur. The WLS_SERVER2 Managed Server is configured to restart on CRMHOST1 should a failure occur. For this configuration, the WLS_SERVER1 and WLS_SERVER2 servers listen on specific floating IP addresses that are failed over by WebLogic Server migration. Configuring server migration for the WLS Managed Servers consists of the following steps:
The first step is to set up a user and tablespace for the server migration leasing table.
Note: If other servers in the same domain have already been configured with server migration, the same tablespace and data sources can be used. In that case, the data sources and multi-data source for database leasing do not need to be re-created, but they will have to be retargeted to the cluster being configured with server migration. |
To set up a user and tablespace:
Create a tablespace called 'leasing'. For example, log on to SQL*Plus as the sysdba user and run the following command:
SQL> create tablespace leasing logging datafile
'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;
Create a user named 'leasing' and assign to it the leasing tablespace:
SQL> create user leasing identified by welcome1; SQL> grant create table to leasing; SQL> grant create session to leasing; SQL> alter user leasing default tablespace leasing; SQL> alter user leasing quota unlimited on LEASING;
Create the leasing table using the leasing.ddl script:
Copy the leasing.ddl file located in either the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/db/oracle/817
or the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/db/oracle/920
directory to your database node.
Connect to the database as the leasing user.
Run the leasing.ddl script in SQL*Plus:
SQL> @Copy_Location/leasing.ddl;
The second step is to create a multi-data source for the leasing table from the Oracle WebLogic Server Administration Console. You create a data source to each of the Oracle RAC database instances during the process of setting up the multi-data source, both for these data sources and the global leasing multi-data source.
Please note the following considerations when creating a data source:
Make sure that this is a non-XA data source.
The names of the multi-data sources are in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.
Use Supports Global Transactions, One-Phase Commit, and specify a service name for your database.
Target these data sources to the cluster assigned to the enterprise deployment component (CLUSTER; see the component-specific chapters in this guide).
Creating a Multi-Data Source
To create a multi-data source:
In the Domain Structure window in the Oracle WebLogic Server Administration Console, click the Data Sources link.
Click Lock & Edit.
Select Multi Data Source from the New dropdown menu.
The Create a New JDBC Multi Data Source page is displayed.
Enter leasing
as the name.
Enter jdbc/leasing
as the JNDI name.
Select Failover as algorithm (default).
Click Next.
Select the cluster assigned to the enterprise deployment component as the target.
Click Next.
Select non-XA driver (the default).
Click Next.
Click Create a New Data Source.
Enter leasing-rac0
as the name. Enter jdbc/leasing-rac0
as the JNDI name. Enter oracle
as the database type. For the driver type, select Oracle Driver (Thin) for Oracle RAC Service-Instance connections, Versions 10 and later.
Note: When creating the multi-data sources for the leasing table, enter names in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on. |
Click Next.
Deselect Supports Global Transactions.
Click Next.
Enter the following for your leasing schema:
Service Name: The service name of the database.
Database Name: The Instance Name for the first instance of the Oracle RAC database.
Host Name: The name of the node that is running the database. For the Oracle RAC database, specify the first instance's VIP name or the node name as the host name.
Port: The port number for the database (1521).
Database User Name: Enter leasing
.
Password: The leasing password.
Click Next.
Click Test Configuration and verify that the connection works.
Click Next.
Target the data source to the cluster assigned to the enterprise deployment component (CLUSTER).
Click Finish.
Click Create a New Data Source for the second instance of your Oracle RAC database, target it to the cluster assigned to the enterprise deployment component (CLUSTER), repeating the steps for the second instance of your Oracle RAC database.
Add leasing -rac0
and leasing -rac1
to your multi-data source.
Make sure the initial connection pool capacity of the data sources is set to 0 (zero). In the Datasources screen do the following:
Select Services, then select Datasources.
Click Datasource Name, then click the Connection Pool tab.
Enter 0
(zero) in the Initial Capacity field.
Click Save, then click Activate Changes.
The third step is to edit Node Manager's properties file, which is located at:
ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/nodemanager/CRMHOST1
ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/nodemanager/CRMHOST2
This needs to be done for the node managers in both nodes where server migration is being configured. For example:
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface: This property specifies the interface name for the floating IP (for example, eth0
).
Do not specify the sub-interface, such as eth0:1
or eth0:2
. This interface is to be used without :0
or :1
. Node Manager's scripts traverse the different :X-enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0
, eth1
, eth2
, eth3
, eth
n
, depending on the number of interfaces configured.
NetMask: This property specifies the net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface; 255.255.255.0 is used as an example in this document.
UseMACBroadcast: This property specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not to use the -b
flag in the arping
command.
Verify in Node Manager's output (shell where Node Manager is started) that these properties are being used, or problems may arise during migration. You should see something like this in Node Manager's output:
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
Note: The steps below are not required if the server properties (start properties) have been properly set and Node Manager can start the servers remotely. |
Set the following property in the nodemanager.properties
file:
StartScriptEnabled: Set this property to 'true'. This is required for Node Manager to start the Managed Servers using start scripts.
Restart Node Manager on CRMHOST1 and CRMHOST2 by running the startNodeManagerWrapper.sh
script, which is located in the ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/nodemanager/
CRMHOST1
and ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/nodemanager/
CRMHOST2
directories.
The fourth step is to set environment and superuser privileges for the wlsifconfig.sh
script:
Ensure that your PATH is set with the environment variables in the terminal from where Node Manager is started, and that it includes these files:
Table 17-1 Files Required for the PATH Environment Variable
File | Located in this directory |
---|---|
wlsifconfig.sh |
|
wlscontrol.sh |
|
nodemanager.domains |
|
Grant sudo configuration for the wlsifconfig.sh script.
Configure sudo
to work without a password prompt.
For security reasons, sudo should be restricted to the subset of commands required to run the wlsifconfig.sh
script. For example, perform these steps to set the environment and superuser privileges for the wlsifconfig.sh
script:
Grant sudo
privilege to the WebLogic user ('oracle') with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.
Make sure the script is executable by the WebLogic user ('oracle'). The following is an example of an entry inside /etc/sudoers
granting sudo execution privilege for oracle
and also over ifconfig
and arping
:
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
Note: Ask the system administrator for the |
The fifth step is to configure server migration targets. You first assign all the available nodes for the cluster's members and then specify candidate machines (in order of preference) for each server that is configured with server migration. Follow these steps to configure cluster migration in a migration in a cluster:
Log in to the Oracle WebLogic Server Administration Console. For example, http://crminternal.mycompany.com:7777/console
In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page is displayed.
Click the cluster for which you want to configure migration (CLUSTER) in the Name column of the table.
Click the Migration tab.
Click Lock & Edit.
In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select CRMHOST1 and CRMHOST2.
Note: When there are three (3) hosts, for example |
Select the data source to be used for automatic migration. In this case, select the leasing data source.
Click Save.
Click Activate Changes.
Set the candidate machines for server migration. You must perform this task for all of the Managed Servers as follows:
In the Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.
Tip: Click Customize this table in the Summary of Servers page and move Current Machine from the Available window to the Chosen window to view the machine on which the server is running. This will be different from the configuration if the server gets migrated automatically. |
Select the server for which you want to configure migration.
Click the Migration tab, and then click Lock & Edit.
In the Available field, located in the Migration Configuration section, select the machines to which to allow migration and click the right arrow. For WLS_SERVER1, select CRMHOST2. For WLS_SERVER2, select CRMHOST1.
Note: If there are three (3) hosts ( In the Configuration section, select the machines to which you want to allow migration and click the right arrow. For |
Select Automatic Server Migration Enabled. This enables Node Manager to start a failed server on the target node automatically.
Click Save.
Click Activate Changes.
Restart the administration server, node managers, and the servers for which server migration has been configured.
The sixth and final step is to test the server migration. Perform these steps to verify that server migration is working properly:
From CRMHOST1:
Stop the WLS_SERVER1 Managed Server. To do this, run this command:
CRMHOST1
> kill -9 pid
where pid specifies the process ID of the Managed Server. You can identify the pid in the node by running this command:
CRMHOST1
> ps -ef | grep WLS_SERVER1 | grepDomainName
_SOACluster
Watch the Node Manager console. You should see a message indicating that WLS_SERVER1's floating IP has been disabled.
Wait for Node Manager to try a second restart of WLS_SERVER1. It waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it few times. Node Manager should now log a message indicating that the server will not be restarted again locally.
From CRMHOST2:
Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_SERVER1 on CRMHOST1
>, Node Manager on CRMHOST2
> should prompt that the floating IP for WLS_SERVER1 is being brought up and that the server is being restarted in this node.
As an example, for Oracle SOA Suite Managed Servers, access the soa-infra console in the same IP.
Verification from the Administration Console
Migration can also be verified in the Administration Console:
Log in to the Administration Console.
Click Domain on the left console.
Click the Monitoring tab and then the Migration subtab.
The Migration Status table, shown in Figure 17-1, provides information on the status of the migration.
Note: To complete server migration in a cluster, perform the same steps on the second, third, and so on, managed servers. |
This chapter provides an overview of the enterprise topology for Oracle Fusion Customer Relationship Management.
This chapter includes the following topics:
An enterprise deployment is an Oracle guidelines blueprint based on proven Oracle high-availability and security technologies and recommendations for Oracle Fusion Applications. The guidelines described in these blueprints span all Oracle products across the entire technology stack: Oracle Database, Oracle Fusion Middleware, Oracle Fusion Applications, and Fusion Middleware Control.
An Oracle Fusion Applications enterprise deployment:
considers various business Service Level Agreements (SLA) to make high-availability guidelines as widely applicable as possible
leverages database grid servers and storage grid with low-cost storage to provide highly resilient, lower cost infrastructure
uses results from extensive performance impact studies for different configurations to ensure that the high-availability architecture is optimally configured to perform and scale to business needs
enables control over the length of time to recover from an outage and the amount of acceptable data loss from a natural disaster
uses Oracle guidelines and recommended architecture, which are independent of hardware and operating systems.
Note: This document focuses on enterprise deployments in Linux environments. Enterprise deployments can also be implemented in UNIX and Windows environments. |
Oracle Fusion Applications are a unified suite of business applications designed to unify personal and enterprise processes. It unifies transactional Oracle SOA Suite and business processes, business intelligence, and collaborative technologies in a seamless user experience. Oracle Fusion Applications can be easily integrated into a service-oriented architecture and made available as software as a service.
Oracle Fusion Applications offer a strong functional value by providing:
Installed based demand (for example, unified global payroll module)
Competitive differentiation (for example, Distributed Order Orchestration)
Revenue generation (for example, sales territory management)
Oracle Fusion Applications incorporate best practice business processes, including those from Oracle E-Business Suite, PeopleSoft, Oracle On Demand, JD Edwards, and Siebel.
Oracle Fusion Applications are standards-based, making them highly adaptable. This standards-based technology allows you to respond effectively to change with flexible, modular, user-driven business software that is powered by best-in-class business capabilities built on open standards. Its technology framework includes the following products:
Oracle WebCenter Portal provides design time and runtime tools for building enterprise portals, transactional websites, and social networking sites.
Oracle Business Intelligence 11g provides a full range of business intelligence capabilities that allow you to collect, present, and deliver organizational data.
Hyperion extends Oracle's business intelligence capabilities to offer the most comprehensive system for enterprise performance management.
Oracle WebCenter Content enables you to leverage document management, Web content management, digital asset management, and records retention functionality to build and complement your business applications.
Oracle SOA Suite provides an enterprise architecture that supports building connected enterprise applications to provide solutions to business problems.
Oracle WebLogic Server is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server.
Oracle JDeveloper is an integrated development environment with end-to-end support for modeling, developing, debugging, optimizing, and deploying Java applications and Web services.
Oracle Enterprise Manager Fusion Middleware Control offers business-driven applications management, integrated application to disk management, and integrated systems management and support experience.
Oracle Identity Management enables organizations to manage the end-to-end life cycle of user identities and to secure access to enterprise resources and assets.
For more information, see the Oracle Fusion Applications Concepts Guide.
The Oracle Fusion Applications configurations discussed in this guide are designed to ensure security of all invocations, maximize hardware resources, and provide a reliable, standards-compliant system for enterprise computing with a variety of applications.
The security and high-availability benefits of the Oracle Fusion Applications configurations are realized through isolation in firewall zones and replication of software components.
The enterprise deployment architectures are secure because every functional group of software components is isolated in its own demilitarized zone (DMZ), and all traffic is restricted by protocol and port. The following characteristics ensure security at all needed levels, as well as a high level of standards compliance:
Configure external load balancers to redirect all external communication received on port 80 to port 443.
Note: The Oracle Technology Network ( |
Communication from external clients does not go beyond the Load Balancing Router (LBR) level.
Components are separated in different protection zones: the Oracle Web Tier, application tier, and the data tier. Moreover, Oracle Identity Management (IDM) has its own protection zones like Oracle Web Tier, Applications tier and Data tier
No direct communication from the Load Balancing Router to the data tier is allowed.
Direct communication between two firewalls at any one time is prohibited.
If a communication begins in one firewall zone, it must end in the next firewall zone.
Oracle Internet Directory (OID) is isolated in the data tier.
All communication between components across protection zones is restricted by port and protocol, according to firewall rules.
The enterprise deployment architectures are highly available, because each component or functional group of software components is replicated on a different computer, and configured for component-level high availability.
The following terminology is used in this enterprise deployment guide:
Oracle home: An Oracle home contains installed files necessary to host a specific product. For example, the SOA Oracle home contains a directory that contains binary and library files for Oracle SOA Suite. An Oracle home resides within the directory structure of the Middleware home. Each Oracle home can be associated with multiple Oracle instances or Oracle WebLogic Server domains.
ORACLE_BASE: An alternate way of specifying the path /u01/oracle
. Stores binaries, configuration, and Oracle Inventory.
WebLogic Server home: A WebLogic Server home contains installed files necessary to host a WebLogic Server. The WebLogic Server home directory is a peer of Oracle home directories and resides within the directory structure of the Middleware home.
Middleware home: A Middleware home consists of the Oracle WebLogic Server home, and, optionally, one or more Oracle homes. A Middleware home can reside on a local file system or on a remote shared disk that is accessible through NFS.
Oracle instance: An Oracle instance contains one or more active middleware system components, for example Oracle Web Cache, Oracle HTTP Server or Oracle Internet Directory. You determine which components are part of an instance, either at install time or by creating and configuring an instance at a later time. An Oracle instance contains files that can be updated, such as configuration files, log files, temporary files.
Domain: The basic administrative unit of Oracle WebLogic Server.
Managed Server: Hosts business applications, application components, Web services, and their associated resources. To optimize performance, Managed Servers maintain a read-only copy of the domain's configuration document. When a Managed Server starts, it connects to the domain's Administration Server to synchronize its configuration document with the document that the Administration Server maintains.
failover: When a member of a high availability system fails unexpectedly (unplanned downtime), in order to continue offering services to its consumers, the system undergoes a failover operation. If the system is an active-passive system, the passive member is activated during the failover operation and consumers are directed to it instead of the failed member. The failover process can be performed manually, or it can be automated by setting up hardware cluster services to detect failures and move cluster resources from the failed node to the standby node. If the system is an active-active system, the failover is performed by the load balancer entity serving requests to the active members. If an active member fails, the load balancer detects the failure and automatically redirects requests for the failed member to the surviving active members. See Oracle Fusion Middleware High Availability Guide for information on active-active and active-passive systems.
failback: After a system undergoes a successful failover operation, the original failed member can be repaired over time and be re-introduced into the system as a standby member. If desired, a failback process can be initiated to activate this member and deactivate the other. This process reverts the system back to its pre-failure configuration.
hardware cluster: A hardware cluster is a collection of computers that provides a single view of network services (for example: an IP address) or application services (for example: databases, Web servers) to clients of these services. Each node in a hardware cluster is a standalone server that runs its own processes. These processes can communicate with one another to form what looks like a single system that cooperatively provides applications, system resources, and data to users.
A hardware cluster achieves high availability and scalability through the use of specialized hardware (cluster interconnect, shared storage) and software (health monitors, resource monitors). The cluster interconnect is a private link used by the hardware cluster for heartbeat information to detect node death. Due to the need for specialized hardware and software, hardware clusters are commonly provided by hardware vendors such as HP, IBM, and Dell. While the number of nodes that can be configured in a hardware cluster is vendor dependent, for the purpose of Oracle Fusion Applications high availability, only two nodes are required. Hence, this document assumes a two-node hardware cluster for high availability solutions employing a hardware cluster.
cluster agent: The software that runs on a node member of a hardware cluster that coordinates availability and performance operations with other nodes. Clusterware provides resource grouping, monitoring, and the ability to move services. A cluster agent can automate the service failover.
clusterware: Software that manages the operations of the members of a cluster as a system. It allows one to define a set of resources and services to monitor via a heartbeat mechanism between cluster members and to move these resources and services to a different member in the cluster as efficiently and transparently as possible.
shared storage: Shared storage is the storage subsystem that is accessible by all the computers in the enterprise deployment domain. Among other things, the following is located on the shared disk:
Middleware Home software
AdminServer Domain Home
Java Message Service (JMS)
Tlogs (where applicable)
Managed server homes can also be optionally located in the shared disk. The shared storage can be a Network Attached Storage (NAS), a Storage Area Network (SAN) or any other storage system that multiple nodes can access simultaneously and can read/write.
primary node: The node that is actively running an Oracle Fusion Applications instance at any given time and has been configured to have a backup/secondary node. If the primary node fails, Oracle Fusion Applications instance is failed over to the secondary node. This failover can be manual or automated using the Clusterware for Administration Server. For a server migration based scenario, WebLogic Whole Server Migration is used for automated failover.
secondary node: The node that is the backup node for an Oracle Fusion Applications instance. This is where the active instance fails over when the primary node is no longer available. See the definition for primary node in this section.
network host name: Network host name is a name assigned to an IP address either through the /etc/hosts
file or through DNS resolution. This name is visible in the network that the computer to which it refers to is connected. Often, the network host name and physical host name are identical. However, each computer has only one physical host name but may have multiple network host names. Thus, a computer's network host name may not always be its physical host name.
physical host name: This guide differentiates between the terms physical host name and network host name. This guide uses physical host name to refer to the "internal name" of the current computer. On UNIX, this is the name returned by the hostname
command.
Physical host name is used by Oracle Fusion Middleware to reference the local host. During installation, the installer automatically retrieves the physical host name from the current computer and stores it in the Oracle Fusion Middleware configuration metadata on disk.
physical IP: Physical IP refers to the IP address of a computer on the network. In most cases, it is normally associated with the physical host name of the computer (see the definition of the physical host name). In contrast to a virtual IP, it is always associated with the same computer when on a network.
switchover: During normal operation, active members of a system may require maintenance or upgrading. A switchover process can be initiated to allow a substitute member to take over the workload performed by the member that requires maintenance or upgrading, which undergoes planned downtime. The switchover operation ensures continued service to consumers of the system.
switchback: When a switchover operation is performed, a member of the system is deactivated for maintenance or upgrading. When the maintenance or upgrading is completed, the system can undergo a switchback operation to activate the upgraded member and bring the system back to the pre-switchover configuration.
virtual host name: Virtual host name is a network addressable host name that maps to one or more physical computers via a load balancer or a hardware cluster. For load balancers, the name "virtual server name" is used interchangeably with virtual host name in this book. A load balancer can hold a virtual host name on behalf of a set of servers, and clients communicate indirectly with the computers using the virtual host name. A virtual host name in a hardware cluster is a network host name assigned to a cluster virtual IP. Because the cluster virtual IP is not permanently attached to any particular node of a cluster, the virtual host name is not permanently attached to any particular node either.
Note: Whenever the term "virtual host name" is used in this document, it is assumed to be associated with a virtual IP address. In cases where just the IP address is needed or used, it will be explicitly stated. |
virtual IP: (Cluster virtual IP, load balancer virtual IP.) Generally, a virtual IP can be assigned to a hardware cluster or load balancer. To present a single system view of a cluster to network clients, a virtual IP serves as an entry point IP address to the group of servers which are members of the cluster. A virtual IP can be assigned to a server load balancer or a hardware cluster.
A hardware cluster uses a cluster virtual IP to present to the outside world the entry point into the cluster (it can also be set up on a standalone computer). The hardware cluster's software manages the movement of this IP address between the two physical nodes of the cluster while clients connect to this IP address without the need to know which physical node this IP address is currently active on. In a typical two-node hardware cluster configuration, each computer has its own physical IP address and physical host name, while there could be several cluster IP addresses. These cluster IP addresses float or migrate between the two nodes. The node with current ownership of a cluster IP address is active for that address.
A load balancer also uses a virtual IP as the entry point to a set of servers. These servers tend to be active at the same time. This virtual IP address is not assigned to any individual server but to the load balancer which acts as a proxy between servers and their clients.
This chapter provides information about how the database tier is implemented in an enterprise deployment topology.
This chapter includes the following topics:
Section 4.1, "Understanding the Database in the Enterprise Deployment Topology"
Section 4.4, "Loading the Oracle Fusion Applications Repository into the Oracle RAC Database"
The Oracle Fusion Applications reference enterprise deployment topology uses a single database for the following components:
Oracle Fusion Applications metadata
Oracle Fusion Applications transactional data
Oracle Transactional Business Intelligence data
Technology stack data, such as Oracle SOA Suite, Oracle Enterprise Manager Fusion Middleware Control, Oracle WebCenter Portal, and Oracle Essbase.
Oracle Secure Enterprise Search data
Implementing Oracle Business Intelligence Data Warehouse requires a separate database for following components:
Data Warehouse Administration Console (DAC)
Informatica
a Data Warehouse
For the enterprise topology, Oracle Real Application Clusters (Oracle RAC) databases are highly recommended. You must set up these databases before you can install and configure the Oracle Fusion Applications components. You install the Oracle Fusion Applications and Oracle Fusion Middleware metadata repositories into existing databases using the Fusion Applications Repository Creation Utility (Fusion Applications RCU).
Before loading the metadata repository into your database, check that the database meets the requirements described in these sections:
Note: When creating the database, ensure that the length of the Oracle System ID (SID) does not exceed eight (8) characters. For example:
|
Note the following requirements for the hosts FUSIONDBHOST1
and FUSIONDBHOST2
in the data tier:
Oracle Clusterware
For Oracle Database 11g Release 2 (11.2.0.2) for Linux, refer to the Oracle Database Installation Guide.
Oracle Real Application Clusters
For Oracle RAC 11g Release 2 (11.2.0.2) for Linux or Oracle Database 10g Release 2 (10.2) for Linux, refer to the Oracle Database Installation Guide.
Oracle Automatic Storage Management (optional)
Oracle ASM gets installed for the node as a whole. It is recommended that you install it in a separate Oracle Home from the Database Oracle Home. This option comes in at runInstaller. In the Select Configuration page, select the Configure Automatic Storage Management option to create a separate Oracle ASM home.
Oracle Fusion Applications requires the presence of a supported database and schemas. To check if your database is certified or to see all certified databases, refer to the supported platforms documentation for Oracle Fusion Applications.
To check the release of your database, you can query the PRODUCT_COMPONENT_VERSION
view as follows:
SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE PRODUCT LIKE 'Oracle%';
Notes:
|
You enable label security in the Select Database Edition screen, shown in Figure 4-1, using Oracle Universal Installer.
Table 4-1 shows the recommended minimum init.ora parameters for an Oracle database. The database shipped with the Oracle Fusion Applications software contains this configuration. When you run the Fusion Applications RCU, its prerequisite check feature checks to see that the database meets these minimum requirements.
Table 4-1 Minimum Requirements for Database Configuration
INST_ID Parameter | Value |
---|---|
_b_tree_bitmap_plans |
FALSE |
audit_trail |
NONE |
compatible |
11.2.0 |
db_files |
1024 |
db_recovery_file_dest_size |
2147483648 |
db_writer_processes |
1 |
disk_asynch_io |
FALSE |
fast_start_mttr_target |
3600 |
filesystemio_options |
Setall |
job_queue_processes |
10 |
log_buffer |
10485760 |
log_checkpoints_to_alert |
TRUE |
max_dump_file_size |
10M |
memory_target |
unset or N/A |
nls_sort |
BINARY |
open_cursors |
500 |
pga_aggregate_target |
>= 4294967296 (4GB) |
plsql_code_type |
NATIVE |
processes |
5000 |
session_cached_cursors |
500 |
sga_target |
>=9663676416 (9GB) |
trace_enabled |
FALSE |
undo_management |
AUTO |
For example, to use the SHOW PARAMETER
command using SQL*Plus to check the value of the initialization parameter:
As the SYS user, issue the SHOW PARAMETER
command as follows:
SQL> SHOW PARAMETER processes
Set the initialization parameter using the following commands:
SQL> ALTER SYSTEM SET processes=5000 SCOPE=SPFILE; SQL> ALTER SYSTEM SET open_cursors=500 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. |
Oracle recommends using the Oracle Enterprise Manager Fusion Middleware Control Cluster Managed Services screen or SQL*Plus to create database services that client applications will use to connect to the database.
To configure this using SQL*Plus:
Use the CREATE_SERVICE
subprogram to create the database service.
Log in to SQL*Plus as the sysdba user and run the following command:
SQL> EXECUTE DBMS_SERVICE.CREATE_SERVICE (SERVICE_NAME => 'crm
.mycompany.com', NETWORK_NAME => 'crm
.mycompany.com' );
Add the service to the database and assign it to the instances using srvctl
:
prompt> srvctl add service -dfusiondb
-scrm
.mycompany.com -rfusiondb1
,fusiondb2
Start the service using srvctl
:
prompt> srvctl start service -dfusiondb
-scrm
.mycompany.com
Verify that the crm
service is running on instance(s) fusiondb1
and fusiondb2
:
prompt> srvctl status service -d fusiondb
Note: For more information about the |
Oracle recommends that a specific database service be used for a product suite even when they share the same database. It is also recommended that the database service used is different than the default database service. For example, for Oracle Fusion Customer Relationship Management the database would be crmdb
.mycompany.com
and the default service is one with the same name. The Oracle Fusion Customer Relationship Management install is configured to use the service crm
.mycompany.com
.
This section describes how to update the kernel parameters for Linux before the database is installed.
To update the parameters:
Log in as root and add or edit the following values in the /etc/sysctl.conf
file:
fs.file-max = 6815744 kernel.shmall = 2097152 kernel.shmmax = 2147483648 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 net.core.rmem_default = 4194304 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 tcp.ipv4.tcp_wmem = 262144 262144 262144 tcp.ipv4.tcp_rmem = 4194304 4194304 4194304 fs.aio-max-nr = 1048576 net.ipv4.ip_local_port_range = 9000 65000
Execute the following command to activate the changes:
/sbin/sysctl -p
Before loading the Oracle Fusion Applications repository into a database, you must apply database patch 10220058 in order to run the Oracle Fusion Applications Repository Creation Utility (Fusion Applications RCU) with Oracle Database 11g Enterprise Edition Release 11.2.0.2.0. To find the patch, go to My Oracle Support (https://support.oracle.com
) and click the Patches & Updates tab.
The Fusion Applications RCU components are included in the zipped Fusion Applications RCU file delivered in the provisioning framework. (The location of the file is ORACLE_BASE
/installers/apps_rcu/linux/rcuHome_fusionapps_linux.zip
.) Unzip the file to the RCU_HOME
location on the FUSIONDBHOST1
machine. For example, ORACLE_BASE
/rcu
.
Once you have the Fusion Applications RCU installed, do the following:
Copy all the required dump files locally on FUSIONDBHOST1
(for example, to /tmp
):
FUSIONDBHOST1
> cd RCU_HOME/rcu/integration/fusionappsFUSIONDBHOST1
> cp export_fusionapps_dbinstall.zip /tmpFUSIONDBHOST1
> cd RCU_HOME/rcu/integration/biapps/schemaFUSIONDBHOST1
> cp otbi.dmp /tmpFUSIONDBHOST1
> cd /tmpFUSIONDBHOST1
> unzip export_fusionapps_dbinstall.zip
Note: When running Fusion Applications RCU for Oracle RAC, you must copy the |
Create the incident_logs
directory on FUSIONDBHOST1
:
FUSIONDBHOST1
> cd ORACLE_HOMEFUSIONDBHOST1
> mkdir incident_logs
Start Fusion Applications RCU from the /bin
directory in the Fusion Applications RCU home directory:
cd RCU_HOME/bin
./rcu
In the Welcome screen (if displayed), click Next.
In the Create Repository screen, shown in Figure 4-2, select Create to load component schemas into a database. Click Next.
In the Database Connection Details screen, shown in Figure 4-3, enter connect information for your database:
Database Type: Select Oracle Database
Host Name: Specify the name of the node on which the database resides. For the Oracle RAC database, specify the VIP name or one of the node names as the host name: FUSIONDBHOST1
-VIP
Port: Specify the listen port number for the database; for example 1521
Service Name: Specify the service name of the database (crm
.mycompany.com
)
Username: Specify the name of the user with DBA or SYSDBA privileges: SYS
Password: Enter the password for the SYS user
Role: Select the database user's role from the list: SYSDBA
(required by the SYS user)
Click Next.
The Repository Creation Utility selects the required components automatically, as shown in Figure 4-4.
Click Next. The Repository Creation Utility checks the prerequisites, as shown in Figure 4-5.
Click OK.
In the Schema Passwords screen, shown in Figure 4-6, enter passwords for the main and additional (auxiliary) schema users, and click Next.
Note: For increased security, do the following:
|
In the Custom Variables screen, shown in Figure 4-7, enter the required values.
Fusion Applications
FUSIONAPPS_DBINSTALL_DP_DIR: The directory on the database server where you unzipped export_fusionapps_dbinstall.zip
and copied the otbi.dmp
file. For example, /tmp
.
APPLCP_FILE_DIR: Used by Oracle Enterprise Scheduler to store the log and output files. For example, ORACLE_HOME
/incident_logs
.
APPLLOG_DIR: Location of the PL/SQL log file from Oracle Fusion Applications PL/SQL procedures, on the database server. For example, ORACLE_HOME
/incident_logs
.
OBIEE Backup Directory: Location of the Oracle Business Intelligence Enterprise Edition dump files.
Note: When specifying an Oracle Business Intelligence Enterprise Edition (OBIEE) backup directory, set it to be a shared directory with read/write permissions for both |
KEYFLEXCOMBFILTER: Location of the Filter XMLSchema. For example, /tmp
.
Secure Enterprise Search
Do you have Advanced Compression Option (ACO) License? Yes (Y) or No (N): Default is No.
Do you have Oracle Partitioning option License? Yes (Y) or No (N): Default is No.
Master and Work Repository
Note: The default values are the only valid values. If you change any of these values, the ODI-related provisioning process will not work.
Master Repository ID: Default = 501
Supervisor Password: Enter and confirm your ODI supervisor password.
Work Repository Type: (D) Development or (R). Default = D
Work Repository ID: Default = 501
Work Repository Name: Default = FUSIONAPPS_WREP
Work Repository Password: Default = None. Enter and confirm your ODI supervisor password.
Oracle Transactional BI
Directory on the database server where Oracle Transactional Business Intelligence import and export files are stored. For example, /tmp
.
Activity Graph and Analytics
Install Analytics with Partitioning (Y/N): Default is N.
Click Next to continue.
In the Map Tablespaces screen, click Next.
In the Summary screen, click Create.
In the Completion Summary screen, click Close.
Note: If you encounter any issues while using the Repository Creation Utility, check the logs at |
Note: Oracle recommends using the database used for identity management to store the Oracle WSM policies. It is therefore expected to use the IM database information for the OWSM MDS schemas, which will be different from the one used for the rest of SOA schemas. To create the required schemas in the database, repeat the steps above using the IM database information, but select only "AS Common Schemas: Metadata Services" in the Select Components screen (Step 7). |
After you have loaded the metadata repository in your database, you should make a backup.
Backing up the database is for the explicit purpose of quick recovery from any issue that may occur in the further steps. You can choose to use your backup strategy for the database for this purpose or simply make a backup using operating system tools or RMAN for this purpose. It is recommended that you use Oracle Recovery Manager for the database, particularly if the database was created using Oracle ASM. If possible, a cold backup using operating system tools such as tar can also be performed.
The first Oracle HTTP Server was configured during the provisioning process (see Chapter 5). This chapter describes how to scale out Oracle HTTP Server for additional hosts.
This chapter includes the following topics:
To scale out Oracle HTTP Server:
Reboot WEBHOST2
to start the scaleout from a clean machine.
Note:
|
Create the directory ORACLE_BASE
/repository/installers
with the same user that installed Oracle HTTP Server on WEBHOST1
.
Copy or ftp
the installers from WEBHOST1
to WEBHOST2
:
WEBHOST1
>ORACLE_BASE
/repository/installers/webgate
to
WEBHOST2
>ORACLE_BASE
/repository/installers
WEBHOST1
>ORACLE_BASE
/repository/installers/webtier
to
WEBHOST2
>ORACLE_BASE
/repository/installers
WEBHOST1
>ORACLE_BASE
/repository/installers/webtier_patchset
to
WEBHOST2
>ORACLE_BASE
/repository/installers
Run the following command to install Oracle Web Tier on WEBHOST2
(oraInventory
should be located in ORACLE_BASE
/oraInventory
):
ORACLE_BASE
/repository/installers/webtier/Disk1/runInstaller
The Oracle Fusion Middleware 11g Oracle Web Tier Utilities Configuration Welcome window opens.
Click Next to start the installation.
The Select Installation Type window, shown in Figure 6-1, opens.
Select Install Software - Do Not Configure and click Next.
The Prerequisite Checks window, shown in Figure 6-2, opens.
Click Next. The Specify Installation Location window, shown in Figure 6-3, opens.
Select the path to Oracle Middleware Home and enter a name for the home directory. For example, /u01/oracle/products/webtier_mwhome/
. Click Next.
In the Specify Security Updates window, shown in Figure 6-4, do the following:
Enter an email address
Indicate that you wish to receive security updates from My Oracle Support
Enter your My Oracle Support password
Click Next. The Installation Summary window, shown in Figure 6-5, opens.
Click Install. The Installation Progress window, shown in Figure 6-6, opens.
Click Next when the installation has finished. The Installation Complete window, shown in Figure 6-7, opens.
Click Finish.
View the directory structure that has been created:
cd ORACLE_BASE
/products/webtier_mwhome
Begin configuring the Oracle Web Tier components:
cd ORACLE_BASE
/products/webtier_mwhome/webtier/bin
run ./config.sh
The Configure Components window, shown in Figure 6-8, opens.
Select Oracle HTTP Server and Associate Selected Components with WebLogic Domain.
Click Next. The Specify WebLogic Domain window, shown in Figure 6-9, opens.
Enter the following:
a domain host name; for example, CRMHOST1
a domain port number; for example, COMMONHOST ADMIN PORT
your CommonDomain Administration Server user name
your CommonDomainAdministration Server password
Click Next. The Specify Component Details window, shown in Figure 6-10, opens.
Do the following:
Select the instance home location; for example, /u01/oracle/config/CommonDomain_webtier1
Enter the instance name; for example, CommonDomain_webtier1
Enter the Oracle HTTP Server component name; for example ohs1
Click Next. The Configure Ports window, shown in Figure 6-11, opens.
Select Specify Ports using Configuration file and click View/Edit.
In the text field that displays, shown in Figure 6-12, enter Oracle HTTP Server port = 7777
.
Note: Copy the |
Click Save and then click Next.
The Specify Security Updates window, shown in Figure 6-13, opens.
Do the following:
Enter an email address
Indicate that you wish to receive security updates from My Oracle Support
Enter your My Oracle Support password
Click Next. The Installation Summary window, shown in Figure 6-14, opens.
Click Configure to install the configuration. The Configuration Progress window, shown in Figure 6-15, opens.
Click Next.
When the installation completes, the Installation Complete window, shown in Figure 6-16, opens.
Click Finish.
Copy or ftp
the FusionVirtualHost files from WEBHOST1
to WEBHOST2
:
WEBHOST1
>ORACLE_BASE
/config/CommonDomain_webtier/config/OHS/ohs1/moduleconf
to
WEBHOST2
>ORACLE_BASE
/config/CommonDomain_webtier1/config/OHS/ohs1/moduleconf/
After the copy, change all WEBHOST1
entries in the .conf
files to WEBHOST2
.
Restart the Oracle HTTP Server instance:
WEBHOST2
> cdORACLE_BASE
/config/CommonDomain_webtier1/binWEBHOST2
> ./opmnctl stopallWEBHOST2
> ./opmnctl startall
From ORACLE_BASE
/repository/installers/webgate
, start the WebGate installation:
run ./Oracle_Access_Manager10_1_4_3_0_linux64_OHS11g_WebGate -gui
When the Welcome window opens, click Next. The Customer Information window, shown in Figure 6-17, opens.
Enter the necessary information and click Next. The Installation Directory window, shown in Figure 6-18, opens.
Enter a destination name and click Next. The Destination Confirmation window, shown in Figure 6-19, opens.
Click Next to start configuring WebGate. The window shown in Figure 6-20 opens.
Enter the location for the GCC runtime libraries and click Next. Following an interim window, the one shown in Figure 6-21 opens.
Select Simple Mode and click Next. The window shown in Figure 6-22 opens.
Note: AccessServer ID, Host name where an Access Server is installed, Port number the Access Server listens to, and Global Access Protocol Pass Phrase need to be obtained from the Oracle Identity Manager stack install. |
Note: The password provided for the WebGate should be same as the one in the provisioning response file. |
Enter the necessary information and click Next. Following an interim window, the one shown in Figure 6-23 opens.
Select Yes and click Next. The Configure Web Server window, shown in Figure 6-24, opens.
Browse for an absolute path or enter one, and click Next. A warning window, shown in Figure 6-25, opens.
Click Next and restart the WebServer, as described in Step 25. The window shown in Figure 6-26 opens after the WebServer has been restarted.
Click Next. The window shown in Figure 6-27 opens.
Select an option and click Next. An informational window, shown in Figure 6-28, opens.
Click Next. Another informational window, shown in Figure 6-29, opens.
Click Next. A window indicating that the installation was successful opens. Figure 6-30 shows this window.
Click Finish. WebGate has now been installed.
Configure your load balancer to route all HTTP requests to the hosts running Oracle HTTP Server, that is, WEBHOST1
and WEBHOST2
.
You do not need to enable sticky session (insert cookie) on the load balancer when Oracle HTTP Server is the front end to Oracle WebLogic Server. You need sticky session if you are going directly from the load balancer to Oracle WebLogic Server, which is not the case in the topology described in this guide.
You also must set Monitors for HTTP.
To validate once the installation is complete:
Check that it is possible to access the Oracle HTTP Server home page using the following URLs:
http://webhost1.mycompany.com:10601
http://webhost2.mycompany.com:7777
Stop WEBHOST1
:
WEBHOST1
> cd /u01/oracle/config/CommonDomain_webtier/binWEBHOST1
> ./opmnctl stopall
Access the following URLs to ensure that the Administration console is visible:
http://crminternal.mycompany.com:7777/console
http://hcminternal.mycompany.com:7777/console
http://scminternal.mycompany.com:7777/console
http://commoninternal.mycompany.com:7777/console
http://biinternal.mycompany.com:7777/console
Access the following URLs to ensure that the Oracle Fusion Applications login screen is visible:
https://crmexternal.mycompany.com/sales/faces/mooOpportunityHome
https://crmexternal.mycompany.com/crmPerformance/faces/TerritoriesMain
https://crmexternal.mycompany.com/contractManagement/faces/ContractsDashboard
https://crmexternal.mycompany.com/customer/faces/CustomerCtrWorkarea
Run the following commands:
WEBHOST1
> cd /u01/oracle/config/CommonDomain_webtier/binWEBHOST1
> ./opmnctl startall
This chapter describes how to scale out the Oracle Fusion Financials domain.
This chapter includes the following topics:
Section 12.1, "Overview of the Oracle Fusion Financials Domain"
Section 12.2, "Prerequisites for Scaling Out the Oracle Fusion Financials Domain"
Section 12.3, "Adding a New Machine in the Oracle WebLogic Server Console"
Section 12.4, "Packing and Unpacking the Managed Server Domain Home"
Section 12.5, "Cloning Managed Servers and Assigning Them to CRMHOST2"
Section 12.7, "Configuring Server Migration for the Managed Servers"
The Oracle Fusion Financials domain provides Oracle Fusion Financials with Currency, Calendar, and other functionality. The Oracle Fusion Financials domain exposes setup portlets that the Oracle Fusion Customer Relationship Management implementation manager can use via Functional Setup Manager.
Figure 2-7 in Chapter 2, "Introduction to the Enterprise Deployment Reference Topologies," shows the topology for the Oracle Fusion Financials domain within the overall reference enterprise deployment topology.
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 CRMHOST2
should be the same as the user on CRMHOST1
The directory structure /u01/oracle
is mounted to same shared file system as CRMHOST1
The directory structure /u02/local/oracle/config
on CRMHOST2
has been created
The initial Oracle Fusion Customer Relationship Management deployment on CRMHOST1
has already been done and verified by provisioning
To add a new machine:
Log in to the Administration Server: http://
fininternal
.mycompany.com:7777/console
.
Navigate to FinancialDomain > Environment > Machines.
LocalMachine is located in the right-hand pane.
In the left-hand pane, click Lock & Edit.
In the right-hand pane, first click New to add the remote machine, and then specify the following:
Name - enter CRMHOST2
Machine operating system - Unix
Click Next.
In the window that opens, set the following attributes:
Type - SSL
Listen Address - <CRMHOST2
>
Note: The "localhost" default value here is wrong. |
Listen port - 5556
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. |
Since the CRMHOST1
domain directory file system is also available from CRMHOST2
, both pack
and unpack
commands can be executed from CRMHOST2
.
To pack and unpack the Managed Server domain home:
Change directory to ORACLE_BASE
/products/fusionapps/oracle_common/common/bin
.
Run the pack
command:
CRMHOST2
> ./pack.sh -managed=true -domain=ORACLE_BASE
/config/domains/CRMHOST1
/FinancialDomain -template=ORACLE_BASE/
user_templates/ FinancialDomain_managed.jar -template_name= "Financial_Managed_Server_Domain"
Ensure that /u02/local/oracle/config/domains/
CRMHOST2
/FinancialDomain
is empty, and then run the unpack
command:
CRMHOST2
> ./unpack.sh -domain=/u02/local/oracle/config/domains/CRMHOST2
/ FinancialDomain -template=ORACLE_BASE
/user_templates/ FinancialDomain_managed.jar
Here, ORACLE_BASE
is shared, and /u02/local
is local to CRMHOST2
.
To add a Managed Server and assign it to CRMHOST2
:
Log in to the Administration Server: http://
fininternal
.mycompany.com:7777/console
.
Navigate to FinancialDomain > Environment > Servers.
Switch to Lock & Edit mode.
Select the Managed_Servers checkbox (for example, GeneralLedgerServer_1) and then click Clone.
Specify the following Server Identity attributes:
Server Name - GeneralLedgerServer_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 - <CRMHOST2
>
Server Listen Port - leave "as is"
Click OK.
You now should see the newly cloned server, GeneralLedgerServer_2
.
Click GeneralLedgerServer_2 and change the following attributes:
Machine - <CRMHOST2
>
Cluster Name - accept the default, GeneralLedgerCluster
Note: Ensure that this cluster name is the same as the cluster name of the original Managed Server. |
Click Save and then Activate Changes.
Navigate to FinancialDomain > Environment > Servers .
From the Name column, click the GeneralLedgerServer_2 scaled-out server link.
Click Lock & Edit, and then select the Configuration tab.
Select the Keystores tab, and ensure that the keystores value is Custom Identity and Custom Trust.
Do the following:
Change the Custom Identity Keystore path to point to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/
CRMHOST2
_fusion_identity.jks
file.
Leave the Custom Identity Keystore type blank.
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 CRMHOST2."
Re-enter the Confirm Custom Identity Keystore Passphrase.
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.
Leave the Custom Trust Keystore type blank.
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 CRMHOST2."
Re-enter the Custom Trust Keystore Passphrase.
Click Save.
Select the SSL tab.
Make sure that Identity and Trust Locations is set to Keystores.
Change the Private Key Alias to CRMHOST2
_fusion
.
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 CRMHOST2."
Re-enter the keypassword from Step c for the Confirm Private Key Passphrase.
Click Save.
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/GeneralLedger_2 -Dserver.group=GeneralLedgerCluster
Click Save.
Select the Logging tab, and then select the HTTP tab.
Do the following:
Change the Log file name to logs/access.log.%yyyyMMdd%
.
Change the rotation type to By Time.
Leave the Limit number of retained files option unchecked.
Leave the Rotate log file on startup option unchecked.
Click Save.
Expand Advanced.
Change the format to Extended.
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)
Click Save.
Click Activate Changes.
Repeat Steps 2 to 18 for all the Managed Servers on this domain.
Set the following environment variable on CRMHOST2
:
WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE
/
products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks"
Stop the domain's Administration Server:
CRMHOST1
>CRACLE_BASE
/config/domains/CRMHOST1
/ FinancialDomain/bin/stopWebLogic.sh
Restart the domain's Administration Server:
CRMHOST2
>ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/bin/wlst.shCRMHOST2
> nmConnect(username='<username>', password='<password>', domainName='FinancialDomain', host='CRMHOST1
',port='5556', nmType='ssl', domainDir='ORACLE_BASE
/config/domains/CRMHOST1
/FinancialDomain')CRMHOST2
> nmStart('AdminServer')
Note: The username and password used in the |
Run the newly created Managed Servers:
Log in to the Administration Server: http://
fininternal
.mycompany.com:7777/console
.
Navigate to FinancialDomain > Environment > Servers > Control.
Select the newly created Managed Servers and click Start.
Navigate to FinancialDomain > Environment > Servers and check the State to verify that the newly created Managed Servers are running.
To configure Oracle HTTP Server:
On WEBHOST1
:
Change directory to ORACLE_BASE
/config/CommonDomain_webtier/config/OHS/ohs1/moduleconf
.
Copy FusionVirtualHost_fin.conf
to FusionVirtualHost_fin.conf.org
.
Edit the FusionVirtualHost_fin.conf
file, adding the scaled-out host and port to all the WebLogic Application Clusters. Example 12-1 shows sample code for GeneralLedgerServer.
Notes:
|
Repeat Step 2 for all applications.
Restart Oracle HTTP Server: cd
to ORACLE_BASE
/config/CommonDomain_webtier/bin
and enter the following:
WEBHOST1
> ./opmnctl stopallWEBHOST1
> ./opmnctl startall
Server migration is required for proper failover of Oracle Fusion Customer Relationship Management components in the event of failure in any of the CRMHOST1
and CRMHOST2
nodes. For more information, see Chapter 17, "Setting Up Server Migration for an Enterprise Deployment."
You should verify URLs to ensure that the appropriate routing and failover are working.
To verify the URLs:
Log in to the FinancialDomain
Oracle WebLogic Server Administration Console and stop all the Managed Servers on CRMHOST1
while the Managed Servers on CRMHOST2
are running.
Access the following URL to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
https://finexternal.mycompany.com/ledger/faces/JournalEntryPage
Log in to the FinancialDomain
Oracle WebLogic Server Administration Console and stop all the Managed Servers on CRMHOST2
.
Start the Managed Servers on CRMHOST1
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the Managed Servers on CRMHOST2
and verify that they are running on CRMHOST1
and CRMHOST2
.
This chapter describes how to scale out the Oracle Fusion Human Capital Management domain.
This chapter includes the following topics:
Section 10.1, "Overview of the Oracle Fusion Human Capital Management Domain"
Section 10.2, "Prerequisites for Scaling Out the Oracle Fusion Human Capital Management Domain"
Section 10.3, "Adding a New Machine in the Oracle WebLogic Server Console"
Section 10.4, "Packing and Unpacking the Managed Server Domain Home"
Section 10.5, "Cloning Managed Servers and Assigning Them to CRMHOST2"
Section 10.7, "Configuring Server Migration for the Managed Servers"
The Oracle Fusion Human Capital Management domain provides the user-management flow needed to create a user, which is executed via Oracle Fusion Human Capital Management/Oracle Identity Management integration. The flow is available as part of Customer Data Management.
Figure 2-5 in Chapter 2, "Introduction to the Enterprise Deployment Reference Topologies," shows the topology for the Oracle Fusion Human Capital Management domain within the overall reference enterprise deployment topology.
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 CRMHOST2
should be the same as the user on CRMHOST1
The directory structure /u01/oracle
is mounted to same shared file system as CRMHOST1
The directory structure /u02/local/oracle/config
on CRMHOST2
has been created
The initial Oracle Fusion Customer Relationship Management deployment on CRMHOST1
has already been done and verified by provisioning
To add a new machine:
Log in to the Administration Server: http://
hcminternal
.mycompany.com:7777/console
.
Navigate to HCMDomain > Environment > Machines.
LocalMachine is located in the right-hand pane.
In the left-hand pane, click Lock & Edit.
In the right-hand pane, first click New to add the remote machine, and then specify the following:
Name - enter CRMHOST2
Machine operating system - Unix
Click Next.
In the window that opens, set the following attributes:
Type - SSL
Listen Address - <CRMHOST2
>
Note: The "localhost" default value here is wrong. |
Listen port - 5556
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. |
Since the CRMHOST1
domain directory file system is also available from CRMHOST2
, both pack
and unpack
commands can be executed from CRMHOST2
.
To pack and unpack the Managed Server domain home:
Change directory to ORACLE_BASE
/products/fusionapps/oracle_common/common/bin
.
Run the pack
command:
CRMHOST2
> ./pack.sh -managed=true -domain=ORACLE_BASE
/config/domains/CRMHOST1
/HCMDomain -template=ORACLE_BASE
/user_templates/ HCMDomain_managed.jar -template_name="HCM_Managed_Server_Domain"
Ensure that /u02/local/oracle/config/domains/
CRMHOST2
/HCMDomain
is empty, and then run the CRMHOST2
command:
CRMHOST2
> ./unpack.sh -domain=/u02/local/oracle/config/domains/CRMHOST2
/HCMDomain -template=ORACLE_BASE
/user_templates/HCMDomain_managed.jar
Here, ORACLE_BASE
is shared, and /u02/local
is local to CRMHOST2
.
To add a Managed Server and assign it to CRMHOST2
:
Log in to the Administration Server: http://
hcminternal
.mycompany.com:7777/console
Navigate to HCMDomain > Environment > Servers.
Switch to Lock & Edit mode.
Select the Managed_Server checkbox (for example, CoreSetupServer_1) and then click Clone.
Specify the following Server Identity attributes:
Server Name - CoreSetupServer_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 - <CRMHOST2
>
Server Listen Port - leave "as is"
Click OK.
You now should see the newly cloned sales server, CoreSetupServer_2
.
Click CoreSetupServer_2 and change the following attributes:
Machine - <CRMHOST2
>
Cluster Name - accept the default, CoreSetupCluster
Note: Ensure that this cluster name is the same as the cluster name of the original Managed Server. |
Click Save and then Activate Changes.
Navigate to HCMDomain > Environment > Servers.
From the Name column, click the CoreSetupServer_2 scaled-out server link.
Click Lock & Edit, and then select the Configuration tab.
Select the Keystores tab, and then ensure that the keystores value is Custom Identity and Custom Trust.
Do the following:
Change the Custom Identity Keystore path to point to the ORACLE_BASE
/products/fusionapps/wlserver_10.3/server/lib/
CRMHOST2
_fusion_identity.jks
file.
Leave the Custom Identity Keystore type blank.
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 CRMHOST2."
Re-enter the Confirm Custom Identity Keystore Passphrase.
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.
Leave the Custom Trust Keystore type blank.
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 CRMHOST2."
Re-enter the Custom Trust Keystore Passphrase.
Click Save.
Select the SSL tab.
Make sure that Identity and Trust Locations is set to Keystores.
Change the Private Key Alias to CRMHOST2
_fusion
.
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 CRMHOST2."
Re-enter the keypassword from Step c for the Confirm Private Key Passphrase.
Click Save.
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/HCMDomain/CoreSetupServer_2 -Dserver.group=CoreSetupCluster
Click Save.
Select the Logging tab, and then select the HTTP tab.
Do the following:
Change the Log file name to logs/access.log.%yyyyMMdd%
.
Change the rotation type to By Time.
Leave the Limit number of retained files option unchecked.
Leave the Rotate log file on startup option unchecked.
Click Save.
Expand Advanced.
Change the format to Extended.
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)
Click Save.
Click Activate Changes.
Repeat Steps 2 to 18 for all the Managed Servers on this domain.
Set the following environment variable on CRMHOST2
:
WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=ORACLE_BASE
/
products/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks"
Stop the domain's Administration Server:
CRMHOST1
>ORACLE_BASE
/config/domains/CRMHOST1
/HCMDomain/bin/stopWebLogic.sh
Start the domain's Administration Server:
CRMHOST2
>ORACLE_BASE
/products/fusionapps/wlserver_10.3/common/bin/wlst.shCRMHOST2
> nmConnect(username='<username>', password='<password>', domainName='HCMDomain', host='CRMHOST1
',port='5556', nmType='ssl', domainDir='ORACLE_BASE
/config/domains/CRMHOST1
/HCMDomain')CRMHOST2
> nmStart('AdminServer')
Note: The username and password used in the |
Run the newly created Managed Servers:
Log in to the Administration Server: http://
hcminternal
.mycompany.com:7777/console
.
Navigate to HCMDomain > Environment > Servers > Control.
Select the newly created Managed Servers and click Start.
Navigate to HCMDomain > Environment > Servers and check the State to verify that the newly created Managed Servers are running.
To configure Oracle HTTP Server:
On WEBHOST1
:
Change directory to ORACLE_BASE
/config/CommonDomain_webtier/config/OHS/ohs1/moduleconf
.
Copy FusionVirtualHost_hcm.conf
to FusionVirtualHost_hcm.conf.org
.
Edit the FusionVirtualHost_hcm.conf
file, adding the scaled-out host and port to all the WebLogic Application Clusters. Example 10-1 shows sample code for CoreSetupServer.
Notes:
|
Repeat Step 2 for all applications.
Restart Oracle HTTP Server: cd
to ORACLE_BASE
/config/CommonDomain_webtier/bin
and enter the following:
WEBHOST1
> ./opmnctl stopallWEBHOST1
> ./opmnctl startall
Server migration is required for proper failover of Oracle Fusion Customer Relationship Management components in the event of failure in any of the CRMHOST1
and CRMHOST2
nodes. For more information, see Chapter 17, "Setting Up Server Migration for an Enterprise Deployment."
You should verify URLs to ensure that the appropriate routing and failover are working.
To verify the URLs:
Log in to the HCMDomain
Oracle WebLogic Server Administration Console and stop all the Managed Servers on CRMHOST1
while the Managed Servers on CRMHOST2
are running.
Access the following URL to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
https://hcmexternal.mycompany.com/hcmCoreSetup/faces/HcmWSIntWA
Log in to the HCMDomain
Oracle WebLogic Server Administration Console and stop all the Managed Servers on CRMHOST2
.
Start the Managed Servers on CRMHOST1
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the Managed Servers on CRMHOST2
and verify that they are running on CRMHOST1
and CRMHOST2
.