Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence
11g Release 1 (11.1.1)

Part Number E15722-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

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

8 Creating a Domain with the Administration Server and First Managed Server

This chapter describes how to create a domain with the Administration Server and the first Oracle Business Intelligence Managed Server using the Oracle Business Intelligence Configuration Assistant, Oracle WebLogic Server Administration Console, and Oracle Enterprise Manager Fusion Middleware Control. Later, you will scale out the domain to add additional components. This is addressed in later chapters in this document.

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 chapter contains the following topics:

8.1 Overview of Creating a Domain

Table 8-1 lists the steps for creating a WebLogic domain for Oracle Business Intelligence that contains the Administration Server and the first Managed Server, including post-configuration tasks.

Table 8-1 Steps for Creating a Domain for Oracle Business Intelligence

Step Description More Information

Create a WebLogic Domain

Run the Oracle Business Intelligence Configuration Assistant to create a WebLogic domain containing the Administration Server and the first Managed Server.

Section 8.2, "Creating a Domain and the bi_server1 Managed Server on APPHOST1"

Post-Configuration and Verification Tasks

Follow the instructions for post-configuration and validation tasks.

Section 8.3, "Post-Configuration and Verification Tasks"

Configure Oracle HTTP Server for the WebLogic Domain

Configure Oracle HTTP Server for the Administration Server and Managed Server in the WebLogic domain and validate the configuration.

Section 8.4, "Configuring Oracle HTTP Server for the WebLogic Domain"

Test Administration Server Failover

Follow the instructions to manually fail over the Administration Server from APPHOST1 to APPHOST2.

Section 8.5, "Manually Failing Over the Administration Server to APPHOST2"

Back Up the Installation

Back up the installation to the local disk.

Section 8.6, "Backing Up the Installation"


8.2 Creating a Domain and the bi_server1 Managed Server on APPHOST1

Run the Oracle Business Intelligence Configuration Assistant from the Oracle home directory to create a domain containing the Administration Server and the first Managed Server with Oracle Business Intelligence components.

  1. Ensure that the database where you installed the Business Intelligence Platform schemas is running. For an Oracle RAC database, it is recommended that you ensure that all instances are running, so that the validation check that is performed in later steps is more reliable.

  2. Change the directory to the location of the Configuration Assistant (created in Chapter 6, "Installing the Software for an Enterprise Deployment"):

    APPHOST1> cd ORACLE_HOME/bin
    
  3. Start the Configuration Assistant:

    APPHOST1> ./config.sh
    
  4. In the Welcome screen, click Next.

  5. In the Prerequisite Checks screen, verify that all checks complete successfully, and then click Next.

  6. The Create, Scale Out or Extend screen is displayed. In this screen, select Create New BI System, then enter the following:

    • User Name: weblogic

    • User Password: your_password

    • Domain Name: bifoundation_domain

    Click Next.

  7. In the Specify Installation Location screen, enter:

    • Middleware Home: ORACLE_BASE/product/fmw (dimmed)

    • Oracle Home: ORACLE_BASE/product/fmw/Oracle_BI1 (dimmed)

    • WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (dimmed)

    • Domain Home: ORACLE_BASE/admin/domain_name/aserver/domain_name

      The Domain Home must end with the domain name.

    • Instance Home: ORACLE_BASE/admin/instance1

    • Instance Name: instance1

    Click Next.

  8. In the Configure Components screen, select the following:

    • Oracle Business Intelligence

      • Business Intelligence Enterprise Edition

      • Business Intelligence Publisher

      • Real-Time Decisions

    Click Next.

  9. In the BIPLATFORM Schema screen, provide the following information:

    • Database Type: Oracle Database

    • Connect String: CUSTDBHOST1:1521:CUSTDB1^CUSTDBHOST2:1521:CUSTDB2@
      BIEDG.MYCOMPANY.COM

    • BIPLATFORM Schema Username: prefix_BIPLATFORM

    • BIPLATFORM Schema Password: your_password

    Click Next.

  10. In the MDS Schema screen, verify the information. For example:

    • Database Type: Oracle Database

    • Connect String: CUSTDBHOST1:1521:CUSTDB1^CUSTDBHOST2:1521:CUSTDB2@
      BIEDG.MYCOMPANY.COM

    • MDS Schema Username: prefix_MDS

    • MDS Password: your_password

    Click Next.

  11. In the Configure Ports screen, select one the following:

    • Auto Port Configuration

    • Specify Ports using Configuration File

    Click Next.

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

  13. In the Summary screen, click Configure.

  14. In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.

  15. In the Complete screen, click Finish.

