9 Extending the Domain to Include Oracle SOA Suite Components

This chapter describes how to use the Oracle Fusion Middleware Configuration Wizard to extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment," to include Oracle SOA Suite components and Oracle WSM Policy Manager. You can extend the resulting domain to add other Fusion Middleware components, as described in the next chapters. It is assumed that a SOA Oracle home (binaries) has already been installed and is available from SOAHOST1 and SOAHOST2 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 SOA Suite components.

Note:

Before starting the setup process, read the release notes for additional installation and deployment information. They are available on the Oracle Fusion Middleware Documentation Library at http://docs.oracle.com/cd/E23943_01/relnotes.htm.

This chapter contains the following sections:

9.1 Overview of Extending the Domain for Oracle SOA Suite Components

Extend the WebLogic domain to include Oracle SOA Suite components. Table 9-1 lists the steps for configuring Oracle SOA Suite and other tasks required for extending the domain for Oracle SOA Suite components.

Table 9-1 Steps for Extending the Domain for Oracle SOA Suite Components

Step Description More Information

Prepare for extending the domain for Oracle SOA Suite components

Enable a VIP mapping for each of the host names, and synchronize the system clocks for the SOA WebLogic Server cluster

Section 9.2, "Enabling SOAHOST1VHN1 on SOAHOST1 and SOAHOST2VHN1 on SOAHOST2"

Extend the domain for Oracle SOA Suite components

Extend the WebLogic domain you created in Chapter 8, "Creating a Domain for an Enterprise Deployment."

Section 9.3, "Extending the Domain for Oracle SOA Suite Components Using the Configuration Wizard"

Configure Oracle Coherence for deploying composites

Configure Oracle Coherence to use unicast communication for deploying composites.

Section 9.4, "Configuring Oracle Coherence for Deploying Composites"

Complete post-configuration and verification tasks

Follow these instructions for post-configuration and validation tasks.

Section 9.5, "Completing Post-Configuration and Verification Tasks"

Verify the configuration of GridLink data sources and Oracle Notification Service (ONS)

Follow these instructions to verify that the configuration of GridLink data sources and ONS is correct.

Section 9.5.3, "Validating GridLink Data Sources"

Propagate the Domain Configuration to SOAHOST2

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory.

Section 9.5.6, "Propagating the Domain Configuration to SOAHOST2"

Configure Oracle HTTP Server with the extended domain

Configure the Oracle HTTP Server with the managed servers, validate access, set the frontend HTTP host and port, and set the WebLogic Server cluster address for SOA_Cluster.

Section 9.7, "Configuring Oracle HTTP Server for the WLS_SOA Managed Servers"

Configure a default persistence store

Configure a default persistence store for transaction recovery.

Section 9.10, "Configuring a Default Persistence Store for Transaction Recovery"

Configure Oracle adapters

Enable high availability for Oracle JCA Adapter for Files and Oracle JCA Adapter for FTP, enable high availability for the Oracle JCA Adapter for JMS, and scale the Oracle JCA Adapter for Database.

Section 9.12, "Scaling the Oracle Database Adapter"

Back up the Oracle SOA Suite configuration

Back up the newly extended domain configuration.

Section 9.15, "Backing Up the Installation"

9.2 Enabling SOAHOST1VHN1 on SOAHOST1 and SOAHOST2VHN1 on SOAHOST2

This step is required for server migration of WLS_SOA1 and WLS_SOA2. You will associate the WLS_SOA1 and WLS_SOA2 servers with virtual host names (SOAHOST1VHN1 and SOAHOST2VHN1). Check that these virtual host names are enabled by DNS or /etc/hosts resolution in your system and that they map to the appropriate VIPs (VIP2 and VIP3).

To enable the virtual IP, run the ifconfig command as root:

/sbin/ifconfig interface:index IP_address netmask netmask
/sbin/arping -q -U -c 3 -I interface IP_address

For example:

/sbin/ifconfig ethX:Y 100.200.140.205 netmask 255.255.255.0

Enable your network to register the new location of the virtual IP, for example:

/sbin/arping -q -U -c 3 -I ethX 100.200.140.205

Validate that the address is available by pinging it from another node, for example:

/bin/ping 100.200.140.205

Note:

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

9.3 Extending the Domain for Oracle SOA Suite Components Using the Configuration Wizard

Use the Oracle Fusion Middleware Configuration Wizard to extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment" to support Oracle Web Services Manager and Oracle SOA Suite components.

Note:

If you have not backed up the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment," back up the current domain before extending it for Oracle SOA Suite components. You may use the backup to recover in case any errors are made in the domain extension. See "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide.

To extend the domain using the Configuration Wizard:

  1. Ensure that the database where you installed the repository is running.

    For Oracle RAC databases, Oracle recommends that all instances are running, so that the validation check later on becomes more reliable.

  2. Shut down all managed servers in the domain.

  3. On SOAHOST1, change the directory to the location of the Oracle Fusion Middleware Configuration Wizard. This is within the Oracle Common home directory (domain extensions are run from the node where the Administration Server resides).

    cd ORACLE_COMMON_HOME/common/bin

  4. Start the Configuration Wizard:

    ./config.sh

  5. In the Welcome screen, select Extend an Existing WebLogic Domain, and click Next.

  6. In the WebLogic Domain Directory screen, select the WebLogic domain directory (ORACLE_BASE/admin/domain_name/aserver/domain_name), and click Next.

  7. In the Select Extension Source screen, which Figure 9-1 shows, do the following:

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

    2. Select these products:

      Oracle SOA Suite - 11.1.1.0 [soa]

      Oracle WSM Policy Manager - 11.1.1.0 [oracle_common] (automatically selected with Oracle SOA Suite)

      The following products should already be selected and grayed out. They were selected when you created the domain (Section 8.3).

      Basic WebLogic Server Domain - 10.3.6.0 [wlserver_10.3]

      Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

      Oracle JRF - 11.1.1.0 [oracle_common]

      Figure 9-1 Select Extension Source Screen for Oracle SOA Suite

      Description of Figure 9-1 follows
      Description of "Figure 9-1 Select Extension Source Screen for Oracle SOA Suite"

    3. Click Next.

  8. If you get a Conflict Detected message that Oracle JRF is already defined in the domain, select the Keep Existing Component option and click OK.

  9. In the Configure JDBC Component Schema screen, which Figure 9-2 shows, do the following:

    1. Select the rows SOA Infrastructure, User Messaging Service, OWSM MDS Schema, and SOA MDS Schema.

    2. For the RAC configuration, you can select Convert to GridLink or Convert to RAC multi data source (described in Appendix A, "Using Multi Data Sources with Oracle RAC"). For the instructions given here, select Convert to GridLink.

      After you select a RAC configuration, all selected schemas are grayed.

      Figure 9-2 Configure JDBC Component Schema Screen for Oracle SOA Suite

      Description of Figure 9-2 follows
      Description of "Figure 9-2 Configure JDBC Component Schema Screen for Oracle SOA Suite"

    3. Click Next.

  10. In the Configure GridLink RAC Component Schema screen, which Figure 9-3 shows, do the following:

    1. Select only the SOA Infrastructure row.

      Figure 9-3 Configure GridLink RAC Component Schema Screen for Oracle SOA Suite

      Description of Figure 9-3 follows
      Description of "Figure 9-3 Configure GridLink RAC Component Schema Screen for Oracle SOA Suite"

    2. Enter values for the following fields, specifying the connection information for the GridLink RAC database that was seeded through RCU:

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

      • Service Name: Enter the service name of the Oracle RAC database in lowercase letters, followed by the domain name; for example, wccedg.mycompany.com.

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

        This book uses DEV as the prefix of user names for the database schemas.

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

      • Select Enable FAN.

      • Enable SSL: Leave this option deselected.

        If you select SSL to enable Oracle Notification Service (ONS) notification encryption, provide the appropriate Wallet File and Wallet Password details.

      • Service listener: Enter the Oracle Single Client Access Name (SCAN) address and port for the Oracle RAC database being used. The protocol should be TCP.

        Oracle recommends that you use a SCAN address to specify the Service Listener (and OSN Host) so you do not need to update a GridLink data source containing a SCAN address if you add or remove Oracle RAC nodes. To determine the SCAN address, query the remote_listener parameter in the database:

        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 here also the SCAN address for the RAC database and the ONS remote port, as reported by the database:

        [orcl@CUSTDBHOST2 ~]$ 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)

    3. Select each data source, one at a time, and enter appropriate values for the user names and passwords.

    4. Ensure that all values are correct for all schemas (SOA Infrastructure, User Messaging Service, OWSM MDS Schema, and SOA MDS Schema), and then click Next.

      Note:

      Oracle recommends using the database used for identity management (see Chapter 15, "Integrating with Oracle Identity Management") to store the Oracle WSM policies. It is therefore expected that you will use the Oracle Identity Management database information that has been seeded through RCU (as recommended in Chapter 3, "Preparing the Network for an Enterprise Deployment") to store the WSM metadata and that this Oracle Identity Management database information will be used in this screen for the OWSM MDS schemas. (This database connection information will be different from the one used for the rest of the Oracle SOA Suite schemas.)

  11. In the Test JDBC Component Schema screen, (Figure 9-4), select each schema, and then click Test Connections.

    The Connection Results Log displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen, correct your entries, and then retry the test.

    Figure 9-4 Test JDBC Component Schema Screen

    Description of Figure 9-4 follows
    Description of "Figure 9-4 Test JDBC Component Schema Screen"

    Click Next when all the connections are successful.

  12. In the Select Optional Configuration screen, select the following options:

    • JMS Distributed Destination

    • Managed Servers, Clusters and Machines

    • Deployment and Services

    • JMS File Store

    Click Next.

  13. In the Select JMS Distributed Destination Type screen, do the following:

    • Select UDD from the drop-down list for UMSJMSystemResource.

    • Select UDD from the drop-down list for SOAJMSModule.

    If an override warning appears, click OK to acknowledge it.

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

    A server called soa_server1 is created automatically. Rename this to WLS_SOA1 and add a new server called WLS_SOA2. Give these servers the attributes listed in Table 9-2. Do not modify the other servers that are shown in this screen; leave them as they are.

    Table 9-2 Managed Servers

    Name Listen Address Listen Port SSL Listen Port SSL Enabled

    WLS_SOA1

    SOAHOST1VHN1

    8001

    n/a

    No

    WLS_SOA2

    SOAHOST2VHN1

    8001

    n/a

    No

    Click Next.

  15. In the Configure Clusters screen, add the clusters as listed in Table 9-3.

    Table 9-3 Clusters

    Name Cluster Messaging Mode Multicast Address Multicast Port Cluster Address

    SOA_Cluster

    unicast

    n/a

    n/a

    SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

    Click Next.

    Note:

    For asynch request/response interactions over direct binding, the SOA composites must provide their JNDI provider URL for the invoked service to look up the beans for callback.

    If soa-infra config properties are not specified, but the WebLogic Server Cluster address is specified, the cluster address from the JNDI provider URL is used. This cluster address can be either a single DNS name that maps to the IP addresses of the clustered servers or a comma-separated list of server ip:port. Alternatively, the soa-infra config property JndiProviderURL/SecureJndiProviderURL can be used for the same purpose if explicitly set by users.

  16. In the Assign Servers to Clusters screen, assign servers to clusters as follows:

    • SOA_Cluster:

      • WLS_SOA1

      • WLS_SOA2

    Click Next.

  17. In the Configure Machines screen, delete the LocalMachine that appears by default and open the Unix Machine tab. You should add the SOAHOST1 and SOAHOST2 machines and eventually have the following entries:

    Table 9-4 Machines

    Name Node Manager Listen Address

    SOAHOST1

    SOAHOST1

    SOAHOST2

    SOAHOST2

    ADMINVHN

    localhost

    Do not modify the other assignments that are shown in this screen; leave them as they are. Please note that the machine names do not need to be valid host names or listen addresses; they are just unique identifiers of Node Manager locations.

    Click Next.

  18. In the Assign Servers to Machines screen, assign servers to machines as follows:

    • ADMINVHN:

      • AdminServer

    • SOAHOST1:

      • WLS_SOA1

    • SOAHOST2:

      • WLS_SOA2

    Click Next.

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

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

    • WSM-PM should be targeted only to SOA_Cluster.

    • The oracle.rules#*, oracle.sdp.*, and oracle.soa.* deployments should be targeted only to SOA_Cluster.

    Click Next.

  20. In the Target Services to Clusters or Servers screen, click Next.

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

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

    Click Next.

  22. In the Configuration Summary screen, click Extend.

    The domain is extended to include the Oracle SOA Suite components.

  23. In the Extending Domain screen, click Done.

  24. Restart the Administration Server for these changes to take effect.

