12 Extending the Domain to Include BAM

This chapter describes the procedures for extending the domain to include Oracle Business Activity Monitoring (BAM).

This chapter contains the following sections:

12.1 Overview of Adding BAM to a Domain

The BAM system is installed using the WL_HOME and ORACLE_HOME created in Chapter 8, "Creating a Domain for an Enterprise Deployment" on a shared storage. BAMHOST1 and BAMHOST2 mount MW_HOME and reuse the existing WLS and SOA installations. The pack and unpack utilities are used to bootstrap the domain configuration for the WLS_BAM1 and WLS_BAM2 servers in these two new nodes. As a result, you do not need to install any software in these two nodes. For the BAM system to work properly, BAMHOST1 and BAMHOST2 must maintain the same system configuration that was required for installing Oracle FMW in SOAHOST1 and SOAHOST2. Otherwise, unpredictable behavior in the execution of binaries may occur.

12.2 Prerequisites for Extending the Domain to Include BAM

Before performing the steps in this section review the following prerequisites:

Back up the existing installation

If you have not yet backed up the existing Fusion Middleware Home and domain, back it up now.

To back up the existing Fusion Middleware Home and domain:

tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw
tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name

These commands create a backup of the installation files for both Oracle WebLogic Server and Oracle Fusion Middleware, as well as the domain configuration.

Attach the existing Oracle Homes to the Inventory in the BAMHOSTS

On the new node, mount the existing FMW Home, which should include the SOA installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.

To attach an ORACLE_HOME in shared storage to the local Oracle Inventory, use the following command on the BAMHOST:

cd ORACLE_COMMON_HOME/oui/bin/attachHome.sh
./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_version

To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the $HOME/bea/beahomelist file and add MW_HOME to it.

12.3 Enabling VIP4 in BAMHOST1

The BAM System uses a virtual hostname as the listen addresses for the managed server hosting the BAM Server component. This virtual host name and corresponding virtual IP is required to enable server migration for the BAM Server component. Enable a virtual IP (VIP4) mapping BAMHOST1VHN1 on BAMHOST1 and correctly resolve the BAMHOST1VHN1 hostname in the network system used by the topology (either by DNS Server, hosts resolution).

To enable the virtual IP, see Section 3.5, "Enabling Virtual IP Addresses for Administration Servers."

About Accessing an Oracle BAM Server Using the BAM Adapter

When accessing an Oracle BAM Server using the BAM Adapter (rmi), use the Virtual Hostname of the BAM Server (BAMHOST1VNH1) for the connection. SOAP requests come through HTTP, therefore, use the load balancer addresses when using the adapter.

12.4 Running the Configuration Wizard to Extend the Domain

In this step, you extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment" to contain BAM. The instructions in this section assume that the BAM deployment uses the same database service (soaedg.mycompany.com) as the SOA deployment. However, you may choose to use a different database service specifically for BAM.

  1. Change directory to the location of the Configuration Wizard. This is within the SOA home directory.

    cd ORACLE_COMMON_HOME/common/bin

  2. Start the Configuration Wizard:

    ./config.sh

  3. In the Welcome screen, select Extend an existing WebLogic domain, and click Next.

  4. In the WebLogic Domain Directory screen, select the following WebLogic domain directory:

    ORACLE_BASE/admin/domain_name/aserver/domain_name

    Click Next.

  5. In the Select Extension Source screen, do the following:

    • Select Extend my domain automatically to support the following added products.

    • Select the following products:

      • Oracle Business Activity Monitoring 11.1.1.0

    Click Next.

  6. In the Configure JDBC Components Schema screen, do the following:

    • Select BAM Schema.

    • For the Oracle RAC configuration for component schemas, select Convert to GridLink.

    Click Next.

  7. The Configure Gridlink RAC Component Schema screen appears (Figure 12-1).

    Figure 12-1 Configure GridLink RAC Component Schema Screen

    Configure RAC Multi Data Source Component Schema screen

    In this screen enter values for the following fields, specifying the connect information for the Oracle RAC database that was seeded with RCU:

    • Driver: Select Oracle's driver (Thin) for GridLinkConnections,Versions:10 and later.

    • Service Name: Enter the service name of the database using lowercase characters. For example:

      soaedg.mycompany.com

    • Username: Enter the database schema owner name of the corresponding component.

    • Password: Enter the password for the database schema owner.

    • Select Enable FAN

    • Make sure Enable SSL is unchecked (alternatively if ssl is selected for ONS notifications to be encrypted, provide the appropriate wallet and wallet password).

    • Service listener: Enter the SCAN address and port for the RAC database being used. You can identify this address by querying the appropriate parameter in the database using the TCP protocol:

      SQL>show parameter remote_listener;

