9 Extending the Domain for SOA Components

This chapter describes how to use the Configuration Wizard to extend the domain to include SOA components. You created in the domain in Chapter 8, "Creating a Domain for an Enterprise Deployment."

Note:

Before starting the setup process, read the Oracle Fusion Middleware Release Notes for additional installation and deployment information.

Note:

Follow the steps in this chapter only if you want to run SOA components on SOAHOST1 and SOAHOST2. If you do not want to run SOA components in your WebCenter Portal topology, you can skip this chapter.

This chapter contains the following sections:

9.1 Overview of Extending the Domain for SOA Components

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

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

Step Description More Information

Prepare for extending the Domain for SOA Components

Enable a VIP mapping for each of the hostnames.

Section 9.2.1, "Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2"

Extend the Domain for SOA Components

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

Section 9.3, "Extending the Domain for SOA Components using the Configuration Wizard"

Configure Oracle Coherence for Deploying Composites

Configure Oracle Coherence in order to use unicast communication for deploying composites.

Section 9.4, "Configuring Oracle Coherence for Deploying Composites"

Post-Configuration and Verification Tasks

Follow these instructions for post-configuration and validation tasks.

Section 9.5, "Post-Configuration and Verification Tasks"

Propagate the Domain Configuration to SOAHOST1

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

Section 9.5.4, "Propagating the Domain Changes to the Managed Server Domain Directory"

Configure the 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 WLS Cluster address for the SOA_Cluster.

Section 9.7, "Configuring Oracle HTTP Server with the Extended Domain"

Configure a Default Persistence Store

Configure a default persistence store for transaction recovery.

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

Configure Oracle Adapters

Enable high availability for Oracle File and FTP Adapters, enable high availability for Oracle JMS Adapters, and scale the Oracle Database Adapter.

Section 9.9, "Configuring Oracle Adapters"

Back Up the SOA Configuration

Back up the newly extended domain configuration.

Section 9.10, "Backing Up the SOA Configuration"


9.2 Preparing to Extend the Domain for Oracle SOA Components

Before you run the Configuration Wizard to extend the domain, enable a VIP mapping for each of the hostnames on the two SOA machines

This section includes the following topics:

9.2.1 Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2

The Oracle WebCenter Portal domain uses virtual hostnames as the listen addresses for the Oracle SOA Suite managed servers. If you have not previously done so, you must enable a virtual IP mapping for each of these hostnames on the two SOA Machines, (VIP2 on SOAHOST1 and VIP3 on SOAHOST2), and correctly resolve the virtual hostnames in the network system used by the topology (either by DNS Server or /etc/hosts resolution).

To enable the virtual IPs, follow the steps described in Section 3.5, "Enabling Virtual IP Addresses for an Enterprise Deployment"if you have yet completed this procedure. These virtual IPs and VHNs are required to enable server migration for the Oracle SOA Suite servers.You can configure server migration for the SOA system later for high availability purposes. For more information about configuring server migration, see, Chapter 14, "Configuring Server Migration for an Enterprise Deployment".

9.3 Extending the Domain for SOA Components using the Configuration Wizard

Use the Configuration Wizard to extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment" to contain SOA components.