Usually, Node Manager is started automatically when config.sh completes. If Node Manager is not running for some reason, run these commands to start it on APPHOST1:

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

8.3 Post-Configuration and Verification Tasks

After configuring the domain with the Oracle Business Intelligence Configuration Assistant, follow these instructions for post-configuration and verification.

This section includes the following topics:

8.3.1 Configuring JMS for Oracle BI Publisher

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.

  1. Log into the Administration Console.

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

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

  4. Click BipJmsStore and enter a directory that is located in the shared storage. This shared storage is accessible from both APPHOST1 and APPHOST2:

    ORACLE_BASE/admin/domain_name/bi_cluster/jms

  5. Click Save and then click Activate Changes.

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

8.3.2 Creating boot.properties for the Administration Server on APPHOST1

Create a boot.properties file for the Administration Server on APPHOST1. This file enables the Administration Server to start without prompting you for the administrator username and password.

  1. Go to the following directory:

    ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security
    
  2. In this directory, create a file called boot.properties using a text editor and enter the following lines in the file:

    username=Admin_Username
    password=Admin_Password
    

    Note:

    When you start the Administration Server, the username and password entries in the file get encrypted. You start the Administration Server in Section 8.3.3, "Starting the Administration Server on APPHOST1." For security reasons, you want to minimize the time the entries in the file are left unencrypted. After you edit the file, you should start the server as soon as possible so that the entries get encrypted.

  3. Save the file and close the editor.

8.3.3 Starting the Administration Server on APPHOST1