NAME              TYPE                VALUE
-------------------------------------------------------------
remote_listener   string    db-scan.mycompany.com:1521

      Note:

      For Oracle Database 11g Release 1 (11.1), use the virtual IP and port of each database instance listener, for example:

      custdbhost1-vip.mycompany.com (port 1521)

      and

      custdbhost2-vip.mycompany.com (1521)

      For Oracle Database 10g, use multi data sources to connect to an Oracle RAC database. For information about configuring multi data sources see Appendix A, "Using Multi Data Sources with Oracle RAC."

    • ONS Host: Enter the SCAN address for the Oracle RAC database and the ONS remote port as reported by the database:

      [orcl@db-scan1 ~]$ srvctl config nodeapps -s
 
ONS exists: Local port 6100, remote port 6200, EM port 2016

      Note:

      For Oracle Database 11g Release 1 (11.1), use the hostname and port of each database's ONS service, for example

      custdbhost1.mycompany.com (port 6200)

      and

      custdbhost2.mycompany.com (6200)

  8. In the Test JDBC Data Sources screen, the connections should be tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.

    Click Next when all the connections are successful.

  9. In the Select Optional Configuration screen, select the following:

    • Managed Servers, Clusters, and Machines

    • Deployments and Services

    • JMS File Store

    • JMS Distributed Destination

      Click Next.

  10. In the Select JMS Distributed Destination Type screen, select UDD from the drop-down list for all Fusion Middleware Components' JMS Modules.

    Note:

    Oracle does not support using WDDs for Fusion Middleware components.

  11. In the Configure Managed Servers screen, add the required managed servers.

    A server called bam_server1 is created automatically. Rename this to WLS_BAM1 and add a new server called WLS_BAM2. Give these servers the attributes listed in Table 12-1. Do not modify the other servers that appear in this screen; leave them as they are.

    Table 12-1 Managed Servers

    Name Listen Address Listen Port SSL Listen Port SSL Enabled

    WLS_BAM1

    BAMHOST1VHN1

    9001

    n/a

    No

    WLS_BAM2

    BAMHOST2

    9001

    n/a

    No

    Click Next.

  12. In the Configure Clusters screen, add the following clusters listed in Table 12-2. Do not modify the other clusters that display in this screen; leave them as they are.

    Table 12-2 Clusters

    Name Cluster Messaging Mode Multicast Address Multicast Port Cluster Address

    BAM_Cluster

    unicast

    n/a

    n/a

    Leave it empty.

    Click Next.

  13. In the Assign Servers to Clusters screen, add the following. Do not modify the other assignments that display in this screen; leave them as they are.

    • BAM_Cluster

      • WLS_BAM1

      • WLS_BAM2

    Click Next.

  14. In the Configure Machines screen, do the following:

    • Delete the LocalMachine that appears by default.

    • Click the Unix Machine tab. You should add the BAMHOST1 and BAMHOST2 machines and have the following entries:

      Table 12-3 Machines

      Name Node Manager Listen Address

      SOAHOST1

      SOAHOST1

      SOAHOST2

      SOAHOST2

      BAMHOST1

      BAMHOST1

      BAMHOST2

      BAMHOST2

    Leave all other fields to their default values.

    Click Next.

  15. In the Assign Servers to Machines screen, do the following:

    • Assign WLS_BAM1 to BAMHOST1

    • Assign WLS_BAM2 to BAMHOST2.

    Click Next.

  16. In the Target Deployments to Clusters or Servers screen, ensure the following targets:

    • usermessagingserver and usermessagingdriver-email should be targeted only to SOA_Cluster and BAM_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)

    • WSM-PM should be targeted only to WSM-PM_Cluster.

    • The DMS Application should be targeted to BAM_Cluster, SOA_Cluster, WSM-PM_Cluster and Admin Server.

    • Target the oracle.sdp.* library only to SOA_Cluster and BAM_Cluster. Target the oracle.soa.* library only to SOA_Cluster.

    • Target the oracle.rules.* library to SOA_Cluster, BAM_Cluster and Admin Server.

    • oracle.bam* is targeted only to BAM_Cluster.

    Click Next.

  17. In the Target Services to Clusters or Servers screen, ensure the following targets:

  18. In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores as recommended in Section 4.3, "About Recommended Locations for the Different Directories." For example:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

  19. In the Configuration Summary screen, click Extend.

  20. Restart the Administration Server using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