In this section we assume that the SOA deployment uses the same database service (wcpedg.mycompany.com) as the WebCenter Portal deployment. However, a deployment may choose to use a different database service specifically for SOA such as soaedg.mycompany.com.

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 SOA 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. Change directory to the location of the Configuration Wizard. This is within the SOA home directory on SOAHOST1.

    Oracle recommends having all database instances up.

    cd ORACLE_BASE/fmw/soa
    
  2. Start the Configuration Wizard.

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

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

    ORACLE_BASE/admin/domain_name/aserver/domain_name
    

    Click Next.

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

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

    2. Select the following products:

      • Oracle SOA Suite 11.1.1.0

      The following products should already be selected, and grayed out. They were selected when you created the domain in Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."

      • Basic WebLogic Server Domain

      • Oracle Enterprise Manager

      • Oracle WSM Policy Manager

      • Oracle JRF

    3. Click Next.

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

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

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

    2. For RAC configuration for component schemas, select Convert to GridLink.

      For the RAC configuration, you can select Convert to GridLink or Convert to RAC multi data source. The latter option is described in Appendix A, "Using Multi Data Sources with Oracle RAC")

    3. Click Next.

  8. In the Configure GridLink RAC Component Schema screen (Figure 9-1):

    Figure 9-1 Configure GridLink RAC Component Schema

    Description of Figure 9-1 follows
    Description of "Figure 9-1 Configure GridLink RAC Component Schema"

    1. Select SOA Infrastructure, User Messaging Service, and SOA MDS Schema in the table.

    2. Enter values for the following fields, specifying the connect information for the Oracle RAC database that was seeded with RCU.

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

      • Service Name: Enter the service name of the database in lowercase letters, followed by the domain name. For example, wcpedg.mycompany.com.

      • Enable FAN: Select the option.

      • Enable SSL: Deselect this option.

        If you select SSL, to enable Oracle Notification Service (ONS) notification encryption, provide 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 SCAN addresses to specify the Service Listener (and OSN Host) so you do not need to update a GridLink data source containing SCAN addresses 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 database versions that do not support SCAN:

        • For Oracle Database 11g Release 1 (11.1), enter the Virtual IP and port of each database's instance listener, for example:

          custdbhost1-vip.mycompany.com (Port 1521)

          and

          custdbhost2-vip.mycompany.com (Port 1521)

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

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

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

        Note:

        For Oracle Database 11g Release 1 (11.1), enter the host name and port for the database's ONS service. For example:

        custdbhost1.mycompany.com (Port 6200)

        and

        custdbhost2.mycompany.com (Port 6200)

    3. Select SOA Infrastructure only, and enter username and password for this database schema:

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

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

    4. Repeat step c) for User Messaging Service and SOA MDS Schema.

    5. When the values are correct for all SOA schemas (SOA Infrastructure, User Messaging Service, and SOA MDS Schema), click Next.

  9. In the Test JDBC Data Sources screen, confirm that all connections are successful.

    The connections are tested automatically. The Status column displays the results. If all connections are not successful, click Previous to return to the previous screen and correct your entries.

    Click Next when all the connections are successful.

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

    • JMS Distributed Destinations

    • Managed Servers, Clusters, and Machines

    • Deployments and Services

    • JMS File Store

    Click Next.

  11. In the Select JMS Distributed Destination Type screen, ensure that ALL JMS system resources are configured to be UDD. This is the default.

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

    A server called soa_server1 is created automatically.

    1. Select the automatically created server and click Rename to change the name to WLS_SOA1.

    2. Click Add to add another new server and enter WLS_SOA2 as the server name.

    3. Give servers WLS_SOA1 and WLS_SOA2 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

    WLS_WSM1

    SOAHOST1

    7010

    n/a

    No

    WLS_WSM2

    SOAHOST2

    7010

    n/a

    No


    Click Next.

  13. In the Configure Clusters screen, add the following clusters:

    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

    WSM-PM_Cluster

    unicast

    n/a

    n/a

    Leave it empty.


    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 a single DNS name which maps to the clustered servers' IP addresses 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.

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

    • SOA_Cluster:

      • WLS_SOA1

      • WLS_SOA2

    • WSM-PM_Cluster:

      • WLS_WSM1

      • WLS_WSM2

    Click Next.

  15. In the Configure Machines screen, delete the LocalMachine that appears by default and click the Unix Machine tab.

    The following entries appear (listed in Table 9-4):

    Table 9-4 Machines

    Name Node Manager Listen Address

    SOAHOST1

    SOAHOST1

    SOAHOST2

    SOAHOST2

    ADMINHOST

    localhost


    Leave all other fields to their default values.

    Click Next.

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

    • ADMINHOST:

      • AdminServer

    • SOAHOST1:

      • WLS_SOA1

      • WLS_WSM1

    • SOAHOST2:

      • WLS_SOA2

      • WLS_WSM2

    Click Next.

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

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

    • Target the oracle.sdp.*, and oracle.soa.* libraries only to SOA_Cluster.

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

    • Target the wsm-pm application to WSM-PM_Cluster.

      (If you plan to deploy Oracle Web Services Manager to the SOA_Cluster, target the wsm-pm application to SOA_Cluster as well.)

    Click Next.

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

    • Target mds-owsm to both WSM-PM_Cluster and AdminServer.

    Click Next.

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

  20. In the Configuration Summary screen click Extend.

    Note:

    Click OK to dismiss the warning dialog about the domain configuration ports conflicting with the host ports. This warning appears because of the existing WSM-PM installation.

  21. In the Extending Domain screen, click Done.

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

