Understanding WebLogic Integration High Availability

A clustered WebLogic Integration application provides scalability and high availability. A highly available deployment has recovery provisions in the event of hardware or network failures, and provides for the transfer of control to a backup component when a failure occurs.

The following sections describe clustering and high availability for a WebLogic Integration deployment:

• About WebLogic Integration High Availability

• Configuring WebLogic Integration for Automatic Restart

• Configuring WebLogic Integration for Migration from Failed to Healthy Node

• Failover and Recovery

 

---

About WebLogic Integration High Availability

For a cluster to provide high availability, it must be able to recover from service failures. WebLogic Server supports failover for replicated HTTP session states, clustered objects, and services pinned to servers in a clustered environment . For information about how WebLogic Server handles such failover scenarios, see Communications in a Cluster in Using WebLogic Server Clusters, which is available at the following URL:

http://download.oracle.com/docs/cd/E13222_01/wls/docs70/cluster/index.html 

Recommended Hardware and Software

The basic components of a highly available WebLogic Integration environment include the following:

• An administration server

• A set of managed servers in a cluster

• An HTTP load balancer (router)

• A shared file system—A shared file system is required for a cluster that uses B2B integration functionality, if you want that cluster to be highly available. We recommend that you use either a Storage Area Network (SAN) or a multiported disk system.

• An Oracle, Microsoft SQL, or Sybase database—You should take advantage of any high availability or failover solutions offered by your database vendor. (See Recovering a Database.)

• Persistence mode—Deploy your application with persistence mode turned on (the default setting for WebLogic Integration). Whether your WebLogic Integration application is deployed in a cluster or on a single server, you must run it in persistent mode if you want to be able to recover after a system failure. A cluster in which B2B integration functionality is used will not work if persistent mode is off.

  When you run WebLogic Integration with persistent mode on, the in-memory, dynamic state of objects is saved to persistent storage in the WebLogic Integration repository from where it can be retrieved if necessary. Persistence mode ensures that run-time states can be recovered in the event of an abnormal shutdown or crash.

A discussion of how to plan the network topology of your clustered system is beyond the scope of this section. For information about how to fully utilize load balancing and failover features for your Web application by organizing one or more WebLogic Server clusters in relation to load balancers, firewalls, and Web servers, see Cluster Architectures in Using WebLogic Server Clusters, which is available at the following URL:

 http://download.oracle.com/docs/cd/E13222_01/wls/docs70/cluster/planning.html 

What to Expect from WebLogic Integration Recovery

A highly available deployment has recovery provisions in the event of system failures. You can configure WebLogic Integration for automatic restart or manual migration:

• You can configure WebLogic Integration for automatic restart on a managed server, whether or not that server is in a clustered environment. For information, see Configuring WebLogic Integration for Automatic Restart.

• You can configure WebLogic Integration to allow manual migration from a failed node to a healthy node in a clustered environment. For information, see Configuring WebLogic Integration for Migration from Failed to Healthy Node.

Note: High availability is not supported for WebLogic Integration applications that are based on the XOCP business protocol; such applications are not recoverable.

When you configure WebLogic Integration appropriately, you can expect the following behavior from your deployment:

• When a server fails, WebLogic Integration reestablishes connections to a live server and then it retries transactions.

• When message delivery fails:

  • In the case of RosettaNet messages, the WebLogic Integration protocol layer does not retry messages; instead it returns HttpStatus code to the workflow layer. RosettaNet workflows are usually designed to handle retries.

  • In the case of ebXML messages, you specify message retries when you specify the ebXML delivery semantics: once and only once. Based on the retry value you specify, the WebLogic Integration protocol layer performs message retries for failed ebXML messages.

• WebLogic Integration supports the manual migration of resources from a failed node to a live node in a cluster. For more information, see Configuring WebLogic Integration for Automatic Restart and Configuring WebLogic Integration for Migration from Failed to Healthy Node.

• All WebLogic Integration resources that were running before a server crashes will be running again when the server is restarted or fails over.

• If the administration server for a cluster is down, deployment or undeployment requests are interrupted, but managed servers should continue serving requests. You can boot or reboot managed servers using an existing configuration. However, you cannot change configuration for the cluster (for example, add new nodes to the cluster) until the administration server is recovered. For more information, see Backup and Failover for an Administration Server.

