5.1 Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2

The SOA domain uses virtual hostnames as the listen addresses for the SOA managed servers. You must enable A VIP mapping each of these hostnames on the two SOA Machines, (VIP2 on SOAHOST1 and VIP3 on SOAHOST2), and must be correctly resolve the virtual hostnames in the network system used by the topology (either by DNS Server, hosts resolution).

To enable the VIP, follow the steps described in Section 4.3, "Enabling VIP1 in SOAHOST1." These VIPs and VHNs are required to enable server migration for the SOA Servers. Server migration must be configured for the SOA System for high availability purposes. Refer to Chapter 9, "Server Migration" for more details on configuring server migration for the SOA servers.

Oracle SOA uses Quartz to maintain its jobs and schedules in the database. The system clocks for the SOA WebLogic cluster must be synchronized to enable proper functioning of jobs, adapters, and Oracle B2B.

Change directory to the location of the Configuration Wizard. This is within the SOA home directory. (It is recommended that all database instances should be up.)

SOAHOST1> cd ORACLE_HOME/common/bin

Start the Configuration Wizard.

SOAHOST1> ./config.sh

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

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

A server called soa_server1 is created automatically. Rename this to WLS_SOA1 and give it the attributes listed in Table 5-1. Then, add a new server called WLS_SOA2. The WLS_WSM1 and WLS_WSM2 managed servers should already be present because they are part of the domain that you are extending. In the end, the list of managed servers should match that in Table 5-1.

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

In the Configure Clusters screen, add the following clusters:

Table 5-2 Clusters

Name

Cluster Messaging Mode

Multicast Address

Multicast Port

Cluster Address

SOA_Cluster

unicast

n/a

n/a

Leave it empty.

WSM-PM_Cluster

unicast

n/a

n/a

Leave it empty.

Click Next.

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.

In the Configure Machines screen, do the following:

Delete the LocalMachine that appears by default.

Click the Unix Machine tab. The following entries appear (listed in Table 5-3):

Table 5-3 Machines

Name

Node Manager Listen Address

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

localhost

Leave all other fields to their default values.

Click Next.

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.

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

The oracle.sdp.*, and oracle.soa.* libraries should be targeted only to SOA_Cluster.

The oracle.rules.* library should be targeted only to Admin Server and SOA_Cluster.

The wsm-pm application should be targeted only to WSM-PM_Cluster.

The oracle.wsm.seedpolicies library should be targeted only to WSM-PM_Cluster.

Target this library to the SOA_Cluster also only if you are planning to deploy WebLogic WebServices to it.

Click Next.

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

An incorrect configuration of the Oracle Coherence framework that is 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 following configuration described in this section.

Enabling Communication for Deployment Using Unicast Communication

Multicast communication enables Oracle Fusion Middleware SOA to discover all of the members of a cluster to which to it deploys composites dynamically. However, 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 box, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.

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.

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 9 nodes. 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 5-2).

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

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

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.

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.

5.5 Setting Connection Destination Identifiers for B2B Queues

Oracle B2B uses specific JMS Destination Member calls, and requires setting the Create Destination Identifier (CDI) for these calls to succeed. To set up the CDI:

Log into the Oracle WebLogic Server Administration Console.

In the Domain Structure window, expand the Services node, and then the Messaging node.

Click JMS Modules, and then SOAJMSModule.

Click Lock and Edit.

Click the dist_B2BEventQueue_auto, Configuration, and the General tab, and then click Advanced.

In the Create Destination Identifier field, add the following jndi name for the queue:

jms/b2b/B2BEventQueue

Repeat these steps, creating the following Create Destination Identifiers for the queues listed below:

5.6Disabling Host Name Verification for the WLS_SOAn Managed Server

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

To disable host name verification, complete these steps:

Log in to Oracle WebLogic Server Administration Console.

Click Lock and Edit.

Expand the Environment node in the Domain Structure window.

Click Servers. The Summary of Servers page appears.

Select WLS_SOA1 (represented as a hyperlink) from the Names column of the table. The Settings page appears.

Select the SSL tab.

Expand the Advanced section of the page.

Set Hostname Verification to None.

Click Save.

Repeat these steps for the WLS_SOA2 managed server.

Save and activate the changes.

5.7Restarting the Node Manager on SOAHOST1

To restart the Node Manager on SOAHOST1:

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:

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.

5.9Starting the WLS_SOA1 Managed Server on SOAHOST1

To start the WLS_SOA1 managed server on SOAHOST1, complete these steps:

Access the Administration Console at http://SOAHOST1VHN1:7001/console.

Click Servers.

Open the Control tab.

Select WLS_SOA1.

Click Start.

Note:

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

5.10Validating the WLS_SOA1 Managed Server

To validate the WLS_SOA1 managed server, complete these steps:

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 10.7, "Troubleshooting" for possible causes.

Access http://SOAHOST1VHN1:8001/integration/worklistapp/ to verify status of the worklist application. Before verifying access is granted, ensure that the WLS_WSM1 managed server is up and running.

Note:

Notice that, 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.11Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility

To propagate the domain configuration, complete these steps:

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

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.

5.12Extracting the XEngine Files in SOAHOST2

To enable B2B's XEngine in SOAHOST2, you need to extract the content of the XEngine tar manually:

5.13Restarting Node Manager on SOAHOST2

5.14Starting and Validating the WLS_SOA2 Managed Server

Perform these steps to start the WLS_SOA2 managed server and check that it is configured correctly:

Start the WLS_SOA2 managed server using the Administration Console.

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 10.7, "Troubleshooting" for possible causes.

Access http://SOAHOST2VHN1:8001/soa-infra.

Access http://SOAHOST2VHN1:8001/b2bconsole to verify status of B2B.

Access http://SOAHOST2VHN1:8001/integration/worklistapp/ to verify status of the worklist application. 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.15Configuring 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, you must set the WebLogicCluster parameter to the list of nodes in the cluster.

On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/ admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.conf file:

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

5.16Validating 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 10.7, "Troubleshooting" for possible causes.

Verify that you can access these URLs, where 'webhostN' specifies the name of each Oracle HTTP Server host (for example, WEBHOST1, WEBHOST2):

http://webhostN:7777/soa-infra

http://webhostN:7777/integration/worklistapp

http://webhostN:7777/b2bconsole

http://webhostN:7777/sdpmessaging/userprefs-ui

http://webhostN:7777/soa/composer

Validate SOA_Cluster through both Oracle HTTP Server instances.

Refer to load balancer configuration to access the system through the load balancer.

5.17Setting the Frontend HTTP Host and Port

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

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

Select the SOA_Cluster cluster.

Select HTTP.

Set the values for the following:

Frontend Host: soa.mycompany.com

Frontend HTTPS Port: 443

Frontend HTTP Port: 80

Click Save.

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

Restart the servers to make the Frontend Host directive in the cluster effective.

Note:

If you do not set the frontend HTTP host and port, you get the following message when trying to retrieve a document definition XSD from Oracle B2B:

An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.

Callback URL

The SOA system calculates the callback URL as follows:

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

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

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 EDG architecture, typically this will be soa.mycompany.com (443/https) for external services and soainternal.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.

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 soa.mycompany.com (443/https) in the EDG architecture. When only internal services are to be invoked, this can be set to soainternal.mycompany.com (7777/http).

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.

Use the local host name as provided by WLS MBean APIs. This is not recommended in HA environments such as EDG.

In the left pane, choose Environment from the Domain Structure window, and then choose Clusters. The Summary of Clusters page appears.

Select the SOA_Cluster cluster.

In the Configuration, General tab, enter the following in the Cluster Address field:

SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

Click Save.

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

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

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.

In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page appears.

Select the persistence store (represented as a hyperlink) from the Name column of the table. The Settings page for the persistence store appear.

In the Configuration tab, enter the location on a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster in the Directory field. Specifying this location enables pending JMS messages to be sent. The location should follow the following directory structure:

ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/jms

Note:

Both WLS_SOA1 and WLS_SOA2 must be able to access this directory. This directory must also exist before you restart the server.

Click Save and activate changes.

Restart the servers to make the change in the persistent stores effective.

5.20Configuring 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 store, complete these steps:

Log into the Oracle WebLogic Server Administration Console.

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

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.

Click the Services tab.

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

Click Save.

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.

5.21Enabling 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 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.

5.21.1Using the Database Mutex Locking Operation

Use the following procedure to 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:

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

Create Database Tables

You are not required to perform this step since the database schemas are pre-created as a part of soainfra.

Click on Lock and 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 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.

outboundDataSourceLocal: Set the value to jdbc/SOALocalTxDataSource. This is the datasource 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.

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

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

Click Save and Activate.

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

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

5.22Update the B2B Instance Identifier for transports

To set up File, FTP, or Email transports in a high availability environment, specify a unique name for each instance by using b2b.HAInstanceName unique_instance_name. If you use ServerName for the value, Oracle B2B retrieves the WebLogic Server name as the HAInstanceName. To specify a unique name for each instance:

On the navigation tree on the left, expand Farm_<domain_name>, SOA, and then right click on the soa-infra<server_name>, and select the SOA Administration, and then B2B Server Properties.

Click on More B2B Configuration Properties... on the right.

Click the b2b MBean.

Click the Operations tab.

Click addProperty in the list on the right.

In the Key field enter b2b.HAInstanceName.

In the value field enter ServerName.

Click Invoke.

5.23Scaling the Oracle Database Adapter

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 this release that approach has now been superseded. If you were using this approach previously, you can simply remove (in db.jca) or clear (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}.

5.24Backing 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 this 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 this guide. For information on how to recover components, see "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" in the guide. Also refer to the Oracle Database Backup and Recovery Guide for information on database backup.

To back up the installation a this point, complete these steps:

Back up the web tier:

Shut down the instance using opmnctl.

ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall

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

tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME

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

tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE

Start the instance using opmnctl:

ORACLE_BASE/admin/<instance_name>/bin/opmnctl startall

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.

Back up the Administration Server domain directory to save your domain configuration. The configuration files all exist under the ORACLE_BASE/admin/<domain_name> directory.

SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>

Note:

ORACLE_HOME should be backed up if any changes are made to the XEngine configuration that are part of your B2B setup. These files are located under ORACLE_HOME/soa/thirdparty/edifecs/XEngine. To back up ORACLE_HOME, execute the following command:

SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME

Scripting on this page enhances content navigation, but does not change the content in any way.