9.4 Configuring Oracle Coherence for Deploying Composites

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

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

Note:

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

9.4.1 Enabling Communication for Deployment Using Unicast Communication

Specify the nodes using the tangosol.coherence.wkan system property, where n is a number between 1 and 9. You can specify up to 9 nodes as Well Known Addresses, but can have more than 9 nodes in the cluster. Start the numbering at 1. This numbering must be sequential and must not contain gaps. In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost system property. This local host name should be the virtual host name used by the Oracle SOA Suite server as the listener addresses (SOAHOST1VHN1 and SOAHOST2VHN1). Set this property by adding the -Dtangosol.coherence.localhost parameter to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab (Figure 9-5).

Tip:

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

Note:

SOAHOST1VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA1 is listening (in SOAHOST1). SOAHOST2VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA2 is listening (in SOAHOST2).

Figure 9-5 Setting the Host Name Using the Start Server Tab of the WebLogic Server Administration Console

Description of Figure 9-5 follows
Description of "Figure 9-5 Setting the Host Name Using the Start Server Tab of the WebLogic Server Administration Console"

9.4.2 Specifying the Host Name

To specify the host name used by Oracle Coherence:

  1. Log in to the WebLogic Server Administration Console.

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

  3. Click Servers.

  4. On the Summary of Servers page, click the name of the server (WLS_SOA1 or WLS_SOA2), which are represented as hyperlinks in the Name column of the table.

  5. On the settings page for the selected server, click Lock & Edit.

  6. Open the Configuration tab and then the Server Start tab.

  7. Enter the following for WLS_SOA1 and WLS_SOA2 in the Arguments field.

    For WLS_SOA1, enter the following (on a single line, without a carriage return):

    -Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1

    For WLS_SOA2, enter the following (on a single line, without a carriage return):

    -Dtangosol.coherence.wka1=SOAHOST1VHN1-Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1

    Note:

    All arguments above are entered in one single line; that is, do not insert new lines in the Java arguments field in the Administration Console. Also, do not copy and paste the preceding text to your Administration Console's arguments text field. This may result in extraneous characters being inserted in the Java arguments. The text should not contain text or characters other than the ones shown in the preceding entry.

    The Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying a different port (for example, 8089) using the -Dtangosol.coherence.wkan.port and -Dtangosol.coherence.localport startup parameters, for example:

    • WLS_SOA1 (enter the following into the Arguments field on a single line, without a carriage return):

      -Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.localport=8089

    • WLS_SOA2 (enter the following into the Arguments field on a single line, without a carriage return):

      -Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