12.5 Configuring a Default Persistence Store for Transaction Recovery

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 the server.

Note:

The recommended location is a dual-ported SCSI disk or on a Storage Area Network (SAN)

To set the location for the default persistence store for WLS_BAM1:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. Click Lock & Edit.

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

  4. Click WLS_BAM1 (represented as a hyperlink) in the Name column of the table. The settings page for the WLS_BAM1 server appears and defaults to the Configuration tab.

  5. Click the Services sub-tab.

  6. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:

    ORACLE_BASE/admin/domain_name/bam_cluster_name/tlogs

  7. Click Save.

  8. Click Activate Changes.

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 BAMHOST1 and BAMHOST2 must be able to access this directory. This directory must also exist before you restart the server.

12.6 Untargeting the BAM Server System from WLS_BAM2

Because the BAM server component in BAM is a singleton, you must untarget it from one of the WLS_BAM servers before you configure it for server migration.

In this step, you remove the BAM server runtime from WLS_BAM2.

To untarget the BAM server artifacts from WLS_BAM2:

  1. Log into the Oracle WebLogic Administration Console at http://ADMINVHN:7001/console.

  2. In the Domain Structure window, choose Environment and then Servers. The Summary of Servers page appears.

  3. Select WLS_BAM2 in Name column of the table. The Settings page for WLS_BAM2 appears.

  4. Click the Deployments tab.

  5. Select the oracle-bam application from the Name column of the table. The Settings page for the oracle-bam application appears.

  6. Click the Targets tab.

  7. Click Lock & Edit.

  8. Change the targets for the modules as described in Table 12-4. You must change all of these components, as incorrect targeting can prevent the BAM system from starting.

    Table 12-4 oracle-bam Component Target Types

    Component Type Target

    oracle-bam(11.1.1)

    Enterprise Application

    BAM_Cluster

    /oracle/bam

    WEBAPP

    WLS_BAM1

    oracle-bam-adc-ejb.jar

    EJB

    WLS_BAM1

    oracle-bam-ems-ejb.jar

    EJB

    WLS_BAM1

    oracle-bam-eventengine-ejb.jar

    EJB

    WLS_BAM1

    oracle-bam-reportcache-ejb.jar

    EJB

    WLS_BAM1

    OracleBAM

    WEBAPP

    BAM_Cluster

    OracleBAMWS

    WEBAPP

    BAM_Cluster

    oracle-bam-statuslistener-ejb.jar

    EJB

    WLS_BAM1

    sdpmessagingclient-ejb.jar

    EJB

    WLS_BAM1

  9. Click Save and Activate Changes

    For information on targeting applications and resources, see Appendix B, "Targeting Applications and Resources to Servers."