9.4 Configuring Oracle Coherence for Deploying Composites

Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication in SOA 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 SOA 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 SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA 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.wka<n> system property, where <n> is a number between 1 and 9. You can specify up to nine nodes as Well Known Addresses, but you can have more than nine 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 SOA server as the listener addresses (SOAHOST1VHN1 and SOAHOST2VHN1). Set this property by adding the -Dtangosol.coherence.localhost parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab (Figure 9-2).

Tip:

To guarantee high availability during deployments of SOA 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 listening (in SOAHOST1). SOAHOST2VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA2 is listening (in SOAHOST2).

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

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

9.4.2 Specifying the Host Name Used by Oracle Coherence

Use the Administration Console to specify a host name used by Oracle Coherence.

To add the host name used by Oracle Coherence:

  1. Log into the Oracle WebLogic Server Administration Console.

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

  3. Click Servers. The Summary of Servers page appears.

  4. Click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in Name column of the table. The settings page for the selected server appears.

  5. Click Lock & Edit.

  6. Click the Server Start tab (illustrated in Figure 9-2).

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

    Note:

    There should be no breaks in lines between the different -D parameters. Do not copy or paste the text from above to your Administration Console's arguments text field. This may result in HTML tags being inserted in the Java arguments. The text should not contain other text characters than those included the example above.

    Note:

    The Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying a different port (for example, 8089) with 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.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=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.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    

    For more information about Coherence Clusters see the Oracle Coherence Developer's Guide.

    For WLS_SOA1, enter the following:

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

    For WLS_SOA2, enter the following:

    -Dtangosol.coherence.wka1=SOAHOST1VHN1
    -Dtangosol.coherence.wka2=SOAHOST2VHN1
    -Dtangosol.coherence.localhost=SOAHOST2VHN1
    
  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. SOA 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 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 Server

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

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

9.5.2 Restarting the Node Manager on SOAHOST1

Use the startNodeManager.sh script to restart Node Manager.

To restart the 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 for Oracle SOA Suite

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

To 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 select Data Sources.

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

  4. Click the Monitoring tab.

  5. Click the Testing tab, select WLS_SOA1, and click Test Data Source (Figure 9-3).

    Figure 9-3 Testing GridLink Data Source

    Test GridLink data source was successful

    The test should be successful if the configuration is correct.

  6. Repeat the test for each SOA managed server 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 select Data Sources.

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

  4. Click the Monitoring tab.

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

    Figure 9-4 Testing ONS Setup

    Test ONS Setup was successful
  6. Select WLS_SOA1, and click Test ONS.

    If the configuration is correct, the ONS test is successful. 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 each managed server 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 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=soadomaintemplateExtSOA.jar -template_name=soadomaintemplateExtSOA
    

    Note:

    If the specified template pack jar file exists from previous pack/unpack operations, choose another name (such as soadomaintemplateExtSOA2.jar).

  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=soadomaintemplateExtSOA.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

Start and validate the WLS_SOA1 managed server using the Administration Console.

To start the WLS_SOA1 managed server on SOAHOST1:

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

    1. Access the Administration Console at the following URL:

      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. Click Servers.

      The Summary of Servers screen appears.

    4. Click the Control tab.

    5. Select WLS_SOA1 and then click Start.

  2. Verify that the server status is reported as Running. 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.9, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" for possible causes.

  3. Access the following URL to verify status of WLS_SOA1:

    http://SOAHOST1VHN1:8001/soa-infra/
    

    Access the following URL to verify status of the worklist application:

    http://SOAHOST1VHN1:8001/integration/worklistapp/
    

    Access the following URL to verify status of the composer application:

    http://SOAHOST1VHN1:8001/soa/composer/
    

    Before verifying access is granted, ensure that at least one of the WLS_WSM1 or WLS_WSM2 managed servers is up and running.

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