-Dtangosol.coherence.localport=8089

  8. Click Save and Activate Changes.

Note:

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

Note:

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

9.5 Completing Post-Configuration and Verification Tasks

After extending the domain with the Configuration Wizard and configuring Oracle Coherence, follow these instructions for post-configuration and validation.

This section includes the following topics:

9.5.1 Disabling Host Name Verification for the WLS_SOAn 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. Therefore, you must disable the host name verification for the WLS_SOAn managed server to avoid errors when managing the different WebLogic Servers. You enable host name verification again once the Enterprise Deployment topology configuration is complete. See Section 13.3, "Enabling Host Name Verification Certificates for Node Manager" for more information.

To disable host name verification:

  1. Log in to WebLogic Server Administration Console.

  2. Click Lock & Edit.

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

  4. Click Servers.

  5. On the Summary of Servers page, select WLS_SOA1 in the Names column of the table.

  6. On the settings page for the server, open the SSL tab.

  7. Expand the Advanced section of the page.

  8. Set host name verification to None.

  9. Click Save.

  10. Repeat steps 4 through 8 for the WLS_SOA2 managed server.

  11. Save and activate the changes.

  12. This change requires a restart of the Administration Server and Node Manager.

    1. To restart the Administration Server see Section 8.4.4, "Starting the Administration Server on SOAHOST1."

    2. To restart Node Manager on SOAHOST1, see Section 9.5.2, "Restarting Node Manager on SOAHOST1."

9.5.2 Restarting Node Manager on SOAHOST1

Use the startNodeManager.sh script to restart Node Manager.

To restart Node Manager on SOAHOST1:

  1. Stop Node Manager by stopping the process associated with it.

    If it is running in the foreground in a shell, simply use Ctrl+C.

    If it is running in the background in the shell, find the associate process and use the kill command to stop it. For example:

    ps -ef | grep NodeManager
orcl   9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh

kill -9 9139

  2. Start Node Manager:

    ./startNodeManager.sh

9.5.3 Validating GridLink Data Sources

After you finish configuring WLS_SOA1 and WLS_SOA2 and start the Administration Server and managed servers, verify that every GridLink data source you created is correctly configured and that the Oracle Notification Service (ONS) setup is correct for each data source on each managed server.

