11 Extending a SOA Domain to Oracle Service Bus

11.1 Overview of Adding Oracle Service Bus to a SOA Domain

This section provides an overview of adding Oracle Service bus to an SOA domain. Table 11-1 lists and describes to high-level steps for extending a SOA domain for Oracle Service Bus.

11.2 Enabling VIP5 on SOAHOST1 and VIP6 on SOAHOST2

The SOA domain uses virtual hostnames as the listen addresses for the Oracle Service Bus managed servers. Enable a virtual IP mapping for each of these hostnames on the two SOA Machines, (VIP5 on SOAHOST1 and VIP6 on SOAHOST2), and correctly resolve the virtual hostnames in the network system used by the topology (either by DNS Server, hosts resolution).

To enable the virtual IP, follow the steps described in Section 3.5, "Enabling Virtual IP Addresses for Administration Servers." These virtual IPs and VHNs are required to enable server migration for the Oracle Service Bus Servers. Server migration must be configured for the Oracle Service Bus Cluster for high availability purposes. Refer to Chapter 9, "Server Migration" for more details on configuring server migration for the Oracle Service Bus servers.

11.3 Running the Configuration Wizard on SOAHOST1 to Extend a SOA Domain to Include Oracle Service Bus

In this step, you extend the domain created in Chapter 9, "Extending the Domain for SOA Components" to contain Oracle Service Bus components. The steps reflected in this section would be very similar if Oracle Service Bus was extending a domain containing only an Admin Server and a WSM-PM Cluster, but some of the options, libraries and components shown in the screens could vary.

To extend the domain for Oracle Service Bus:

1. Change directory to the location of the Configuration Wizard. This is within the Oracle Service Bus directory. (All database instances should be up.)

   cd ORACLE_COMMON_HOME/common/bin
   

2. Start the Configuration Wizard.

   ./config.sh
   

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

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

   ORACLE_BASE/admin/domain_name/aserver/domain_name
   

   Click Next.

5. In the Select Extension Source screen, select Extend my domain automatically to support the following added products and select the following products (the components required by Oracle SOA and Oracle WSM Policy Manager should already be selected and grayed out):

   • Oracle Service Bus OWSM Extension - 11.1.1.6 [osb]

   • Oracle Service Bus - 11.1.1.0 [osb]

   • WebLogic Advance Web Services JAX-RPC Extension

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

   • Select the select the OSB JMS reporting Provider schema.

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

   Click Next. The Configure Gridlink RAC Component Schema screen appears.

7. In the Configure Gridlink RAC Component Schema screen accept the values for the data sources that are already present in the domain and click Next.

8. In the Test JDBC Component Schema screen, verify that the Oracle Service Bus JMS reporting datasources are correctly verified and click Next.

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

10. In the Select JMS Distributed Destination Type screen leave the pre-existing JMS System Resources as they are and Select UDD from the drop down list for WseeJMSMOdule and JmsResources.

    Click Next.

11. In the Configure Managed Servers screen, add the required managed servers for Oracle Service Bus.

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

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

    3. Give servers WLS_OSB1 and WLS_OSB2 the attributes listed in Table 11-2.

    In the end, the list of managed servers should match Table 11-2.

    Click Next.

    • Table 11-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
      WLS_OSB1	SOAHOST1VHN2	8011	n/a	No
      WLS_OSB2	SOAHOST2VHN2	8011	n/a	No

      
      

12. In the Configure Clusters screen, add the Oracle Service Bus cluster (leave the present cluster as they are):

    Table 11-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.
    OSB_Cluster	unicast	n/a	n/a	SOAHOST1VHN2:8011, SOAHOST2VHN2:8011

    
    

    (*) - if you are extending a SOA domain

    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 configuration 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 configuration property JndiProviderURL/SecureJndiProviderURL can be used for the same purpose if explicitly set by users.

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

    • SOA_Cluster - If you are extending a SOA domain.

      • WLS_SOA1

      • WLS_SOA2

    • WSM-PM_Cluster:

      • WLS_WSM1

      • WLS_WSM2

    • OSB_Cluster:

      • WLS_OSB1

      • WLS_OSB2

      Click Next.