12.7 Propagating the Domain Changes to the Managed Server Domain Directory

Propagate the domain configuration to BAMHOST1 and BAMHOST2 using the pack/unpack utility.

Note:

If you configure server migration before unpacking (extending the domain to include BAM), the wlsifconfig script is overwritten and must be restored from the copy tha the-overwrite option provides.

To propagate the new domain configuration:

  1. Make sure that a similar directory and shared storage configuration as SOAHOST2 is present in BAMHOST1 (described in Chapter 3, "Preparing the Network for an Enterprise Deployment"). BAMHOST1 and BAMHOST2 should have mounted the MW_HOME directory as created in Chapter 8, "Creating a Domain for an Enterprise Deployment."

  2. Run the pack command on SOAHOST1 to create a template pack:

    1. Run the following command:

      cd ORACLE_COMMON_HOME/common/bin

      Note:

      Notice that this directory is available as mount point to the MW_HOME created in Chapter 8, "Creating a Domain for an Enterprise Deployment."

    2. Run the pack command:

      ./pack.sh -managed=true -domain=ORACLE_BASE/admin/
domain_name/aserver/domain_name -template=soadomaintemplateExtBAM.jar
 -template_name=soa_domain_templateExtBAM

  3. Run the following command on SOAHOST1 to copy the template file created in the previous step to BAMHOST1.

    scp soadomaintemplateExtBAM.jar
   oracle@BAMHOST1:/ORACLE_COMMON_HOME/common/bin

  4. Run the unpack command on BAMHOST1 to unpack the template in the managed server domain directory as follows:

    BAMHOST1> cd ORACLE_COMMON_HOME/common/bin
BAMHOST1> ./unpack.sh -domain= ORACLE_BASE/admin/
domain_name/mserver/domain_name -template=soadomaintemplateExtBAM.jar 
-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

  5. Run the copy and unpack commands for BAMHOST2.

Note:

The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.

12.8 Disabling Host Name Verification for the WLS_BAMn Managed Servers

For the enterprise deployment described in this guide, you set up the appropriate certificates to authenticate the different nodes with the Administration Server after you have completed the procedures to extend the domain for Oracle SOA Suite. You must disable the host name verification for the WLS_BAM1 and WLS_BAM2 managed servers to avoid errors when managing the different WebLogic Server instances. For more information, see Section 8.4.8, "Disabling Host Name Verification."

You enable host name verification again once the enterprise deployment topology configuration is complete. For more information, see Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1."

12.9 Starting Node Manager on BAMHOST1 and BAMHOST2

Start Node manager using the setNMProps.sh script.

To start Node Manager on BAMHOST1 and BAMHOST2:

  1. On each server, run the setNMProps.sh script, which is located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled property to 'true' before starting Node Manager:

    BAMHOSTn> cd ORACLE_COMMON_HOME/common/bin
BAMHOSTn> ./setNMProps.sh

    Note:

    Use the StartScriptEnabled property to avoid class loading failures and other problems. For more information about StartScriptEnabled, see Section 16.14.5, "Incomplete Policy Migration After Failed Restart of SOA Server."

    Note:

    If the BAM server is sharing the MW_HOME in a local or shared storage with SOA, as suggested in the shared storage configuration described in Chapter 3, "Preparing the Network for an Enterprise Deployment," it is not required to run setNMProps.sh again. In this case, Node Manager has already been configured to use a startscript.

  2. Run the following commands to start Node Manager on BAMHOST1:

    BAMHOST1> cd WL_HOME/server/bin
BAMHOST1> ./startNodeManager.sh

    Run the following commands to start Node Manager on BAMHOST2:

    BAMHOST2> cd WL_HOME/server/bin