• If a managed server in a cluster crashes, in-flight requests are interrupted, but other managed servers in the cluster continue serving requests.

• When any one of the managed servers participating in a cluster is down, you cannot deploy or undeploy application integration resources. For example, you cannot deploy application integration adapters when any server in your cluster is down.

• In a clustered environment, it is possible that duplicate B2B messages are sent due to failover and retry attempts. In such cases, a non fatal duplicate message exception is logged, and a 202/200 HTTP status is returned. When they are received, duplicate messages are not delivered to the workflow or application layer.

• If WebLogic Integration and the database are running on the same machine and the machine is unplugged, you should take steps to recover the database before attempting to recover WebLogic Integration. Under ideal conditions, the database is deployed on a separate machine.

• High availability is supported for ebXML and RosettaNet business protocols. (Applications based on these business protocols are recoverable.)

  WebLogic Integration supports the ebXML Message Service Specification v1.0 and the RosettaNet Implementation Framework v1.1 and v2.0.

  If your WebLogic Integration application includes RosettaNet workflows developed in previous versions of WebLogic Integration, you must make changes to those workflows before running your application on WebLogic Integration 7.0. For information about migrating your workflows, see Migrating WebLogic Integration 2.1 to WebLogic Integration 7.0 in the BEA WebLogic Integration Migration Guide.

• If WebLogic Integration fails while an instance of a workflow is being processed, the workflow is rolled back, and upon recovery, it is restarted from the last quiescent point.

• If one instance of WebLogic Integration sends a message to another instance, but the destination instance has failed, you may see one or more error messages, followed by a stack trace, in the server console. The following are examples of the types of error messages displayed:

  • Not able to send RosettaNet Message

  • Peer Gone Exception

• Automatic restart and recovery are supported for both single-node and clustered deployments of WebLogic Integration. Migration is supported for clustered deployments only.

• Automatic restart and recovery are supported for single-node deployments of WebLogic Integration Business Partner (a midweight trading partner). However, you cannot deploy midweight trading partners in a clustered environment. For information about configuring your WebLogic Integration Business Partner deployment for automatic restart in the case of failure, see Configuring WebLogic Integration for Automatic Restart.

 

---

Configuring WebLogic Integration for Automatic Restart

Whether WebLogic Integration is deployed in a clustered environment or a nonclustered environment, you can configure your system to automatically restart servers that have shut down because of a system crash, hardware reboot, server failure, and so on.

Note: The procedures in this section address a clustered environment, but you can follow the same procedure to configure a nonclustered environment, that is, one in which you deploy an administration server and a managed server.

Node Manager

The procedures in this section describe how to configure your system to start a managed server when the Node Manager is running on the machine on which the managed server is located. The Node Manager is a Java program provided with WebLogic Server that enables you to perform the following tasks for managed servers:

• Start and stop any remote managed server in a domain

• Automatically restart WebLogic Server instances that have shut down because of a system crash, hardware reboot, server failure, and so on

• Automatically monitor the health of WebLogic Server instances and restart instances that have reached a failed health state

For information about the Node Manager, see Managing Server Availability with Node Manager in Creating and Configuring WebLogic Server Domains, which is available at the following URL:

 http://download.oracle.com/docs/cd/E13222_01/wls/docs70/admin_domain/index.html

Complete the following procedures to configure your WebLogic Integration cluster for automatic restart:

• Step 1. Configure Managed Servers for Remote Start

• Step 2. Configure SSL for Your Administration Server

• Step 3. Configure the Node Manager

• Step 4. Configure Self-Health Monitoring

• Step 5. Start the Node Manager

Step 1. Configure Managed Servers for Remote Start

You must first configure each managed server in your cluster so that it can be started from a remote server.

To configure managed servers for remote start, complete the following steps:

1. In the WebLogic Server Administration Console navigation tree, select the managed server for which you want to configure automatic start.

2. Select the Configuration tab and then the Remote Start tab.

3. Enter information in the fields shown on the Remote Start tab. The information required is specific to the remote server. The fields on this tab are described in Server—>Configuration—>Remote Start in the WebLogic Server Adminstration Console Online Help, which is available at the following URL:

   http://download.oracle.com/docs/cd/E13222_01/wls/docs70/domain_server_config_server-start.html 

Step 2. Configure SSL for Your Administration Server