14. Confirm that the following entries appear:

    Table 11-4 Machines

    Name	Node Manager Listen Address
    SOAHOST1	SOAHOST1
    SOAHOST2	SOAHOST2
    ADMINHOST	localhost

    
    

    Leave all other fields to their default values.

    Click Next.

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

    • ADMINHOST:

      • AdminServer

    • SOAHOST1

      • WLS_SOA1 (if extending a SOA domain)

      • WLS_WSM1

      • WLS_OSB1

    • SOAHOST2:

      • WLS_SOA2 (if extending a SOA domain)

      • WLS_WSM2

      • WLS_OSB2

      Click Next.

16. 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 AdminServer and SOA_Cluster.

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

    • Target all Transport Provider Deployments to both the OSB_Cluster and the AdminServer.

    Click Next.

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

17. In the Target Services to Clusters or Servers screen:

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

    • Target mds-soa only to SOA_Cluster.

    Click Next.

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

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
    

    Select Direct-write policy for all stores.

    Click Next.

19. In the Configuration Summary screen click Extend.

20. In the Extending Domain screen, click Done.

21. Restart the Administration Server for this configuration to take effect.

11.4 Disabling Host Name Verification for the WLS_OSBn Managed Servers

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

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

11.5 Configuring Oracle Coherence for the Oracle Service Bus Result Cache

By default, result caching uses multicast communication. Oracle recommends using unicast communication for the Oracle Service Bus result cache. Additionally, Oracle recommends separating port ranges for Coherence clusters used by different products. The ports for the Oracle Service Bus result cache Coherence cluster should be different from the Coherence cluster used for SOA.

To enable unicast for the Oracle Service Bus result cache Coherence infrastructure:

1. Log into Oracle WebLogic Server Administration Console. In the Change Center, click Lock & Edit.

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

3. Click Servers.

4. Click the name of the server (represented as a hyperlink) in the Name column of the table. The settings page for the selected server appears.

5. Click the Server Start tab.

6. Enter the following into the Arguments field for WLS_OSB1 on a single line, with no carriage returns:

   -DOSB.coherence.localhost=soahost1vhn2 -DOSB.coherence.localport=7890 
   -DOSB.coherence.wka1=soahost1vhn2 -DOSB.coherence.wka1.port=7890 
   -DOSB.coherence.wka2=soahost2vhn2 -DOSB.coherence.wka2.port=7890
   

   For WLS_OSB2, enter the following on a single line, no carriage returns:

   -DOSB.coherence.localhost=soahost2vhn2 -DOSB.coherence.localport=7890 
   -DOSB.coherence.wka1=soahost1vhn2 -DOSB.coherence.wka1.port=7890 
   -DOSB.coherence.wka2=soahost2vhn2 -DOSB.coherence.wka2.port=7890
   

   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.

7. Save and activate the changes. You must restart Oracle Service Bus servers for these changes take effect.

   Note:

   The Coherence cluster used for Oracle Service Bus' result cache is configured above using port 7890. This port can be changed by specifying a different port (for example, 8089) with the following startup parameters:

   -Dtangosol.coherence.wkan.port
   -Dtangosol.coherence.localport
   

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

8. Ensure that these variables are passed to the managed server correctly by checking the server's output log.

   Failure of the Oracle Coherence framework can prevent the result caching from working.

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

To set the location for the default persistence stores:

1. Log into the Oracle WebLogic Server Administration Console.

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

   The Summary of Servers page appears.

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

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

4. Click the Services tab.

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

6. Perform Steps 2-5 for both WLS_OSB1, and WLS_OSB2 servers.

7. Click Save and Active Changes.

11.7 Propagating the Domain Configuration to the Managed Server Directory in SOAHOST1 and to SOAHOST2

Oracle Service Bus requires some updates to the WebLogic Server start scripts. Propagate these changes using the pack and unpack commands.

Prerequisite

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

To propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory:

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

   cd ORACLE_COMMON_HOME/common/bin
    
   ./pack.sh -managed=true -domain=ORACLE_BASE/admin/
   domain_name/aserver/domain_name -template=soadomaintemplateExtOSB.jar
    -template_name=soa_domain_templateExtOSB
   

2. Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server:

   ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
   -overwrite_domain=true -template=soadomaintemplateExtOSB.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.

3. Copy the template to SOAHOST2 run the following commands on SOAHOST1:

   cd ORACLE_COMMON_HOME/common/bin
   
   scp soadomaintemplateExtOSB.jar oracle@SOAHOST2:/ ORACLE_COMMON_HOME/common/bin
   