To verify the configuration of a GridLink data source for Oracle SOA Suite:

  1. Log in to the Weblogic Server Administration Console.

  2. In the Domain Structure tree, expand Services, then click Data Sources.

  3. Click the name of a GridLink data source that was created.

  4. Click the Monitoring tab, and click the name of one of the servers.

  5. Click the Testing tab (Figure 9-6), select one of the servers, and click Test Data Source.

    Figure 9-6 Testing a GridLink Data Source for Oracle SOA Suite

    Description of Figure 9-6 follows
    Description of "Figure 9-6 Testing a GridLink Data Source for Oracle SOA Suite"

    The test should be successful if the configuration is correct.

  6. Repeat the test for every WebLogic Server instance that uses the GridLink data source.

To verify the configuration of ONS for a GridLink data source for Oracle SOA Suite:

  1. Log in to the Weblogic Server Administration Console.

  2. In the Domain Structure tree, expand Services, then click Data Sources.

  3. Click the name of a GridLink data source that was created.

  4. Click the Monitoring tab, and click the name of one of the servers.

  5. Click the ONS tab and then the Testing tab (Figure 9-7).

  6. Select a server, and click Test ONS.

    Figure 9-7 Testing the ONS Configuration for Oracle SOA Suite

    Description of Figure 9-7 follows
    Description of "Figure 9-7 Testing the ONS Configuration for Oracle SOA Suite"

    The test should be successful if the configuration is correct. If the ONS test fails, verify that the ONS service is running in the Oracle RAC database nodes:

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

  7. Repeat the ONS test for every WebLogic Server instance that uses the GridLink data source.

9.5.4 Propagating the Domain Changes to the Managed Server Domain Directory

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory.

To propagate the start scripts and classpath configuration:

  1. Create a copy of the managed server domain directory and the managed server applications directory.

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

    cd ORACLE_COMMON_HOME/common/bin

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

  3. Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server, using the following command:

    ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -overwrite_domain=true -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

    Note:

    The -overwrite_domain option in the unpack command, allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and EAR files in the managed server domain directory, they must be restored after this unpack operation.

9.5.5 Starting and Validating the WLS_SOA1 Managed Server

To start the WLS_SOA1 managed server and check that it is configured correctly:

  1. Start the WLS_SOA1 managed server using the WebLogic Server Administration Console as follows:

    1. Access the Administration Console at http://ADMINVHN:7001/console.

      ADMINVHN is the virtual host name that maps to the virtual IP where the Administration Server is listening (in SOAHOST1).

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

    3. Choose Servers.

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

    5. Select WLS_SOA1 and then click Start.

  2. Verify that the server status is reported as Running in the Administration Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors. See Section 16.11, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology" for possible causes.

  3. Access the following URLs:

    • Access http://SOAHOST1VHN1:8001/soa-infra to verify the status of WLS_SOA1.

    • Access http://SOAHOST1VHN1:8001/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 store opens.The configuration is incorrect if no policies or assertion templates appear.

    • Access http://SOAHOST1VHN1:8001/integration/worklistapp to verify the status of the worklist application.

9.5.6 Propagating the Domain Configuration to SOAHOST2

After completing the configuration of SOAHOST1, propagate the configuration to SOAHOST2 using the unpack utility, and then validate the propagated configuration.

This section covers the following topics:

9.5.6.1 Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility

Propagate the domain you just configured to SOAHOST2 using the unpack utility.

To propagate the domain configuration:

  1. Run the following commands on SOAHOST1 to copy the template file created in the previous step to SOAHOST2:

    cd ORACLE_BASE/product/fmw/oracle_common/common/bin

scp edgdomaintemplateSOA.jar oracle@SOAHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

  2. Run the unpack command on SOAHOST2 to unpack the propagated template.

    Note:

    Run unpack from the ORACLE_COMMON_HOME/common/bin directory, not from WL_HOME/common/bin.

    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications

Note:

The ORACLE_BASE/admin/domain_name/mserver directory must exist before you run unpack. In addition, the ORACLE_BASE/admin/domain_name/mserver/applications directory must be empty.

9.5.6.2 Starting and Validating the WLS_SOA2 Managed Server

To start the WLS_SOA2 managed server and check that it is configured correctly:

  1. Start the WLS_SOA2 managed server using the WebLogic Server Administration Console, as follows:

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

    2. Choose Servers.

    3. On the Summary of Servers page, open the Control tab.

    4. Select WLS_SOA2 and then click Start.

  2. Verify that the server status is reported as Running in the Administration Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors. See Section 16.11, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology" for possible causes.

  3. Access the following URLs:

    • Access http://SOAHOST2VHN1:8001/soa-infra to verify the status of WLS_SOA2.

    • Access http://SOAHOST2VHN1:8001/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 store opens.

      Note:

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

    • Access http://SOAHOST2VHN1:8001/integration/worklistapp to verify the status of the worklist application.