9.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 command on SOAHOST1 to copy the template file created in the previous step to SOAHOST2.

    cd ORACLE_COMMON_HOME/common/bin
    
    scp soadomaintemplateExtSOA.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin
    
  2. Run the unpack command on SOAHOST2 to unpack the propagated template.

    cd ORACLE_COMMON_HOME/common/bin
    
    ./unpack.sh
    -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/
    -template=soadomaintemplateExtSOA.jar -overwrite_domain=true
    -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.

Note:

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

9.6.2 Starting and Validating the WLS_SOA2 Managed Server

Use the Administration Console to start the WLS_SOA2 managed server. Validate it by accessing soa-infra, and worklistapp URLs.

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

  1. Start the WLS_SOA2 managed server using the Administration Console.

  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.9, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" for possible causes.

  3. Access the following URL for soa-infra:

    http://SOAHOST2VHN1:8001/soa-infra
    
  4. Access the following URL to verify status of the worklist application.

    http://SOAHOST2VHN1:8001/integration/worklistapp/
    

    Before verifying access is granted, ensure that at least one of the managed servers (WLS_WSM1 or WLS_WSM2) is up and running.

    Note:

    Although the WLS_SOA1 server may be up, some applications may be in a failed state. Therefore, Oracle recommends verifying the URLs above and watch for errors pertaining each individual application in the server's output file.

  5. Access the following URL to verify status of the composer application.

    http://SOAHOST2VHN1:8001/soa/composer/
    

9.7 Configuring Oracle HTTP Server with the Extended Domain

After propagating the domain configuration to SOAHOST2, configure the Oracle HTTP Server with the extended domain.

This section includes the following topics:

9.7.1 Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers

To enable Oracle HTTP Server to route to the SOA_Cluster, which contains the WLS_SOAn managed servers, set the WebLogicCluster parameter to the list of nodes in the cluster.

To enable Oracle HTTP Server to route to the SOA_Cluster:

  1. On WEBHOST1 and WEBHOST2, add directives highlighted in bold (Example 9-1) to the wcp_vh.conf file located in the following directory:

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

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

    The wcp_vh.conf file will appear as it does in Example 9-1.

    Example 9-1 wcp_vh.conf File

    <VirtualHost *:7777>
        ServerName https://wcp.mycompany.com:443
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    
    <Location /soa-infra>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # SOA inspection.wsil
    <Location /inspection.wsil>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # UMS prefs
    <Location /sdpmessaging/userprefs-ui>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # Default to-do taskflow
    <Location /DefaultToDoTaskFlow>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # Workflow
    <Location /workflow>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    #Required if attachments are added for workflow tasks
     <Location /ADFAttachmentHelper>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # SOA composer application
     <Location /soa/composer>
         SetHandler weblogic-handler
         WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    </VirtualHost>
    
  2. Similarly, add the directives highlighted in bold (Example 9-2) to the wcpinternal_vh.conf file at the same location.

    The wcpinternal_vh.conf file will appear as it does in Example 9-2.

    Example 9-2 wcpinternal_vh.conf file

    <VirtualHost *:7777>
        ServerName wcpinternal.mycompany.com:80
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    
    # WSM-PM
    <Location /wsm-pm>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
    </Location>
    
    # Worklist
    <Location /integration>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    </Location>
    
    # Workflow
    <Location /workflow>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    </Location>
    
    </VirtualHost>
    
  3. Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:

    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 parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. The listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

Sample scenarios:

  • Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered on the fly at runtime.

  • Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.

    If you list all members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started.

For more information on configuring the WebLogic Server plug-in, see the Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server guide.

9.7.2 Validating Access Through Oracle HTTP Server

Verify that the server status is reported as Running in the Admin 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.9, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" for possible causes.

Verify these load balancer URLs to ensure that appropriate routing and failover is working from Oracle HTTP Server to SOA_Cluster:

  • https://wcp.mycompany.com/soa-infra

  • https://wcp.mycompany.com/integration/worklistapp

  • https://wcp.mycompany.com/sdpmessaging/userprefs-ui

  • https://wcp.mycompany.com/soa/composer

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

9.7.3 Setting the Frontend HTTP Host and Port

This section contains the procedure for setting the frontend HTTP host and port using the Administration Console. It also contains information about how callback URLs are calculated.

9.7.3.1 Setting the Frontend HTTP Host and Port