4. 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/ -overwrite_domain=true
   -template=soadomaintemplateExtOSB.jar -app_dir=ORACLE_BASE/admin/
   domain_name/mserver/applications
   

11.8 Starting the Oracle Service Bus Servers

Since Oracle Service Bus servers extend an already existing domain it is assumed that the Administration Server and respective Node Managers are already running in SOAHOST1 and SOAHOST2.

To start the added the WLS_OSB servers:

1. Log into the Oracle WebLogic Server Administration Console at:

   http://ADMINVHN:7001/console
   

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

   The Summary of Servers page appears.

3. Click the Control tab.

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

5. Click Start. Wait for the server to come up and check that its status is reported as RUNNING in the Administration Console.

6. Repeat steps 2 through 5 for WLS_OSB2.

11.9 Validating the WLS_OSB Managed Servers

Validate the WLS_OSB managed servers using the Oracle WebLogic Server Administration Console and by accessing URLs.

To validate the WLS_OSB managed server:

1. 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.14, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.

2. Access the following URL to verify status of WLS_OSB1:

   http://SOAHOST1VHN2:8011/sbinspection.wsil
   

   With the default installation, this should be the HTTP response:

   Figure 11-1 HTTP Response

   
   

3. Access the following URL:

   http://SOAHOST1VHN2:8011/alsb/ws/_async/AsyncResponseServiceJms?WSDL
   

   With the default installation, this should be the HTTP response:

   Figure 11-2 HTTP Response

   
   

4. Access the equivalent URLs for:

   http://SOAHOST2VHN2:8011/
   

5. Verify also the correct deployment of the Oracle Service Bus console to the Administration Server by accessing the following URL:

   http://ADMINHOSTVHN:7001/sbconsole/
   

   The Oracle Service Bus console should appear with no errors.

11.10 Configuring Oracle HTTP Server for the WLS_OSBn Managed Servers

To enable Oracle HTTP Server to route to Oracle Service Bus console and Oracle Service Bus service you must set the WebLogicCluster parameter to the list of nodes in the cluster.

If you use a virtual server for administration purposes, the /sbconsole defines routing in the context of the virtual server in the admin_vh.conf file. Similarly, add the rest of the Oracle Service Bus URLs to the osb_vh.conf file.

Start the context paths for the HTTP proxy services with a common name, such as /osb/project-name/folder-name/proxy-service-name to facilitate the routing in Oracle HTTP Server for all the proxy services.

To set the parameter:

1. On WEBHOST1 and WEBHOST2, add directives to the osb_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 osb_vh.conf file using the instructions in Section 7.6, "Defining Virtual Hosts."

   Add the following directives inside the <VirtualHost> tags:

   <Location /sbinspection.wsil >
       SetHandler weblogic-handler
       WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
       WLProxySSL ON
       WLProxySSLPassThrough ON
   </Location>
    
   <Location /sbresource >
       SetHandler weblogic-handler
       WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
       WLProxySSL ON
       WLProxySSLPassThrough ON
   </Location>
    
   <Location /osb >
       SetHandler weblogic-handler
       WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
       WLProxySSL ON
       WLProxySSLPassThrough ON
   </Location>
    
   <Location /alsb >
       SetHandler weblogic-handler
       WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
       WLProxySSL ON
       WLProxySSLPassThrough ON
   </Location>
   

   The osb_vh.conf file will appear as it does in Example 11-1.

2. Add the following entry to the admin_vh.conf file within the <VirtualHost> tags:

   <Location /sbconsole >
       SetHandler weblogic-handler
       WebLogicHost ADMINVHN
       WeblogicPort 7001
      </Location>
   

   The admin_vh.conf file will appear as it does in Example 11-2.

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
   

<VirtualHost *:7777>
    ServerName https://osb.mycompany.com:443
    ServerAdmin [email protected]
    RewriteEngine On
    RewriteOptions inherit

<Location /sbinspection.wsil >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
 
<Location /sbresource >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
 
<Location /osb >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
 
<Location /alsb >
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN2:8011,SOAHOST2VHN2:8011
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>

# The admin URLs should only be accessible via the admin virtual host 

<VirtualHost *:7777>
    ServerName admin.mycompany.com:80
    ServerAdmin [email protected]
    RewriteEngine On
    RewriteOptions inherit