9.6 Configuring the Java Object Cache for Oracle Web Services Manager

The Java Object Cache (JOC) should be configured among all the servers running Oracle Web Services Manager (Oracle WSM). This local cache is provided to increase the performance of Oracle WSM. The Java Object Cache can be configured using the MW_HOME/oracle_common/bin/configure-joc.py script. This is a Python script, which can be used to configure JOC in the managed servers. The script runs in WLST online mode and expects the Administration Server to be up and running.

For the configuration of JOC ports for Oracle products, Oracle recommends using ports in the 9988 to 9998 range.

Note:

After you configure the Java Object Cache using the WLST commands or configure-joc.py script, all affected managed servers should be restarted for the configurations to take effect.

To configure the Java Object Cache for Oracle WSM:

  1. Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST); for example:

    MW_HOME/oracle_common/common/bin/wlst.sh
$ connect()

    Enter the server URL, Oracle Weblogic Administration user name and password when prompted.

  2. After connecting to the Administration Server using WLST, start the script using the execfile command, for example:

    wls:/domain_name/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")

Specifically, for enterprise deployment environments, the first cluster option in step 2 should be used. Here is a walkthrough for using configure-joc.py for EDG environments (see below for the script input parameters):

Execfile("MW_HOME/oracle_common/bin/configure-joc.py").
Enter Hostnames (eg host1,host2) : SOAHOST1VHN1,SOAHOST2VHN1
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : SOA_Cluster
.
Enter Discover Port : 9991
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

You can also configure the Java Object Cache (JOC) using the HA Power Tools tab in the Oracle WebLogic Administration Console as described in the Oracle Fusion Middleware High Availability Guide.

Script Input Parameters

The input parameters are prompted by the script. The script can be used to perform the following JOC configurations:

  • Configure JOC for all specified managed servers for a given cluster. Enter y when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the managed servers for the given cluster and configures the JOC. The discover port is common for the entire JOC configuration across the cluster. For example:

    Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : SOA_Cluster
Enter Discover Port : 9991

  • Configure JOC for all specified managed servers. Enter n when the script prompts whether you want to specify a cluster name, and also specify the managed server and discover port, when prompted. For example:

    Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_SOA1:9991, WLS_SOA21:9991) : WLS_SOA1:9999,WLS_SOA2:9999

    This example configures JOC only for the specified managed servers (that is, WLS_SOA1 and WLS_SOA2). The discover port is specified with the managed server (for example, WLS_SOA1:2222).

  • Exclude JOC configuration for some managed servers. The script allows you to specify the list of managed servers for which the JOC configuration DistributeMode will be set to false. Enter y when the script prompts whether you want to exclude any servers from JOC configuration, and enter the managed server names to be excluded, when prompted. For example:

    Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_SOA1,WLS_SOA2

  • Disable the distribution mode for all managed servers. The script allows you to disable the distribution to all the managed servers for a specified cluster. Specify false when the script prompts for the distribution mode. By default, the distribution mode is set to true.

9.7 Configuring Oracle HTTP Server for the WLS_SOA Managed Servers

To enable Oracle HTTP Server to route to SOA_Cluster, which contain the WLS_SOAn 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:

    # WSM-PM
<Location /wsm-pm>
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA soa-infra app
<Location /soa-infra>
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

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

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

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

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

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

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

  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://wcc.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>

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

    Note:

    Values such as wcc.mycompany.com:443, admin.mycompany.com:80 and you@youraddress 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:

    ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohsX

    For WEBHOST1, use ohs1 for ias-component and for WEBHOST2 use ohs2.

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. Please note that 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 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 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.

9.8 Setting the Frontend HTTP Host and Port

You must set the frontend HTTP host and port for the Oracle WebLogic Server cluster hosting the Oracle SOA Suite servers:

  1. Log in to WebLogic Server Administration Console.

  2. Go to the Change Center section and click Lock & Edit.

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

  4. Click Clusters.

  5. On the Summary of Servers page, select SOA_Cluster.

  6. Open the HTTP tab.

  7. Set the following values:

    • Frontend Host: soainternal.mycompany.com

    • Frontend HTTP Port: 80

  8. Click Save.

  9. Click Activate Changes in the Change Center section of the Administration Console.

  10. Restart the servers to make the frontend host directive in the cluster take effect.