BAMHOST2> ./startNodeManager.sh

12.10 Starting the BAM System

Start the WLS_BAM1 managed server using the Oracle WebLogic Server Administration Console.

These instructions are based on the assumption that the host name verification displayed previously for the WS-M or SOA managed servers in SOAHOST2 and that the Node Manager is already running on SOAHOST2.

To start the WLS_BAM1 managed server on BAMHOST1:

  1. Start the WLS_BAM1 managed servers:

    1. Log into the Oracle WebLogic Server Administration Console at http://ADMINVHN:7001/console.

    2. In the Domain Structure window, expand the Environment node and then select Servers. The Summary of Servers page appears.

    3. Click the Control tab.

    4. Select WLS_BAM1 from the Servers column of the table.

    5. Click Start.

  2. Access http://BAMHOST1VHN1:9001/OracleBAM to verify status of WLS_BAM1.

If the managed server fails to start with the following message:

Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found
The Connection descriptor used by the client was <db_connect_string>

Verify that the PROCESSES initialization parameter for the database is set to a high enough value. See Section 5.2.3, "About Initialization Parameters" for details. This error often occurs when you start servers that are subsequent the first server.

  1. Start the WLS_BAM2 managed servers:

    1. Log into the Oracle WebLogic Administration Console at http://ADMINVHN:7001/console.

    2. In the Domain Structure window, expand the Environment node and then select Servers. The Summary of Servers page appears.

    3. Click the Control tab.

    4. Select WLS_BAM2 from the Servers column of the table.

    5. Click Start.

  2. Access http://BAMHOST2:9001/OracleBAM to verify status of WLS_BAM2.

12.11 Validating GridLink Data Sources

When the servers are started, verify that the GridLink data sources are correctly configured and that the ONS setup is correct. Perform this procedure for every GridLink data source created.

To validate the GridLink data sources configuration:

  1. Log on to the Oracle WebLogic Administration Console.

  2. In the Domain Structure tree, expand Services, and select Data Sources.

  3. Click one of the new data sources.

  4. Click the Monitoring tab and select one of the servers.

  5. Click the Statistics tab and select one of the servers.

  6. Click the ONS tab, and then click the Testing tab.

  7. Select the server and click Test ONS.

    If both tests are successful, the configuration is correct. If the ONS test fails, verify that the ONS service is running in the RAC database nodes:

    orcl@db-scan1 ~]$ srvctl status scan_listener
SCAN Listener LISTENER_SCAN1 is enabled
SCAN listener LISTENER_SCAN1 is running on node db-scan1
SCAN Listener LISTENER_SCAN2 is enabled
SCAN listener LISTENER_SCAN2 is running on node db-scan2
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node db-scan2
 
[orcl@db-scan1 ~]$ srvctl config nodeapps -s 
ONS exists: Local port 6100, remote port 6200, EM port 2016
 
[orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
ONS is enabled
ONS daemon is running on node: db-scan1
ONS daemon is running on node: db-scan2

Run the ONS test from every WebLogic server that uses the data source.

12.12 Configuring the BAM Web Applications to Use the BAM Server in BAMHOST1

To configure the OracleBamWeb(WLS_BAM1) and OracleBamWeb(WLS_BAM2) applications to use the BAM server in BAMHOST1:

  1. Access Oracle Enterprise Manager Fusion Middleware Control through http://ADMINVHN:7001/em.

  2. Expand BAM in the navigation tree.

  3. Right-click OracleBamWeb(WLS_BAM1).

  4. Choose BAM Web Properties from the context menu. The BAM Web Properties page appears.

  5. Define the following properties:

    • Enter https://soa.mycompany.com:443 for the application URL.

    • Enter BAMHOST1VHN1 for the server name. See also Table 3-2 in Section 3.4, "About IPs and Virtual IPs."

    • Click Apply.

    • Modify the listening port of the server using the Mbean browser:

      • Log into the Oracle Enterprise Manager Fusion Middleware Control.

      • Expand the domain name in the left navigation tree.

      • Expand the BAM item in the left navigation tree.

      • Highlight OracleBamServer in the left navigation tree.

      • In the BAMServer drop-down menu on the top-right, select System Mbean Browser.

      • Navigate to the oracle.bam.web, Server, Application, Config, and then BAMWebConfig, on the right.

      • In the ServerPort field, replace the "DEFAULT" value with 9001.

  6. Select OracleBamWeb(WLS_BAM2) from the navigation tree and repeat steps 3 through 5.

12.13 Configuring Oracle HTTP Server for the WLS_BAMn Managed Servers

To enable Oracle HTTP Server to route to BAM_Cluster, which contains the WLS_BAMn managed servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster as follows:

To enable Oracle HTTP Server to route to the SOA_Cluster:

  1. On WEBHOST1 and WEBHOST2, add directives to the soa_vh.conf file located in the following directory:

    ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

    Note that this assumes you created the soa_vh.conf file using the instructions in Section 7.6, "Defining Virtual Hosts."

    Add the following directives to the soa_vh.conf file within the <VirtualHost> tags.

    # BAM Web Application
<Location /OracleBAM >
    SetHandler weblogic-handler
    WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /OracleBAMWS >
    SetHandler weblogic-handler
    WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

    The soa_vh.conf file will appear as it does in Example 12-1.

  2. Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2 as follows:

    WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1
WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2

Example 12-1 soa_vh.conf file

<VirtualHost *:7777>
    ServerName https://soa.mycompany.com:443
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

<Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Worklist
<Location /integration>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# B2B
<Location /b2bconsole>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Default to-do taskflow
<Location /workflow/DefaultToDoTaskFlow/>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# Workflow
<Location /workflow>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    SetHandler weblogic-handler 
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# SOA composer application 
 <Location /soa/composer> 
     SetHandler weblogic-handler 
     WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

# BAM Web Application
<Location /OracleBAM >
    SetHandler weblogic-handler
    WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /OracleBAMWS >
    SetHandler weblogic-handler
    WebLogicCluster BAMHOST1VHN1:9001,BAMHOST2:9001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>

The servers specified in the WebLogicCluster parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of 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:

  • 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 on the fly at runtime.

  • 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 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 the Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server guide.

12.14 Validating Access Through Oracle HTTP Server

Verify URLs to ensure that appropriate routing and failover is working from the HTTP Server to the BAM_Cluster.

To verify the URLs:

  1. While WLS_BAM2 is running, stop WLS_BAM1 using the Oracle WebLogic Server Administration Console.

  2. Access WebHost1:7777/OracleBAM to verify the appropriate functionality. You can not retrieve reports or data at this point since the BAM server is down.

  3. Start WLS_BAM1 from the Oracle WebLogic Server Administration Console.

  4. Stop WLS_BAM2 from the Oracle WebLogic Server Administration Console.

  5. Access WebHost1:7777/OracleBAM to verify the appropriate functionality.

12.15 Configuring Server Migration for the WLS_BAM1 Server

The high-availability architecture for BAM uses server migration to protect the BAM server singleton service against failures. The WLS_BAM1 managed server is configured so that it can be restarted on BAMHOST2 if it fails. For this configuration, WLS_BAM1 listens on a specific, floating IP address that is failed over by WebLogic Server migration. To configure server migration for the WLS_BAM1 managed servers, complete the following tasks:

Note:

If server migration was configured previously for SOA, the BAM stem can use the same data sources and database schemas. In that case, steps 1 through 4 are not required, but you must target the corresponding server-migration/leasing datasources to the BAM Cluster.

12.15.1 Setting Up the User and Tablespace for the Server Migration Leasing Table

To create the user and tablespace:

  1. 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;

  2. Create a user named leasing and assign it to the leasing tablespace as follows:

    SQL> create user leasing identified by password;
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;

  3. Create the leasing table using the leasing.ddl script as follows:

    1. Copy the leasing.ddl file located in the WL_HOME/server/db/oracle/920 directory to your database node.

    2. Connect to the database as the leasing user.

    3. Run the leasing.ddl script in SQL*Plus as follows:

      SQL> @copy_location/leasing.ddl;

12.15.2 Creating a Gridlink Data Source for leasing Using the Administration Console

To use the Oracle WebLogic Server Administration Console to create GridLink data source for the leasing table follow the instructions in section Section 14.3, "Creating a GridLink Data Source for Leasing Using the Administration Console."

12.15.3 Editing the Node Manager's Properties File

Edit the Node Manager properties file on the two nodes where the servers are running. The nodemanager.properties file is located in the following directory:

WL_HOME/common/nodemanager

Add the following properties to enable server migration to work properly:

  • Interface

    Interface=eth0

    This property specifies the interface name for the floating IP (eth0, for example).

    Note:

    Do not specify the sub interface, such as eth0:1 or eth0:2. This interface is to be used without the :0, or :1. The 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, or, eth2, eth3, ethn, depending on the number of interfaces configured.

  • NetMask

    NetMask=255.255.255.0

    This property specifies the net mask for the interface for the floating IP.

  • UseMACBroadcast

    UseMACBroadcast=true

    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 the output of Node Manager (the shell where the Node Manager is started) that these properties are in use. Otherwise, problems may occur during migration. The output should be similar to the following:

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

Note:

The following steps are not required if the server properties (start properties) have been set and Node Manager can start the servers remotely.

  1. If not done already, set the StartScriptEnabled property in the nodemanager.properties file to true. This is required to enable Node Manager to start the managed servers.

  2. Start Node Manager on Node 1 and Node 2 by running the startNodeManager.sh script, which is located in the WL_HOME/server/bin/ directory.

    Note:

    When running Node Manager from a shared storage installation, multiple nodes are started using the same nodemanager.properties file. However, each node may require different NetMask or Interface properties. In this case, specify individual parameters on a per-node basis using environment variables. For example, to use a different interface (eth3) in SOAHOSTn, use the Interface environment variable as follows: SOAHOSTn> export JAVA_OPTIONS=-DInterface=eth3 and start Node Manager after the variable has been set in the shell.

12.15.4 Setting Environment and Superuser Privileges for the wlsifconfig.sh Script

Set the environment and superuser privileges for the wlsifconfig.sh script.

Ensure that the PATH environment variable includes the files listed in Table 12-5.

Table 12-5 Required Files for the PATH Environment

File Directory Location

wlsifconfig.sh

 
ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration

wlscontrol.sh

 
WL_HOME/common/bin

nodemanager.domain

 
WL_HOME/common/nodemanager

Grant sudo privilege to the WebLogic user ('oracle') with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.

For security reasons, sudo should be restricted to the subset of commands required to run the wlsifconfig.sh script. For example, to set the environment and superuser privileges for the wlsifconfig.sh script.

Note:

Ask the system administrator for the sudo and system rights as appropriate to this step.

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.

To grant sudo privilege to the WebLogic user ('oracle') with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries:

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

12.15.5 Enabling Host Name Verification for Node Manager in the BAMHOSTn Nodes and the Administration Server

Enable host name verification certificates between Node Manager in the BAMHOSTn nodes and the Administration Server. To enable host name verification certificates, see Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1."

12.15.6 Configuring Server Migration Targets

To configure cluster migration targets, set the DataSourceForAutomaticMigration property to true.

To configure migration targets in a cluster:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page appears.

  3. Click the cluster for which you want to configure migration (BAM_Cluster) in the Name column of the table.

  4. Click the Migration tab.

  5. Click Lock & Edit.

  6. In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select BAMHOST1 and BAMHOST2.

  7. Select the data source to be used for automatic migration. In this case select the leasing data source.

  8. Click Save and Activate Changes.

  9. Set the candidate machines for server migration for WLS_BAM1 only. WLS_BAM2 does not use server migration:

    1. In Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.

    2. Select the server for which you want to configure migration.

    3. Click the Migration tab.

    4. In the Available field, located in the Migration Configuration section, select the machines to which to allow migration and click the right arrow. Select BAMHOST2 for WLS_BAM1.

    5. Select Automatic Server Migration Enabled and click Save.

      This enables the Node Manager to start a failed server on the target node automatically.

    6. Click Activate Changes.

    7. Restart the Administration Server and the WLS_BAM1 server.

      To restart the Administration Server, use the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1.".

Tip:

Click Customize this table in the Summary of Servers page, move Current Machine from the Available Window to the Chosen Window to view the machine on which the server is running. This is different from the configuration if the server is migrated automatically.

12.15.7 Testing Server Migration

To verify that Server Migration is working properly:

To test from Node 1:

  1. Kill the WLS_BAM1 managed server.

    BAMHOST1> 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:

    BAMHOST1> ps -ef | grep WLS_BAM1

  2. Watch the Node Manager console: you should see a message indicating that WLS_BAM1's floating IP has been disabled.

  3. Wait for the Node Manager to try a second restart of WLS_BAM1. Node Manager waits for a fence period of 30 seconds before trying this restart.

  4. Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally.

To test from Node 2:

  1. Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_BAM1on Node 1, Node Manager on Node 2 should prompt that the floating IP for WLS_BAM1 is being brought up and that the server is being restarted in this node.

  2. Access the Oracle BAM console using BAMHOST1VHN1 and soa.mycompany.com/OracleBAM.

To validate migration from the Administration Console:

  1. Log into the Administration Console.

  2. Click on Domain on the left console.

  3. Click the Monitoring tab and then on the Migration tab.

    The Migration Status table provides information on the status of the migration.

12.16 Applying Configuration Changes BAM components in a BAM Cluster

If you are using Oracle BAM in a clustered environment, you must make the changes you made in Oracle Enterprise Manager on one node to all nodes. In addition, consider the following when making configuration changes to BAM Server in a BAM Enterprise Deployment Topology:

Since you are using server migration, the BAM Server is moved to a different node's domain directory. You must pre-create the BAM Server configuration in the failover node. The BAM Server configuration files are located in the following directory:

DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config

In order to create the files in preparation for possible failovers, you can force a server migration and copy the files from the source node. For example, for BAM:

  1. Configure the driver for WLS_BAM1 in BAMHOST1.

  2. Force a failover of WLS_BAM1 to BAMHOST2. Verify the directory structure for the BAM Server in the failover node:

    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/oracle_bam-11.1.1/config

12.17 Backing Up the BAM Configuration

After you have verified that the extended domain is working, back up the domain configuration. This is a quick backup for the express purpose of immediate restore in case of failures in future procedures. Back up the configuration to the local disk. This backup can be discarded once you have completed the enterprise deployment. Once you have completed the enterprise deployment, you can initiate the regular deployment-specific backup and recovery process.

For information about backing up the environment, see "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide. For information about recovering your information, see "Recovering Your Environment" in the Oracle Fusion Middleware Administrator's Guide.

To back up the domain configuration:

  1. Back up the Web tier:

    1. Shut down the instance using opmnctl.

      ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

    2. Back up the Middleware Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

    3. Back up the Instance Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE

    4. Start the instance using opmnctl:

      ORACLE_BASE/admin/instance_name/bin/opmnctl startall

  2. Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or OS tools such as tar for cold backups if possible.

  3. Back up the Administration Server domain directory to save your domain configuration. The configuration files are located in the following directory:

    ORACLE_BASE/ admin/domain_name

    To back up the Administration Server:

    tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name