# Admin Server and EM
<Location /console>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /consolehelp>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /em>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /sbconsole >
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
   </Location>
</VirtualHost>

11.11 Setting the Front End HTTP Host and Port for OSB_Cluster

Set the front end HTTP host and port for Oracle WebLogic Server cluster using the WebLogic Server Administration Console.

To set the front end host and port:

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

2. In the left pane, select Environment and then Clusters.

3. Select the OSB_Cluster.

4. Select HTTP.

5. Set the values for the following:

   • Frontend Host: osb.mycompany.com

   • Frontend HTTP Port: 80

   • Frontend HTTPS Port: 443

     Note:

     Make sure this address is correct and available (the load balancing router is up). An incorrect value, for example, http:// in the address, or trailing / in the hostname, may prevent the SOA system from being accessible even when using the virtual IPs to access it.

     Click Save.

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

11.12 Validating Access Through Oracle HTTP Server

Since you have already set the cluster address for the OSB_Cluster, the Oracle Service Bus URLs can only be verified once Oracle HTTP Server has been configured to route the Oracle Service Bus context URLs to the WebLogic Servers. Verify the URLs to ensure that appropriate routing and failover is working from the HTTP Server to the Oracle Service Bus components.

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

To verify the URLs:

1. While WLS_OSB1 is running, stop WLS_OSB2 using the Oracle WebLogic Server Administration Console.

2. Access WebHost1:7777/sbinspection.wsil and verify the HTTP response as indicated in Section 11.9, "Validating the WLS_OSB Managed Servers."

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

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

5. Access WebHost1:7777/sbinspection.wsil and verify the HTTP response as indicated in section Section 11.9, "Validating the WLS_OSB Managed Servers."

   Note:

   Since a front end URL has been set for the OSB_Cluster, the requests to the urls result in a re-route to the LBR, but in all cases it should suffice to verify the appropriate mount points and correct failover in Oracle HTTP Server.

6. Verify this URLs using your load balancer address:

   http://osb.mycompany.com:80/sbinspection.wsil
   

11.13 Enabling High Availability for Oracle DB, File and FTP Adapters

Oracle SOA Suite and Oracle Service Bus use the same database and File and FTP JCA adapters. You create the required database schemas for these adapters when you use the Oracle Repository Creation Utility for SOA. The required configuration for the adapters is described in section Section 9.8.1, "Enabling High Availability for Oracle File and FTP Adapters." The DB adapter does not require any configuration at the WebLogic Server resource level. If you are configuring Oracle Service Bus as an extension of a SOA domain, you do not need to add to the configuration already performed for the adapters.

If you are deploying Oracle Service Bus as an extension to a WSM-PM and Admin Server domain, do the following:

• Run RCU to seed the Oracle Service Bus database with the required adapter schemas (Select SOA Infrastructure, and SOA and BAM Infrastructure in RCU).

• Perform the steps in, and the steps reflected in Section 9.8.1, "Enabling High Availability for Oracle File and FTP Adapters."

11.14 Configuring Server Migration for the WLS_OSB Servers

The high availability architecture for an Oracle Service Bus system uses server migration to protect some singleton services against failures. For more information on whole server migration, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.

The WLS_OSB1 managed server is configured to be restarted on SOAHOST2 in case of failure, and the WLS_OSB2 managed server is configured to be restarted on SOAHOST1 in case of failure. For this configuration the WLS_OSB1 and WLS_OSB2 servers listen on specific floating IPs that are failed over by WLS Server Migration.

Table Table 11-5 lists the high-level steps for configuring server migration for the WLS_OSB server.

WL_HOME/common/nodemanager 

...
StateCheckInterval=500
Interface=eth0 (Linux) or Interface="Local Area Connection" (Windows)
NetMask=255.255.255.0
UseMACBroadcast=true
...

11.15 Backing Up the Oracle Service Bus Configuration

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

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

To back up the domain configuration:

1. Back up the Web tier:

   1. Shut down the instance using opmnctl.

      ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
      

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

      tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
      

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

      tar -cvpf BACKUP_LOCATION/web_instance.tar ORACLE_INSTANCE
      

   4. Start the instance using opmnctl:

      ORACLE_BASE/admin/instance_name/bin/opmnctl startall
      

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

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

   ORACLE_BASE/admin/domain_name
   

   To back up the Administration Server:

   tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name