To set the frontend HTTP host and port for the Oracle WebLogic Server cluster:

  1. In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.

  2. In the left pane, select Environment in the Domain Structure window and then select Clusters. The Summary of Clusters page appears.

  3. Select the SOA_Cluster cluster.

  4. Select HTTP.

  5. Set the values for the following:

    • Frontend Host: wcp.mycompany.com

    • Frontend HTTPS Port: 443

    • Frontend HTTP Port: 80

  6. Click Save.

  7. To activate the changes, click Activate Changes in the Change Center section of the Administration Console.

  8. Restart the servers for the Frontend Host directive in the cluster to take affect.

Note:

When HTTPS is enabled in the load balancer and the load balancer terminates SSL (the SOA servers receive only HTTP requests, not HTTPS), as suggested in this guide, the endpoint protocol for webservices is set to http. Since the load balancer redirects HTTP to HTTPS this causes the following exception when testing webservices functionality in Oracle Enterprise Manger Fusion Middleware Control:

(javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException)

To resolve this exception, update the URL endpoint:

In the Enterprise Manager Test Page, check Edit Endpoint URL.

Within the endpoint URL page:

  • Change http to https.

  • Change the default port number (say 80) to SSL port (say 443).

9.7.3.2 About the Callback URL

This section describes how the SOA system calculates the callback URL.

  • If a request to SOA originates from an external or internal service, SOA uses the callback URL specified by the client.

  • If a request to an external or internal asynchronous service originates from SOA, SOA uses the following method, in decreasing order of preference to calculate the callback URL:

    1. Use callbackServerURL specified as a binding property for the specific reference. (You can set this when modeling the composite or at runtime using the MBeans). This allows different service calls to have different callback URLs. That is, a callback URL from an external service can be set to be different than one to an internal service In the context of the Enterprise Deployment architecture, typically this will be wcp.mycompany.com (443/https) for external services and wcpinternal.mycompany.com (7777/http) for internal services. At runtime, this property is set using the System MBean Browser, through the corresponding binding mbean. To add a specific URL, add a callbackServerURL property to its Properties attribute, then invoke the save operation.

    2. Use the callback URL as specified in soa-infra-config.xml. In this case, only one address can be specified. When a mix of both external and internal services can be invoked, this should be set to wcp.mycompany.com (443/https) in the Enterprise Deployment architecture. When only internal services are to be invoked, this can be set to wcpinternal.mycompany.com (7777/http).

    3. Use the callback URL as the frontend host specified in WLS for the SOA_Cluster. In this case, too, only one address can be specified and the recommendation is same as the one for soa-infra-config.xml.

    4. Use the local host name as provided by WLS MBean APIs. Oracle does not recommend this in high availability environments such as enterprise deployment.

9.8 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to 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 stores:

  1. Log into the Oracle WebLogic Server Administration Console.

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

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

  4. Click the name of the server WLS_SOA1 (represented as a hyperlink) in Name column of the table.

    The settings page for the selected server appears and defaults to the Configuration tab.

  5. Click the Configuration tab, and then the Services tab (not the top-level Services tab).

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

    ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
    
  7. Repeat steps 3, 4, 5, and 6 for the WLS_SOA2 server.

  8. Click Save and Activate Changes.

  9. Restart the WLS_SOA1 and WLS_SOA2 Managed Servers.

  10. After WLS_SOA1 and WLS_SOA2 are restarted, verify that the following files are created in the following directory:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
    
    • _WLS_WLS_SOA1000000.DAT

    • _WLS_WLS_SOA2000000.DAT

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. This directory must also exist before you restart the server.

9.9 Configuring Oracle Adapters

Configure Oracle File, FTP, and database adapters for the extended SOA domain.

This section includes the following topics:

9.9.1 Enabling High Availability for Oracle File and FTP Adapters

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 operation described above is necessary only if your application requires these adapters.

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 RAC backend or in the SOA managed servers.

9.9.1.1 Using the Database Mutex Locking Operation

Make an outbound Oracle File or FTP Adapter service highly available using database table as a coordinator:

Note:

The steps and configuration options for the FTP adapter are exactly the same as the options for the file adapter. The connection factory to be used for FTP HA configuration is eis/Ftp/HAFtpAdapter which appears under the Outbound Connection Pools for the FTPAdapter deployment.

Note:

If you use database as a coordinator, increase global transaction timeouts.