9.9 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. See Section 16.11, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology" for possible causes.

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

  • http://WEBHOSTn:7777/soa-infra

  • http://WEBHOSTn:7777/integration/worklistapp

  • http://WEBHOSTn:7777/sdpmessaging/userprefs-ui

  • http://WEBHOSTn:7777/soa/composer

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

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

Note:

After the registering Oracle HTTP Server as described in Section 8.5.3, "Registering Oracle HTTP Server with WebLogic Server," Oracle HTTP Server should appear as a manageable target in the Oracle Enterprise Manager console. To verify this, log in to the Oracle Enterprise Manager console. The WebTier item in the navigation tree should show that Oracle HTTP Server has been registered.

9.10 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. Oracle 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 managed 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:

  1. Log in to the WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Environment node and then click the Servers node.

  3. On the Summary of Servers page, click the name of the server (represented as a hyperlink) in the Name column of the table. The settings page for the selected server opens and defaults to the Configuration tab.

  4. Open the Services tab within the Configuration tab (not the top-level Services tab).

  5. Click Lock & Edit.

  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/soa_cluster_name/tlogs

  7. Save and activate the changes.

  8. Restart the WLS_SOA1 and WLS_SOA2 managed servers.

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 WLS_SOA1 and WLS_SOA2 must be able to access this directory.

9.11 Enabling High Availability for Oracle File and FTP Adapters

Note:

this step is optional and applies only to those deployments that require adapter support for the BPEL processes that are invoked by.

The Oracle File and FTP Adapters enable a BPEL process or an Oracle Mediator to read and write files on local file systems and on remote file systems through FTP (File Transfer Protocol).These adapters support high availability for an active-active topology with Oracle BPEL Process Manager and Oracle Mediator service engines for both inbound and outbound operations. To make Oracle File and FTP Adapters highly available for outbound operations, use the database mutex locking operation as described in "High Availability in Outbound Operations" in Oracle Fusion Middleware User's Guide for Technology Adapters. The database mutex locking operation enables these adapters to ensure that multiple references do not overwrite one another if they write to the same directory.

Note:

The File Adapter picks up a file from the inbound directory, processes it, and then outputs a file to the output directory. Because the File Adapter is non-transactional, files can be processed twice. As a result, it is possible to get duplicate files when there is failover in the Oracle RAC back end or in the Oracle SOA Suite managed servers.

Using the Database Mutex Locking Operation

To make an outbound Oracle File or FTP Adapter service highly available using database table as a coordinator, you must modify the Oracle File Adapter deployment descriptor for the connection-instance corresponding to eis/HAFileAdapter in the Oracle WebLogic Server console.

Note:

You must increase global transaction timeouts if you use database as a coordinator.

To use the Database Mutex locking operation:

  1. Log in to the Oracle WebLogic Server console. To access the console, navigate to http://server_name:port_number/console.

  2. Click Deployments in the left pane for Domain Structure.

  3. Click FileAdapter under Summary of Deployments on the right pane.

  4. Open the Configuration tab.

  5. Open the Outbound Connection Pools tab, and expand javax.resource.cci.ConnectionFactory to see the configured connection factories.

  6. Click eis/HAFileAdapter. The Outbound Connection Properties screen for the connection factory corresponding to high availability opens. The connection factory properties are displayed as shown in Figure 9-8.

    Figure 9-8 Oracle WebLogic Server Console - Settings for javax.resource.cci.ConnectionFactory Page

    Description of Figure 9-8 follows
    Description of "Figure 9-8 Oracle WebLogic Server Console - Settings for javax.resource.cci.ConnectionFactory Page"

  7. Click Lock & Edit. After this, the property value column becomes editable (you can select any of the rows under Property Value and modify its value).

    The new parameters in connection factory for Oracle File and FTP Adapters follow:

    • controlDir: Set it to the directory structure where you want the control files to be stored. You must set it to a shared location if multiple WebLogic Server instances run in a cluster. Structure the directory for shared storage as follows:

      ORACLE_BASE/admin/domain_name/cluster_name/fadapter

    • inboundDataSource: Set the value to jdbc/SOADataSource. This is the data source where the schemas corresponding to high availability are pre-created. The pre-created schemas can be found under ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql. If you want to create the schemas elsewhere, use this script. You must set the inboundDataSource property accordingly if you choose a different schema.

    • outboundDataSource: Set the value to jdbc/SOADataSource. This is the data source where the schemas corresponding to high availability are pre-created. The pre-created schemas can be found under ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql. If you want to create the schemas elsewhere, use this script. You must set the outboundDataSource property if you choose to do so.

    • outboundLockTypeForWrite: Set the value to oracle if you are using Oracle Database. By default, the Oracle File and FTP Adapters use an in-memory mutex to lock outbound write operations. You must choose from the following values for synchronizing write operations:

      • memory: The Oracle File and FTP Adapters use an in-memory mutex to synchronize access to the file system.

      • oracle: The adapter uses Oracle Database sequence.

      • db: The adapter uses a pre-created database table (FILEADAPTER_MUTEX) as the locking mechanism. You must use this option only if you are using a schema other than the Oracle Database schema.

      • user-defined: The adapter uses a user-defined mutex. To configure the user-defined mutex, you must implement the mutex interface (oracle.tip.adapter.file.Mutex) and then configure a new binding-property with the name oracle.tip.adapter.file.mutex and value as the fully qualified class name for the mutex for the outbound reference.

    Note:

    The parameters available for FTP Adapters are slightly different than for the connection factory, but from a high-availability standpoint, just setting the control directory to a shared storage location is what matters.

  8. Click Save after you update the properties.

  9. On the Save Deployment Plan page, enter a shared storage location for the deployment plan. The directory structure is as follows:

    ORACLE_BASE/admin/domain_name/cluster_name/dp/Plan.xml

  10. Click Save and Activate.

  11. Configure BPEL Process or Mediator Scenario to use the connection factory as shown in the following example:

    <adapter-config name="FlatStructureOut" adapter="File Adapter"
 xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
  <connection-factory location="eis/HAFileAdapter" adapterRef=""/>
  <endpoint-interaction portType="Write_ptt" operation="Write">
<interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">
      <property../>
      <property../>
    </interaction-spec>
  </endpoint-interaction>
</adapter-config>

    Note:

    The location attribute is set to eis/HAFileAdapter for the connection factory.

9.12 Scaling the Oracle Database Adapter

Note:

this step is optional and applies only to those deployments that require adapter support for the BPEL processes that are invoked by.

If you are using Logical Delete polling and you set MarkReservedValue, skip locking is not used. Formerly, the best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL Process Manager or Oracle Mediator nodes was essentially using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize. However, with the introduction of skip locking in Oracle Fusion Middleware 11g Release 1 (11.1.2.0), that approach has now been superseded. If you were using this approach previously, you can simply remove (in db.jca) or clear (on the Logical Delete wizard page) the MarkReservedValue attribute, and you will automatically get skip locking.

The benefits of using skip locking over a reserved value include:

  • Skip locking scales better in a cluster and under load.

  • All work is in one transaction (as opposed to update/reserve, then commit, then select in a new transaction), so the risk of facing non-recoverable situations in high-availability environments is minimized.

  • No unique MarkReservedValue needs to be specified. Previously, for this to work, you had to configure a complex variable, such as R${weblogic.Name-2}-${IP-2}-${instance}.

For more information, see "Scalability" and "Polling Strategies" in Oracle Fusion Middleware User's Guide for Technology Adapters.

9.13 Configuring Node Manager for the WLS_SOA Managed Servers

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 13, "Setting Up Node Manager" for further details. The procedures in that chapter must be performed twice using the following information:

Run Host Name (HOST) Virtual IP (VIP) Server Name (WLS_SERVER)

Run 1:

SOAHOST1

SOAHOST1VHN1

WLS_SOA1

Run 2:

SOAHOST2

SOAHOST2VHN1

WLS_SOA2

9.14 Configuring Server Migration for the WLS_SOA Managed Servers

Server migration is required for proper failover of the Oracle SOA Suite components in the event of failure in any of the SOAHOST1 and SOAHOST2 nodes. See Chapter 14, "Configuring Server Migration for an Enterprise Deployment" for further details. For Oracle SOA Suite, use the following values for the variables in that chapter:

  • Server names:

    • WLS_SERVER1: WLS_SOA1

    • WLS_SERVER2: WLS_SOA2

  • Host names:

    • HOST1: SOAHOST1

    • HOST2: SOAHOST2

  • Cluster name:

    • CLUSTER: SOA_Cluster

9.15 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 once 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 "Recovery of Components" and "Recovery After Loss of Component" 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 Guide for information on database backup.

To back up the installation at this point:

  1. Back up the web tier on WEBHOST1:

    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 Oracle instance on the web tier using the following command:

      tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

    4. Start the instance using opmnctl:

      cd 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 operating system tools such as tar for cold backups if possible.

  3. 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 on SOAHOST1 to create the backup:

    tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name