Because the administration server communicates with the Node Manager using SSL, you must configure SSL for your administration server. Complete the following steps:

1. Add the following line to the administration server startWeblogic command file:

   -Dweblogic.security.SSL.trustedCAKeyStore=WL_HOME\lib\cacerts 

   In the previous line, WL_HOME represents the directory where WebLogic Server is installed. For example, if you installed WebLogic Platform in the default directory, WL_HOME is C:\bea70\weblogic700\server.

2. Copy the democert.pem, demokey.pem and ca.pem files from BEA_HOME\weblogic700\common\templates\domains\wls.jar to the root directory for your domain.

3. In the WebLogic Server Administration Console navigation tree, select the administration server.

4. Select the Connections tab and then the SSL tab.

5. Enter information in fields in the SSL tab as described in Server—>Connections—>SSL in the WebLogic Server Adminstration Console Online Help, which is available at the following URL:

   http://download.oracle.com/docs/cd/E13222_01/wls/docs70/ConsoleHelp/domain_server_connections_ssl.html 

   The democert.pem, demokey.pem and ca.pem files that you copied to the root directory of your domain in step 2 are sample files provided to get you started. You can use them in the following fields when you configure SSL in the Administration Console: Server Certificate File Name, Server Key File Name, Trusted CA File Name.

Step 3. Configure the Node Manager

To configure the Node Manager for a managed server, you must use the WebLogic Server Administration Console to create a machine, specify attributes for the Node Manager on that machine, and deploy the managed server that you configured for remote start on that machine. Specifically, you must complete the following steps:

1. In the Administration Console navigation tree, select Machines.

   The Machines table is displayed in the right pane, showing all the machines defined in the domain.