To make outbound Oracle File or FTP Adapters highly available, modify Oracle File Adapter deployment descriptor for the connection-instance corresponding to eis/HAFileAdapter from the Oracle WebLogic Server console:

  1. Log into your Oracle WebLogic Server console. To access the console navigate to the following URL:

    http://servername:portnumber/console
    
  2. Click Deployments in the left pane for Domain Structure.

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

  4. Click the Configuration tab.

  5. Click 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 for the connection factory corresponding to high availability is displayed.

  7. The connection factory properties appear as shown in Figure 9-5.

    Figure 9-5 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page

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

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

    The new parameters in connection factory for Oracle File and FTP Adapters are as follows:

    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 in the following directory:

    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 are located in the following directory:

    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.

    outboundDataSourceLocal: Set the value to jdbc/SOALocalTxDataSource. This is the data source where the schemas corresponding to high availability are pre-created.

    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.

  8. Click Save after you update the properties. The Save Deployment Plan page appears.

  9. 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. Once the new deployment plan has been saved and activated, activate the FileAdapter deployment (the deployment remains in Prepared state if not started). To activate the FileAdapter deployment plan:

    In the Administration Console, click Deployments in the left pane for Domain Structure.

    Select the FileAdapter under Summary of Deployments on the right pane and Select Start, and then Servicing All Requests.

  12. (Optional) Configure BPEL Process or Mediator Scenario to use the connection factory as shown in the following example (in the jca file included in the composite for the binding component):

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

    Notes:

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

    • The preceding steps are for configuring the File Adapter for high availability. To configure the FTP Adapter for high availability, perform the same steps for updating the control directory. Use the eis/Ftp/HAFtpAdapter connection factory instance for these modifications.

9.9.2 Enabling High Availability for Oracle JMS Adapters

When the Oracle JMS adapter communicates with multiple servers in a cluster, the adapter's connection factory property FactoryProperties must list available servers. If it does not list servers, the connection establishes to only one random server. If that particular server goes down, no further messages are processed.

To verify the adapter's JCA connection factory:

  1. Log into your Oracle WebLogic Server Administration Console using the following URL:

    http://servername:portnumber/console
    
  2. Click Deployments in the left pane for Domain Structure.

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

  4. Click the Configuration tab.

  5. Click the Outbound Connection Pools tab and expand oracle.tip.adapter.jms.IJmsConnectionFactory to see the configured connection factories.

  6. Click the specific instance you are using (for example, eis/wls/Queue). The Outbound Connection Properties for the connection factory opens.

  7. Click Lock & Edit.

  8. In the FactoryProperties field (click on the corresponding cell under Property value), enter the following:

    java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
    java.naming.provider.url=t3://soahostvhn1:8001,soahost2vhn1:8001;java.naming.security.principal=weblogic;
    java.naming.security.credentials=myPassword1
    
  9. Click Save after you update the properties. The Save Deployment Plan page appears.

  10. 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
    
  11. Click Save and Activate.

Update the deployment in the console:

  1. Click Deployments and select the JMS Adapter.

  2. Click Lock & Edit then Update.

  3. Select Update this application in place with new deployment plan changes (A deployment plan must be specified for this option.) and select the deployment plan saved in a shared storage location; all servers in the cluster must be able to access the plan).

  4. Click Finish.

  5. Activate the changes.

9.9.3 Scaling the Oracle Database Adapter

The introduction of skip locking has superseded the previous best practice of using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize. If you were using this approach previously, you can simply remove (in db.jca) or deselect(Logical Delete Page of wizard) the MarkReservedValue, and you 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 a non-recoverable situation in a high availability environment is minimized.

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

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 that approach has now been superseded. If you were using this approach previously, you can simply remove (in db.jca) or deselect (Logical Delete Page of wizard) the MarkReservedValue, and you automatically get skip locking.

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

9.10 Backing Up the SOA Configuration

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

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

To back up the domain configuration:

  1. Back up the web tier:

    1. Shut down the instance using opmnctl.

      ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
      
    2. Back up the Middleware Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
      
    3. Back up the Instance Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
      
    4. Start the instance using opmnctl:

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

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

    ORACLE_BASE/admin/domain_name
    

    To back up the Administration Server run the following command on SOAHOST1:

    tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name