The Administration Server is started and stopped using Node Manager. However, the first start of the Administration Server with Node Manager requires changing the default username and password that the Configuration Assistant set for Node Manager. Follow these steps to start the Administration Server using Node Manager:

  1. Use the Administration Console to update the Node Manager credentials:

    1. Open a Web browser and go to http://APPHOST1:7001/console.

    2. Log in as the administrator.

    3. In the Change Center, click Lock & Edit to enable configuration changes.

    4. Click domain_name, then Security, then General, and then expand the Advanced options at the bottom.

    5. Enter a new username for Node Manager, or make a note of the existing one and update the Node Manager password.

    6. Click Save.

    7. Click Activate Changes.

  2. Stop the Administration Server process 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

    • Log in to the Administration Console and click Servers under the Environment heading, then click the Control tab. Select AdminServer(admin) and click Shutdown.

  3. Stop and restart Node Manager and enable dynamic registration, as follows:

    1. Stop the running NodeManager process.

    2. Restart Node Manager and enable dynamic registration using the following commands:

      APPHOST1> cd WL_HOME/server/bin 
      APPHOST1> export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
      APPHOST1> ./startNodeManager.sh
      

      Note:

      It is important that you set -DDomainRegistrationEnabled=true whenever you start a Node Manager which must manage the Administration Server. If there is no Administration Server on this computer, and if this computer is not an Administration Server failover node, then Node Manager can be started as follows:

      APPHOST1> ./startNodeManager.sh
      
  4. Start the Oracle WebLogic Scripting Tool (WLST) and connect to Node Manager with nmconnect and the credentials set in step 1, and start the Administration Server using nmstart:

    APPHOST1> cd ORACLE_COMMON_HOME/common/bin
    APPHOST1> ./wlst.sh
    

    In the WLST shell, execute the following command:

    wls:/offline>nmConnect('Admin_User','Admin_Pasword', 'APPHOST1',
    'node_manager_port','domain_name','Domain_Home')
    
    wls:/nm/domain_name> nmStart('AdminServer')
    

    For example:

    wls:/offline>nmConnect('weblogic', 'my_password', 'APPHOST1' , '9556',
    'bifoundation_domain' ,'/u01/app/oracle/admin/bifoundation_domain/aserver/
    bifoundation_domain')
    
    wls:/nm/bifoundation_domain> nmStart('AdminServer')
    

Note:

APPHOST1 is the address of the node where the domain was created, not the listen address of the Administration Server. Also, the username and password are only used to authenticate connections between Node Manager and clients. They are independent from the server admin ID and password, and are stored in the ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager/nm_password.properties file.

8.3.4 Enabling Administration Server High Availability

The Oracle WebLogic Server Administration Server is a singleton application, so it cannot be deployed in an active-active configuration. By default, the Administration Server is only available on the first installed node, and for this enterprise topology, it is available only on APPHOST1. If this node becomes unavailable, then the Administration Console and Fusion Middleware Control also become unavailable. To avoid this scenario, the Administration Server and the applications deployed to it must be enabled for high availability. The enterprise deployment architecture in this guide calls for the deploying the Administration Server on a disk shared between APPHOST1 and APPHOST2.

The process described in this guide initially deploys the Administration Server and the bi_server1 Managed Server on the shared disk mounted on APPHOST1, and then manually migrates the bi_server1 Managed Server domain information to the local file system. This process is necessary to overcome certain design constraints in the Oracle Universal Installer.

This section contains the following topics:

8.3.4.1 Enabling ADMINVHN on APPHOST1

The Administration Server must be configured to listen on a virtual IP Address to enable it to seamlessly failover from one host to another. In case of a failure, the Administration Server, along with the virtual IP Address, can be migrated from one host to another.

However, before the Administration Server can be configured to listen on a virtual IP Address, one of the network interface cards on the host running the Administration Server must be configured to listen on this virtual IP Address. The steps to enable a virtual IP Address are completely dependent on the operating system.

Follow the steps in this section to enable a virtual IP Address on APPHOST1. In a UNIX environment, the command must be run as the root user:

  1. On APPHOST1, run the ifconfig command to get the value of the netmask. In a UNIX environment, run this command as the root user. For example:

    [root@APPHOST1 ~] # /sbin/ifconfig
    eth0     Link encap:Ethernet  HWaddr 00:11:43:D7:5B:06
         inet addr:139.185.140.51  Bcast:139.185.140.255  Mask:255.255.255.0
         inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0
         TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:4036851474 (3.7 GiB)  TX bytes:2770209798 (2.5 GiB)
         Base address:0xecc0 Memory:dfae0000-dfb00000
    
  2. On APPHOST1, bind the virtual IP Address to the network interface card using ifconfig. In a UNIX environment, run this command as the root user. Use a netmask value that was obtained in Step 1.

    The syntax and usage for the ifconfig command is as follows:

    /sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask
    

    For example:

    /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
    
  3. Update the routing table using arping. In a UNIX environment, run this command as the root user.

    /sbin/arping -q -U -c 3 -I networkCardInterface Virtual_IP_Address
    

    For example:

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

See also Section 3.4.1, "Enabling Virtual IPs for the Managed Servers" for information about enabling VIP2 and VIP3 for the Managed Servers on APPHOST1 and APPHOST2.

8.3.4.2 Create a Machine for the Administration Server

Create a new machine and assign the Administration Server to the new machine using the Administration Console.

  1. Log in to the Administration Console.

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

  3. In the Environment section of the Home page, click Machines.

  4. On the Summary of Machines page, select the Machine that is associated with the Administration Server from under the Machines table and click Clone. For example: APPHOST1.MYCOMPANY.COM.

  5. On the Clone a Machine page, enter the Name of the Machine under the Machine Identity section and click OK. For example, enter ADMINHOST as the machine name.

  6. On the Summary of Machines page, click the newly created Machine link.

  7. On the Settings page for the ADMINHOST machine, select the Servers tab.

  8. Click Add under the Servers table.

  9. On the Add a Server to Machine page, choose Select an existing server, and associate it with this machine option.

  10. Choose the AdminServer from the drop-down menu.

  11. Click Finish to associate the Administration Server with the Machine.

  12. In the Change Center, click Activate Changes.

8.3.4.3 Enabling the Administration Server to Listen on the Virtual IP Address

Ensure that you have performed the steps described in Section 8.3.4.1, "Enabling ADMINVHN on APPHOST1" before setting the Administration Server listen address.

Perform these steps to set the Administration Server listen address:

  1. Log in to the Administration Console.

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

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

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

  5. Select AdminServer(admin) in the Names column of the table. The Setting page for AdminServer(admin) is displayed.

  6. Set the Listen Address to ADMINVHN.

  7. Click Save.

  8. Click Activate Changes.

  9. The changes will not take effect until the Administration Server is restarted. Follow these steps to restart the Administration Server:

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

    2. Select AdminServer(admin) in the table and then click Shutdown.

    3. Start the Administration Server again from the command line, as follows:

      APPHOST1> cd ORACLE_COMMON_HOME/common/bin
      APPHOST1> ./wlst.sh
      wls:/offline> nmConnect
      ('Admin_User','Admin_Password','APPHOST1','5556','domain_name','DOMAIN home')
      wls:/nm/domain_name> nmStart ('AdminServer')
      

8.3.4.4 Creating a Separate Domain Directory for the bi_server1 Managed Server

Use the pack and unpack commands to separate the domain directory used by the Administration Server from the domain directory used by the bi_server1 Managed Server in APPHOST1.

  1. Stop the Administration Server and bi_Server1 Managed Server, as follows:

    1. Log in to the Administration Console.

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

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

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

    5. Select AdminServer(admin) and bi_server1 in the table and then click Shutdown.

  2. Run the pack command on APPHOST1 to create a template pack using the following command. Make sure to pass managed=true to pack just the bi_server1 Managed Server domain information.

    APPHOST1> cd ORACLE_HOME/common/bin
    APPHOST1> ./pack.sh -managed=true -domain=path_to_installer_created_domain
    -template=templateName.jar -template_name=templateName
    

    For example:

    APPHOST1> cd ORACLE_HOME/common/bin
    APPHOST1> ./pack.sh -managed=true -domain= 
    ORACLE_BASE/admin/bifoundation_domain/aserver/bifoundation_domain
    -template=/tmp/managedServer.jar -template_name=ManagedServer_Template
    
  3. Run the unpack command on APPHOST1 to unpack the template to the domain directory of the Managed Server using the following command:

    APPHOST1> cd ORACLE_HOME/common/bin
    APPHOST1> ./unpack.sh -domain=path_to_domain_on_LocalFileSystem 
    -template=templateName.jar -app_dir=path_to_applications_dir_on_LocalFileSystem
    

    For example:

    APPHOST1> cd ORACLE_HOME/common/bin
    APPHOST1>./unpack.sh -domain=
    ORACLE_BASE/admin/bifoundation_domain/mserver/bifoundation_domain
    -template=/tmp/managedServer.jar -app_dir=
    ORACLE_BASE/admin/bifoundation_domain/mserver/applications
    
  4. Start the Oracle WebLogic Scripting Tool (WLST) and connect to Node Manager with nmconnect and the credentials set in step 2, and start the Administration Server using nmstart:

    APPHOST1> cd ORACLE_COMMON_HOME/common/bin
    APPHOST1> ./wlst.sh
    

    In the WLST shell, execute the following command:

    wls:/offline>nmConnect('Admin_User','Admin_Pasword','APPHOST1',
    'node_manager_port','domain_name','Domain_Home')
    
    wls:/nm/domain_name> nmStart('AdminServer')
    

    For example:

    wls:/offline>nmConnect('weblogic', 'my_password', 'APPHOST1' , '9556',
    'bifoundation_domain' ,'/u01/app/oracle/admin/bifoundation_domain/
    aserver/bifoundation_domain')
    
    wls:/nm/bifoundation_domain> nmStart('AdminServer')
    
  5. Start the bi_server1 Managed Server on APPHOST1, as follows (ensure that Node Manager is up and running):

    1. Log in to the Administration Console.

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

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

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

    5. Select bi_server1 in the table and then click Start.

8.3.4.5 Enabling Fusion Middleware Control Failover

To enable Fusion Middleware Control failover, copy the em.ear file from the MW_HOME/user_projects/applications/bifoundation_domain directory to the equivalent directory on all nodes where Administration Server HA might be performed. In some cases, you might need to create the MW_HOME/user_projects/applications/bifoundation_domain directory on the other nodes.

8.3.5 Validating the Administration Server

Perform these steps to ensure that the Administration Server is properly configured:

  1. Open a Web browser and go to http://ADMINVHN:7001/console.

  2. Log in as the administrator.

  3. Check that you can access Fusion Middleware Control at:

    http://ADMINVHN:7001/em

  4. Log in to Fusion Middleware Control with the username and password you specified in Section 8.3.2, "Creating boot.properties for the Administration Server on APPHOST1."

8.3.6 Setting the Listen Address for bi_server1 Managed Server

Ensure that you have performed the steps described in Section 3.4.1, "Enabling Virtual IPs for the Managed Servers" before setting the bi_server1 listen address.

Perform these steps to set the listen address for the Managed Server:

  1. Log in to the Administration Console.

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

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

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

  5. Select bi_server1 in the Names column of the table. The Setting page for bi_server1 is displayed.

  6. Set the Listen Address to APPHOST1VHN1.

  7. Click Save.

  8. Click Activate Changes.

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

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

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

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

  10. Restart the Oracle Business Intelligence system components, as follows:

    cd ORACLE_BASE/admin/instances/instance1/bin
    ./opmnctl stopall
    ./opmnctl startall
    

8.3.7 Updating the Oracle BI Publisher Scheduler Configuration

Follow the steps in this section to update the WebLogic JNDI URL for the Oracle BI Publisher Scheduler.

To update the Oracle BI Publisher Scheduler configuration:

  1. Log in to Oracle BI Publisher at the following URL:

    http://APPHOST1VHN1:9704/xmlpserver

  2. Click the Administration link.

  3. Click Scheduler Configuration under System Maintenance. The Scheduler Configuration screen is displayed.

  4. Update the WebLogic JNDI URL under JMS Configuration, as follows:

    cluster:t3://bi_cluster

  5. Click Test JMS.

    You should receive a confirmation message that JMS tested successfully.

  6. Click Apply. The changes are sent to the cluster to be applied at run time.

  7. Check the Scheduler status from the Scheduler Diagnostics tab.

8.3.8 Disabling Host Name Verification for the bi_server1 Managed Server

This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 10, "Setting Up Node Manager for an Enterprise Deployment"). If you have not configured the server certificates, you will receive errors when managing the different Oracle WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again after the EDG topology configuration is complete as described in Chapter 10, "Setting Up Node Manager for an Enterprise Deployment."

Perform these steps to disable host name verification:

  1. Log in to the Administration Console.

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

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

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

  5. Select bi_server1 in the Names column of the table. The settings page for the server is displayed.

  6. Open the SSL tab.

  7. Expand the Advanced section of the page.

  8. Set Hostname Verification to 'None'.

  9. Click Save.

  10. Click Activate Changes.

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

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

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

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

  12. Restart the Oracle Business Intelligence system components, as follows:

    cd ORACLE_BASE/admin/instance1/bin
    ./opmnctl stopall
    ./opmnctl startall
    

8.3.9 Configuring Oracle BI Composer

Oracle BI Composer (BI Composer) is an optional component in Oracle Business Intelligence that enables you to create, edit, or view analyses using wizard instead of the Analysis editor.

You can configure BI Composer using the ORACLE_HOME/bicomposer/install/configureComposer.py script. This is a Python script that can be used to configure BI Composer in the Managed Servers. The script runs in WLST online mode and expects the Administration Server to be up and running.

Note:

After configuring BI Composer using the configureComposer.py script, you must restart all affected Managed Servers for the configuration to take effect.

To configure BI Composer:

  1. Run the configureComposer.py script using the command-line Oracle WebLogic Scripting Tool (WLST), as follows:

    APPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh
    ORACLE_HOME/bicomposer/install/configureComposer.py admin_server_domain_home
    Admin_Server_host Admin_Server_port admin_user
    

    For example:

    APPHOST1> ORACLE_COMMON_HOME/common/bin/wlst.sh 
    ORACLE_HOME/bicomposer/install/configureComposer.py
    /u01/app/oracle/admin/bifoundation_domain/aserver/bifoundation_domain ADMINVHN
    7001 weblogic
    

    Enter the password for the administrator user when prompted.

    Note:

    The configureComposer.py script stops the Administration Server. The Administration Server and all affected Managed Servers and system components must be restarted for the configuration to take effect, as described in the next steps.

  2. Start the Administration Server and bi_server1 Managed Server on APPHOST1.

  3. Start the Oracle Business Intelligence system components on APPHOST1.

  4. Verify the BI Composer configuration, as follows:

    1. Log in to the Administration Console.

    2. Expand Deployments in the Domain Structure window.

    3. Verify that the BI Composer application and shared libraries are visible as follows:

      bicomposer (11.1.1)

      oracle.bi.composer (11.1.1,11.1.1)

      oracle.bi.jbips (11.1.1,11.1.1)

    BI Composer is now available in Oracle Business Intelligence. For information about how BI Composer is displayed, see "Availability of BI Composer in Oracle BI Enterprise Edition" in the Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition.

8.3.10 Validating Oracle Business Intelligence on APPHOST1

Access the following URLs:

  • Access http://APPHOST1VHN1:9704/analytics to verify the status of bi_server1.

  • Access http://APPHOST1VHN1:9704/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://APPHOST1VHN1:9704/xmlpserver to verify the status of the Oracle BI Publisher application.

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

  • Access http://APPHOST1VHN1:9704/bioffice/about.jsp to verify the status of the Oracle BI for Microsoft Office application.

  • Access http://APPHOST1VHN1:9704/bicomposer to verify the status of the Oracle BI Composer application. You only need to verify this URL if BI Composer has been configured.

8.4 Configuring Oracle HTTP Server for the WebLogic Domain

This section covers how to configure Oracle HTTP Server for the WebLogic domain that contains the Administration Server and the bi_server1 Managed Server.

This section contains the following topics:

8.4.1 Configuring Oracle HTTP Server for the Administration Server

To enable Oracle HTTP Server to route to the Administration Server, you must set the corresponding mount points in your HTTP server configuration:

  1. On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_INSTANCE/config/OHS/component_name/mod_wl_ohs.conf file:

    # The admin URLs should only be accessible via the admin virtual host
    
    NameVirtualHost *:7777
    <VirtualHost *:7777>
        ServerName admin.mycompany.com:80
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    
    # Admin Server and EM
    <Location /console>
        SetHandler weblogic-handler
        WebLogicHost ADMINVHN
        WeblogicPort 7001
    </Location>
    
    <Location /consolehelp>
        SetHandler weblogic-handler
        WebLogicHost ADMINVHN
        WeblogicPort 7001
    </Location>
    
    <Location /em>
        SetHandler weblogic-handler
        WebLogicHost ADMINVHN
        WeblogicPort 7001
    </Location>
    </VirtualHost>
    

    Note that the value for the VirtualHost parameter depends on how the LBR virtual host was set up. You might need to use a different value than the one shown, such as 80.

  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
    

8.4.2 Configuring Oracle HTTP Server for the bi_servern Managed Servers

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

  1. On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/admin/instance_name/config/OHS/component_name/mod_wl_ohs.conf file. Note that you only need to include entries related to /bicomposer if BI Composer has been configured.

    #redirect browser requests that omit document/dir
    RedirectMatch 301 /analytics$ /analytics/
    RedirectMatch 301 /bimiddleware$ /bimiddleware/
    RedirectMatch 301 /xmlpserver$ /xmlpserver/
    RedirectMatch 301 /ui$ /ui/
    RedirectMatch 301 /bisearch$ /bisearch/
    RedirectMatch 301 /mapviewer$ /mapviewer/
    RedirectMatch 301 /bicontent$ /bicontent/
    # only if BI Composer has been configured. 
    #RedirectMatch 301 /bicomposer$ /bicomposer/
    
    # WSM-PM
    <Location /wsm-pm>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    # BIEE Analytics
    <Location /analytics>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    <Location /analytics-ws>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    <Location /bimiddleware>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    <Location /bicontent>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    # MapViewer
    <Location /mapviewer>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location> 
    
    # BI Publisher
    <Location /xmlpserver>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    # Oracle RTD
    <Location /ui>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    <Location /rtis>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
     
    <Location /schema>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
     
    <Location /ws>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    # BI Office
    <Location /bioffice>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    <Location /biofficeclient>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    # BI Search
    <Location /bisearch>
       SetHandler weblogic-handler
       WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
       WLProxySSL ON
       WLProxySSLPassThrough ON
    </Location>
    
    # BI Composer
    # only if BI Composer has been configured.
    #<Location /bicomposer>
    #   SetHandler weblogic-handler
    #   WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704
    #   WLProxySSL ON
    #   WLProxySSLPassThrough ON
    #</Location>
    

    Note:

    Add other resources as appropriate (such as analyticsRes or ActionSamples to support functionality in SampleApp.rpd).

  2. Make sure the httpd.conf file located in the same directory as the mod_wl_ohs file contains the following lines:

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

    Note:

    Values such as bi.mycompany.com:443, admin.mycompany.com:80 and you@your.address that are noted in this document serve as examples only. Enter values based on the actual environment.

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

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.

8.4.3 Turning On the WebLogic Plug-In Enabled Flag

For security purposes, and because the load balancer terminates SSL requests (Oracle HTTP Server routes the requests as non-SSL to WebLogic Server), after SSL is configured for the load balancer, turn on the WebLogic Plugin Enabled flag for the domain. To do this, follow these steps:

  1. Log in to the Administration Console.

  2. Click the domain name in the navigation tree on the left.

  3. Click the Web Applications tab.

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

  5. Select WebLogic Plugin Enabled.

  6. Click Save, then click Activate Changes.

8.4.4 Registering Oracle HTTP Server with Oracle WebLogic Server

For Fusion Middleware Control to be able to manage and monitor Oracle HTTP Server instances, they must be registered with the domain. To do this, you must register Oracle HTTP Server with Oracle WebLogic Server using the following command:

WEBHOST1> cd ORACLE_INSTANCE/bin
WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic

You must also run this command from WEBHOST2 for OHS2.

Note:

After registering Oracle HTTP Server, it should appear as a manageable target in Fusion Middleware Control. To verify this, log in to Fusion Middleware Control. The WebTier item in the navigation tree should show that Oracle HTTP Server has been registered.

8.4.5 Setting the Frontend URL for the Administration Console

The Administration Console application tracks changes made to ports, channels and security using the console. When changes made through the console are activated, the console validates its current listen address, port, and protocol. If the listen address, port, and protocol are still valid, the console redirects the HTTP request replacing the host and port information with the Administration Server's listen address and port. When the Administration Console is accessed using a load balancing router (LBR), it is required to change the Administration Server's frontend URL so that the user's Web browser is redirected to the appropriate LBR address. To do this, follow these steps:

  1. Log in to the Administration Console.

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

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

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

  5. Select AdminServer(admin) in the Names column of the table. The settings page for AdminServer(admin) is displayed.

  6. Click the Protocols tab.

  7. Click the HTTP tab.

  8. Set the Frontend Host field to admin.mycompany.com (your LBR address).

  9. Set the Frontend HTTP Port to 80.

  10. Click Save, then click Activate Changes.

To eliminate redirections, it is recommended that you disable the Administration Console's "Follow changes" feature. To do this, log in to the Administration Console and click Preferences, and then Shared Preferences. Clear the Follow Configuration Changes option, and then click Save.

8.4.6 Validating Access Through Oracle HTTP Server

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.

This section contains the following topics:

8.4.6.1 Validating the Administration Console and Fusion Middleware Control

Validate the Administration Console and Fusion Middleware Control through both Oracle HTTP Server instances using the following URLs:

  • http://WEBHOSTn:7777/console

  • http://WEBHOSTn:7777/em

    Note:

    After setting the frontend URL to the LBR address, the access to the console through the WEBHOSTn addresses will be redirected by the console to the frontend URL, thus validating the correct configuration of both Oracle HTTP Server and the LBR device.

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

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

For information on configuring system access through the load balancer, see Section 3.3, "Configuring the Load Balancer."

8.4.6.2 Validating bi_cluster

Validate bi_cluster through Oracle HTTP Server using the following URLs (for both WEBHOST1 and WEBHOST2):

  • http://WEBHOSTn:7777/analytics

  • http://WEBHOSTn:7777/mapviewer

  • http://WEBHOSTn:7777/xmlpserver

  • http://WEBHOSTn:7777/ui

  • http://WEBHOSTn:7777/wsm-pm

  • http://WEBHOSTn:7777/bioffice/about.jsp

  • http://WEBHOSTn:7777/bicomposer

    You only need to validate the /bicomposer URL if BI Composer has been configured.

For information on configuring system access through the load balancer, see Section 3.3, "Configuring the Load Balancer."

8.5 Manually Failing Over the Administration Server to APPHOST2

In case a node fails, you can fail over the Administration Server to another node. This section describes how to fail over the Administration Server from APPHOST1 to APPHOST2, and contains the following topics:

8.5.1 Assumptions and Procedure

Note the following assumptions:

  • The Administration Server is configured to listen on ADMINVHN, and not on ANY address.

  • The Administration Server is failed over from APPHOST1 to APPHOST2, and the two nodes have these IP addresses:

    • APPHOST1: 100.200.140.165

    • APPHOST2: 100.200.140.205

    • ADMINVHN: 100.200.140.206. This is the VIP where the Administration Server is running, assigned to ethX:Y, available in APPHOST1 and APPHOST2.

  • The domain directory where the administration server is running in APPHOST1 is on a shared storage and is mounted also from APPHOST2.

  • Oracle WebLogic Server and Oracle Fusion Middleware components have been installed in APPHOST2 (that is, the same paths for ORACLE_HOME and MW_HOME that exist on APPHOST1 are also available on APPHOST2).

Procedure

The following procedure shows how to fail over the Administration Server to a different node (APPHOST2):

  1. Stop the Administration Server, if it is running.

  2. Migrate the IP address to the second node:

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

      APPHOST1> /sbin/ifconfig ethX:Y down
      
    2. Run the following command on APPHOST2:

      APPHOST2> /sbin/ifconfig interface:index IP_address netmask netmask
      

      For example:

      APPHOST2> /sbin/ifconfig eth0:1 10.200.140.206 netmask 255.255.255.0
      

      Note:

      Make sure that the netmask and interface to be used match the available network configuration in APPHOST2.

    3. Update the routing tables using arping. For example:

      APPHOST2> /sbin/arping -b -A -c 3 -I eth0 100.200.140.206
      
  3. Start Node Manager in APPHOST2, using the instructions given in Step 3 of Section 8.3.3, "Starting the Administration Server on APPHOST1."

  4. Start the Administration Server on APPHOST2, using the instructions given in Step 4 of Section 8.3.3, "Starting the Administration Server on APPHOST1."

  5. Test that you can access the Administration Server on APPHOST2, as follows:

    1. Ensure that you can access the Administration Console at http://ADMINVHN:7001/console.

    2. Check that you can access and verify the status of components in Fusion Middleware Control at http://ADMINVHN:7001/em.

8.5.2 Validating Access to APPHOST2 Through Oracle HTTP Server

Perform the steps described in Section 8.4.6, "Validating Access Through Oracle HTTP Server" to check that you can access the Administration Server when it is running on APPHOST2.

8.5.3 Failing the Administration Server Back to APPHOST1

This step checks that you can fail back the Administration Server; that is, stop it on APPHOST2 and run it on APPHOST1 again. To do this, migrate ADMINVHN back to the APPHOST1 node as follows:

  1. Make sure the Administration Server is not running.

  2. Run the following command as root on APPHOST2.

    APPHOST2> /sbin/ifconfig ethX:Y down
    
  3. Run the following command on APPHOST1:

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

    For example:

    APPHOST1> /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
    

    Note:

    Make sure that the netmask and interface you use matches the available network configuration in APPHOST1.

  4. Update the routing tables using arping. For example:

    APPHOST1> /sbin/arping -b -A -c 3 -I ethZ 100.200.140.206
    
  5. Start the Administration Server again on APPHOST1, as described in Step 4 of Section 8.3.3, "Starting the Administration Server on APPHOST1."

  6. Test that you can access the Administration Console at http://ADMINVHN:7001/console.

  7. Check that you can access and verify the status of components in Fusion Middleware Control at http://ADMINVHN:7001/em.

If you encounter problems with Administration Server failover, see Section 13.8.2, "Administration Server Fails to Start After a Manual Failover" for additional information.

8.6 Backing Up the Installation

After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded after the enterprise deployment setup is complete. At that point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in that guide. For information on how to recover components, see the "Recovering Components" and "Recovering After Loss of Component Host" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" section in the guide. Also refer to the Oracle Database Backup and Recovery User's Guide for information on database backup.

Perform these steps to back up the installation at this point:

  1. Back up the Web tier:

    1. Shut down the instance using opmnctl:

      WEBHOSTn> ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
      
    2. Back up the Middleware home on the Web tier using the following command (as root):

      WEBHOSTn> tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
      
    3. Back up the Oracle instance on the Web tier using the following command:

      WEBHOSTn> tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE
      
    4. Start the instance using opmnctl:

      WEBHOSTn> cd ORACLE_BASE/admin/instance_name/bin
      WEBHOSTn> opmnctl startall
      
  2. Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or operating system tools such as tar for cold backups if possible.

  3. Back up the BI Instance in the application tier, as follows:

    1. Shut down the instance using opmnctl:

      APPHOST1> ORACLE_INSTANCE/bin/opmnctl stopall
      
    2. Back up the Middleware home on the application tier using the following command:

      APPHOST1> tar -cvpf BACKUP_LOCATION/bi.tar MW_HOME
      
    3. Back up the Oracle instance on the application tier using the following command:

      APPHOST1> tar -cvpf BACKUP_LOCATION/bi_instance_name.tar ORACLE_INSTANCE
      
    4. Start the instance using opmnctl:

      APPHOST1> ORACLE_INSTANCE/bin/opmnctl startall
      
  4. Back up the Administration Server and Managed Server domain directories to save your domain configuration. The configuration files all exist in the ORACLE_BASE/admin/ domain_name directory. Run the following command to create the backup:

    APPHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name