2. Click Configure a New Machine (or, if you are configuring a UNIX machine, click Configure a New Unix Machine.

   A dialog box is displayed in the right pane, showing the tabs associated with configuring a new machine.

3. Enter a name for the new machine in the Name attribute field and click Create to create a machine instance with the name you specified.

4. On the Node Manager tab, define Node Manager connection and authentication attributes—the address and port on which the Node Manager listens for connections. The default values for address:port are localhost:5555. Click Apply to implement your changes.

5. On the Servers tab, identify the managed server to reside on this machine (that is, a managed server that you configured for remote start in Step 1. Configure Managed Servers for Remote Start).

   You can select an existing server to assign to this machine by selecting the server name in the Available column, and click the appropriate arrow to move the server to the Chosen column.

6. Click Apply to implement your changes.

   The new machine entry now specifies the attributes required for two purposes: to connect to the Node Manager process running on the machine; and to identify which instances of WebLogic Server reside on the machine.

Step 4. Configure Self-Health Monitoring

This step describes how to configure the frequency of your managed server's automated health checks, and the frequency with which the Node Manager checks the servers's health. You can also specify whether the Node Manager automatically stops and restarts the server if the server reaches a failed health state.

Complete the following procedure for each managed server:

1. In the WebLogic Server Administration Console navigation tree, select the managed server for which you configured automatic start in Step 1. Configure Managed Servers for Remote Start.

2. Select the Configuration tab and then the Health Monitoring tab.

3. Specify the following information:

   • Auto Restart—Select Auto Restart to enable the automatic restarting of this managed server by the Node Manager.

   • Auto Kill if Failed—Select Auto Kill if Failed to enable automatic kill of a failed server by the Node Manager.

   • Restart Interval—The number of seconds during which Node Manager restarts are counted. This attribute is used with the Max Restarts within Interval attribute to limit attempts to restart this server. The default value is 300 seconds.

   • Max Restarts within Interval—The maximum number of times the Node Manager can restart this server within the interval specified by the Restart Interval. The default value is 2 restarts.

   • Health Check Interval—Periodicity (in seconds) of the server's health checks. This parameter controls the frequency of the server's self-health monitoring and the Node Manager's health queries.

   • Health Check Timeout—Interval (in seconds) the Node Manager should wait before timing out its health query to the server.

   • Restart Delay Seconds—Interval (in seconds) the Node Manager should wait before restarting the server. This value is used in cases such as when the OS does not allow listen ports to be reused immediately.

Step 5. Start the Node Manager

You can start the Node Manager manually, by running the java command from an operating system prompt, or automatically, by running a script.

Syntax for the Start Node Manager Command

The java command syntax for starting the Node Manager is as follows:

java [java_property=value ...] -D[nodemanager_property=value]
-D[server_property=value] weblogic.nodemanager.NodeManager

Caution: You must start the Node Manager from the same directory in which you start the managed server manually.

In the preceding java command line:

• java_property—Specifies a direct argument to the java executable, such as -ms, or -mx.

  Note: To avoid running out of memory, always specify a minimum heap size of 32 megabytes (-Xms32m) for the Node Manager.

• nodemanager_property—Defines the behavior of the Node Manager process. Table  4-1 describes valid Node Manager properties.

Table 4-1 Values for nodemanager_property Command-Line Argument  

Node Manager Property	Description	Default
weblogic.nodemanager. certificateFile	Specifies the path to the certificate file used for SSL authentication.	./config/democert.pem
weblogic.nodemanager. javaHome	Specifies the Java home directory used by the Node Manager to start managed servers on this machine.	none
weblogic.nodemanager. keyFile	The path to the private key file to be used for SSL communication with the Administration Server.	./config/demokey.pem
weblogic.nodemanager. keyPassword	The password used to access the encrypted private key in the key file.	password
weblogic.ListenAddress	The address at which the Node Manager listens for connection requests. This argument deprecates weblogic.nodemanager.listenAddress.	localhost
weblogic.ListenPort	The number of the TCP port on which the Node Manager listens for connection requests. This argument deprecates weblogic.nodemanager.listenPort.	5555
weblogic.nodemanager. nativeVersionEnabled	For UNIX systems other than Solaris or HP-UX, set this property to false to run the Node Manager in non-native mode.	true
weblogic.nodemanager. reverseDnsEnabled	Specifies whether entries in the trusted hosts file may contain DNS names (instead of IP addresses).	false
weblogic.nodemanager. savedLogsDirectory	Specifies the path for the directory in which the Node Manager stores log files. The Node Manager creates a subdirectory in the savedLogsDirectory named NodeManagerLogs.	./NodeManagerLogs
weblogic.nodemanager. sslHostNameVerificationEnabled	Determines whether or not the Node Manager performs host name verification.	false
weblogic.nodemanager. startTemplate	For UNIX systems only, this property specifies the path of a script file used to start managed servers.	./nodemanager.sh
weblogic.nodemanager. trustedHosts	Specifies the path to the trusted hosts file used by the Node Manager.	./nodemanager.hosts
weblogic.nodemanager. weblogicHome	Specifies the root directory of the WebLogic Server installation. This directory name is used as the default value of -Dweblogic.RootDirectory for servers that do not have a configured root directory.	n/a

 

• server_property—Specifies default values when starting new managed server instances. Table  4-2 describes valid server properties.

Table 4-2 Values for server_property Command Line Argument  

Server Property	Description	Default
bea.home	Specifies the BEA home directory used by managed servers on the current machine.	Specifies the BEA home directory used by managed servers on the current machine.
java.security.policy	Specifies the path to the security policy file that Managed Servers use.	none
weblogic.security.SSL.trustedCAKeyStore	Specifies the path to the KeyStore in which certificates of trusted authorities are contained.	java.security.keyStore

 

The information in the preceding tables, along with details about configuring and running the Node Manager, are available in "Starting Node Manager" in Managed Server Availability with Node Manager in Creating and Configuring WebLogic Server Domains, which is available at the following URL:

http://download.oracle.com/docs/cd/E13222_01/wls/docs70/admin_domain/index.html

Starting the Node Manager When a Machine Is Booted

In a production environment, the Node Manager should start automatically when a machine is booted. You can ensure that it does so by creating a startup script for UNIX systems, or by setting up the Node Manager as a Windows service for Windows systems. For information about how to perform these tasks, see "Starting Node Manager" in Managed Server Availability with Node Manager in Creating and Configuring WebLogic Server Domains, which is available at the following URL:

http://download.oracle.com/docs/cd/E13222_01/wls/docs70/admin_domain/index.html

 

---

Configuring WebLogic Integration for Migration from Failed to Healthy Node

When a managed server fails and is deemed not to be usable, you can migrate the services from the failed managed server to a healthy node in the cluster. Complete the following procedures to configure your system for a manual migration:

• Step 1. Configure Your Cluster

• Step 2. Configure Migratable Targets for JMS Servers and JTA Recovery Service

For instructions about how to perform the migration when a node in your cluster fails, see Manual Migration of WebLogic Integration from Failed to Healthy Node.

Step 1. Configure Your Cluster

Make sure that your WebLogic Integration resources are distributed appropriately and your clustered domain is configured as described in Configuring a Clustered Deployment.

Step 2. Configure Migratable Targets for JMS Servers and JTA Recovery Service

To achieve high availability for your WebLogic Integration deployment, you must configure JTA and JMS servers for failover; the process involves configuring migratable targets for JMS servers and the JTA Recovery Service. You can do this by using the WebLogic Server Administration Console or by editing your config.xml file appropriately.

Complete the following procedure:

1. Create a migratable target for a cluster:

   1. Select the Servers node in the Administration Console navigation tree.

   2. Select the name of a server that resides in the cluster you want to configure.

   3. Choose Control—>Migration Config. in the main console window. A list of servers for which you can select constrained candidate servers for the migratable target is displayed.

   4. In the Available column, select all of the servers capable of hosting migratable services in the cluster. Use the arrow to move these servers to the Chosen column.

      Note: Typically, all the managed servers in the cluster are selected as potential hosts for migratable services.

   5. Click Apply to make your changes to the migratable target.

      The list of servers that you specified is configured in the MigratableTarget element. See the ConstrainedCandidateServers attribute for the MigratableTarget elements in Listing  4-1. (A domain configuration contains one MigratableTarget element for each managed server.)

2. Configure JTA failover:

   1. Make sure that all servers in your cluster have access to the transaction log files for a server. In other words, JTA log files should reside on a shared file system.

   2. Select the Servers node in the Administration Console navigation tree.

   3. Select the name of a server that resides in the cluster you want to configure.

   4. Choose Control—>JTA Migration Config. to create a migratable target for JTA services. A list of servers that you can select as constrained candidate servers for the migratable target is displayed.

   5. In the Available column, select all the servers capable of hosting migratable services in the cluster. Use the arrow to move these servers to the Chosen column.

   6. Click Apply to make your changes to the new migratable target.

Note: JTA and JMS service migration is a two-step process. It is recommended that when you migrate WebLogic Integration resources, you first migrate JTA services, and then migrate JMS services. For more information, see Manual Migration of WebLogic Integration from Failed to Healthy Node.

For more information about configuring migratable targets, see:

• Constraining the Servers to Which the Transaction Recovery Service Can Migrate in "JTA" in WebLogic Server Adminstration Console Online Help, which is available at the following URL:

  http://download.oracle.com/docs/cd/E13222_01/wls/docs70/ConsoleHelp/jta.html

• Server Migration Tasks in "Servers" in WebLogic Server Adminstration Console Online Help, which is available at the following URL

  http://download.oracle.com/docs/cd/E13222_01/wls/docs70/ConsoleHelp/servers.html

Note: Online Help is accessible from the Administration Console, and also at the following URL:

http://download.oracle.com/docs/cd/E13222_01/wls/docs70/ConsoleHelp/index.html

The following listing, an excerpt from a sample config.xml file, shows how to configure migratable targets. It demonstrates the configuration of migratable targets for both JMS servers and the JTA Recovery Service in a clustered WebLogic Integration environment. In this example configuration, the cluster contains two managed servers: MyServer-1 and MyServer-2.

Listing 4-1 Configuration for Migratable Targets

<JMSServer Name="WLCJMSServer-MyServer-1" 
        Store="JMSWLCStore-MyServer-2" Targets="MyServer-1 (migratable)"
        TemporaryTemplate="TemporaryTemplate">
        <JMSQueue JNDIName="com.bea.b2b.OutboundQueue-MyServer-1"
                Name="B2bOutboundQueue-MyServer-2"/>
        <JMSQueue ...
     :
</JMSServer>

<JMSServer Name="WLCJMSServer-MyServer-2" 
        Store="JMSWLCStore-MyServer-2" Targets="MyServer-2 (migratable)"
        TemporaryTemplate="TemporaryTemplate">
        <JMSQueue JNDIName="com.bea.b2b.OutboundQueue-MyServer-2"
                Name="B2bOutboundQueue-MyServer-2"/>
        <JMSQueue ...
     :
</JMSServer>
...

<MigratableTarget Cluster="MyCluster"
        ConstrainedCandidateServers="MyServer-1,MyServer-2"
        Name="MyServer-1 (migratable)"
        Notes="This is a system generated default migratable target for a server.
        Do not delete manually." 
        UserPreferredServer="MyServer-1"/>

<MigratableTarget Cluster="MyCluster"
        ConstrainedCandidateServers="MyServer-1,MyServer-2"
        Name="MyServer-2 (migratable)"
        Notes="This is a system generated default migratable target for a server.
        Do not delete manually." 
        UserPreferredServer="MyServer-2"/>

...

<Server Cluster="MyCluster" JTARecoveryService="MyServer-1"
        ListenAddress="localhost" ListenPort="7901" Name="MyServer-1"
        ServerVersion="7.0.0.0">
        <COM Name="MyServer-1"/><ExecuteQueue Name="default" ThreadCount="15"/>
        <IIOP Name="MyServer-1"/>
        <JTAMigratableTarget Cluster="MyCluster"
        ConstrainedCandidateServers="MyServer-1,MyServer-2 Name="MyServer-1"
        UserPreferredServer="MyServer-1"/>

</Server>

<Server Cluster="MyCluster" JTARecoveryService="MyServer-2"
        ListenAddress="localhost" ListenPort="7901" Name="MyServer-2"
        ServerVersion="7.0.0.0">
        <COM Name="MyServer-2"/><ExecuteQueue Name="default" ThreadCount="15"/>
        <IIOP Name="MyServer-2"/>
        <JTAMigratableTarget Cluster="MyCluster"
        ConstrainedCandidateServers="MyServer-1,MyServer-2 Name="MyServer-2"
        UserPreferredServer="MyServer-2"/>

</Server>

Note the following XML elements in the preceding listing:

• JMS Server—The Target attribute for the JMS server must be the migratable target name for the server. A migratable target is created, by default, for each managed server. (For details, see the following item in this list.)

• MigratableTarget—The migratable target specification for MyServer-2 in MyCluster. As noted in the listing, the migratable target is a system-generated default migratable target for a server. One such target is created for each managed server in a cluster.

  The MigratableTarget element also contains the comma-separated list of servers for ConstrainedCandidateServers. The servers in this list are those that you have specified as capable of acting as JMS server backups. Note that you must include the UserPreferredServer in the list of ConstrainedCandidateServers; the WebLogic Server Administration Console enforces this rule.

• Server—The Server elements include the specification of migratable targets for JTARecoveryService.

 

---

Failover and Recovery

This section describes how WebLogic Integration failover and recovery works in specific scenarios. It contains the following topics:

• Backup and Failover for an Administration Server

• Manual Migration of WebLogic Integration from Failed to Healthy Node

• Recovering a Database

• Recovering JMS Stores

Backup and Failover for an Administration Server

To provide for quick failover in case of an administration server crash or other failure, you may wish to create another instance of the administration server on a different machine that is ready to use if the original server fails.

Because the administration server uses the configuration file (config.xml), security files, and application files to administer the domain, we recommend that you at least keep an archived copy of these files, so that in case of a failure of the administration server you can safely restart the administration server on another machine without interrupting the functioning of the managed servers.

When the administration server for a cluster crashes, the managed servers continue serving requests. However, you cannot change configuration for the cluster or perform new deployment activities until the administration server is recovered. For example, if the administration server for a cluster is not running, you cannot add new nodes to the cluster, deploy new application views, or undeploy the connection factories associated with those application views.

The WebLogic Integration B2B Console is deployed only on the administration server. It is never deployed on the managed servers in a cluster. Therefore B2B integration management and monitoring functions are unavailable when the administration server is down. For example, you cannot add, delete, or modify trading partner information until the administration server is recovered.

If the managed servers are running but the administration server is stopped, you can recover management of the domain without the need to stop and restart the managed servers.

For instructions to restart your administration server when managed servers are running, see Starting and Stopping WebLogic Servers in the BEA WebLogic Server Administration Guide, which is available at the following URL:

 http://download.oracle.com/docs/cd/E13222_01/wls/docs70/adminguide/startstop.html 

Manual Migration of WebLogic Integration from Failed to Healthy Node

This section describes a controlled fail over. That is, source and destination servers are not serving any requests when you migrate services from a failed node to a healthy node in your cluster.

Before attempting to migrate WebLogic Integration from a failed node to a healthy node:

• You should have configured your application (before starting your cluster) as described in Configuring WebLogic Integration for Migration from Failed to Healthy Node.

• Ensure that your source server is not running. If the source server is not down, but only unavailable because of network problems, the services will be copied to the destination server without being removed from the source server, resulting in two simultaneous running versions of the same services, which could cause corruption of the transaction log or of JMS messages.

Note: JTA and JMS service migration is a two-step process. When you migrate WebLogic Integration resources, you should first migrate JTA services, and then migrate JMS services.

You can migrate WebLogic Integration using one of the following methods:

• Using the weblogic.Admin Command-Line Utility

• Using the WebLogic Server Administration Console

Using the weblogic.Admin Command-Line Utility

Use the following command line (weblogic.Admin with the MIGRATE command) to migrate a JMS service or a JTA service to a targeted server within the cluster:

java weblogic.Admin [-url http://hostname:port]
[-username username]
[-password password] 
MIGRATE -jta -migratabletarget (migratabletarget_name|servername)
-destination servername [-sourcedown] [-destinationdown]

In the previous command line:

• -url—Specifies the URL of the administration server, including the number of the TCP port at which WebLogic Server is listening for client requests. The format is hostname:port. The default is localhost:7001.

• -jta—Specifies that the migration is a migration of JTA services. If -jta is not specified, the migration is assumed to be a migration of JMS services.

• -migratabletarget—Names a configuration file identified with the server from which services will migrate. For each server, WebLogic Server automatically creates a migratable target file. (The file is named servername_migratable for JMS and servername for JTA.) This migratable target file is a configuration file that specifies the preferred servers for JMS and JTA services.

• -destination—The name of the server to which the services will migrate.

• -sourcedown—Specifies that the source server is down.

  Warning: As mentioned previously in this section, it is important to ensure that your source server is down when you invoke weblogic.Admin with the MIGRATE command.

• -destinationdown—Use this option if the destination server is down when you do the migration.

For more information about the weblogic.Admin command-line tool, see WebLogic Server Command-Line Interface Reference in BEA WebLogic Server Administration Guide, which is available at the following URL:

 http://download.oracle.com/docs/cd/E13222_01/wls/docs70/adminguide/cli.html

Using the WebLogic Server Administration Console

As an alternative to the weblogic.Admin command-line tool, you can use the WebLogic Server Administration Console to migrate a JTS service or a JMS service to a targeted server within the cluster:

1. Select the Servers node  in the Administration Console navigation tree.

2. Select the name of a server in your cluster.

3. Select the Migrate tab appropriate for the services you are migrating. Note that JTA and JMS service migration is a two-step process. When you migrate WebLogic Integration resources, you should first migrate JTA services, and then migrate JMS services. The Migrate tab you select is determined by the type of services you are migrating:

   • When you migrate JTA services, select the Control tab, followed by the JTA Migrate tab.

   • When you migrate JMS services, select the Control tab, then the Migrate tab.

   Warning: Make sure that your source server is down. Failover for WebLogic Integration is supported only when the source server is down.

4. Select a server from the Destination Server migratable target list.

5. Click Migrate.

   Services running on the server you selected in step 2 are migrated to the destination server you selected.

   The services that are migrated depend on the selection you made in step 3. That is, if you selected the JTA Migrate tab, only the JTA service is migrated to the selected server. If you selected the Migrate tab, only JMS services are migrated to the selected server.

For more information about how to use the Administration Console to migrate JMS or JTA services to a targeted server within the cluster, see Migrating Services to a New Server in "Servers" in WebLogic Server Adminstration Console Online Help.

Recovering a Database

WebLogic Integration does not attempt to recover a crashed database. In the event of a database crash or database shutdown, it may be necessary to restart WebLogic Integration.

For example, if WebLogic Integration and the database are running on the same machine and the machine is unplugged, you should take steps to recover the database before attempting to recover WebLogic Integration.

Recovering JMS Stores

There is no migration of JMS stores after a server crash. WebLogic Integration uses JDBC for JMS stores. That is, it uses JDBC to access JMS JDBC Stores, which can be on another server. WebLogic Integration uses the same database for all nodes in a cluster. If you plan to use separate database instances for each node in your cluster, you should take advantage of any high availability or failover solutions offered by your database vendor. For example, you could use warm database standby in the event of database crash.