| products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 

Deploying Solutions

 Previous Next Contents Index View as PDF  

Understanding WebLogic Integration Clusters

The following sections describe how WebLogic Integration is configured and deployed in a clustered environment. It contains the following topics:


Understanding WebLogic Integration Clusters

Clustering allows WebLogic Integration to run on a group of servers that can be managed as a single unit. In a clustered environment, multiple machines share the processing load. WebLogic Integration provides load balancing so that resource requests are distributed proportionately across all machines. A WebLogic Integration deployment can use clustering and load balancing to improve scalability by distributing the workload across nodes. Clustering provides a deployment platform that is more scalable than a single server.

A WebLogic Server domain consists of only one administration server, and one or more managed servers. The managed servers in a WebLogic Integration domain can be grouped in a cluster. When you configure WebLogic Integration clusterable resources, you target the resources to a named cluster. The advantage of specifying a cluster as the target for resource deployment is that it makes it possible to increase capacity dynamically by adding managed servers to your cluster.

The topics in this section provide the information you need to configure WebLogic Integration in a clustered environment. Although some background information about how WebLogic Server supports clustering is provided, the focus is on procedures that are specific to configuring WebLogic Integration for a clustered environment.

Before proceeding, we recommend that you review the following sections of the WebLogic Server documentation to obtain a more in-depth understanding of clustering:


Designing a Clustered Deployment

The following sections provide the information you need to design a clustered deployment:

Introducing WebLogic Integration Domains

Before you begin designing the architecture for your clustered domain, you need to learn how WebLogic Server clusters operate.

Creating Domains

Domain and cluster creation are simplified by a Configuration Wizard that lets you generate domains from domain templates based on WebLogic Integration, business process management (BPM), or enterprise application integration (EAI) functionality. Based on user queries, the Configuration Wizard generates a domain, server, and enterprise application with the appropriate components preconfigured and assets included. For information about the templates available for different domains, see the Configuration Wizard Template Reference, which is available at the following URL:

For information about creating WebLogic Integration domains using the Configuration Wizard, see Configuring a Clustered Deployment.

Clustered Servers

A server can be either a managed server or an administration server. A WebLogic Server running the administration service is called an administration server and hosts the Administration Console. In a domain with multiple WebLogic Servers, only one server is the administration server; the other servers are called managed servers. Each managed server obtains its configuration at startup from the administration server.

For general information, see Using WebLogic Server Clusters in the WebLogic Server documentation set, at the following URL:

For details about basic, multi-tiered, and proxy architectures that are recommended, see Cluster Architectures in Using WebLogic Server Clusters.

Note About Cluster and Management Domains

Although it is possible for a WebLogic Server management domain and cluster domain to be different (that is, it is possible for WebLogic Server clusters to have nodes that belong to different management domains), you must design your WebLogic Integration deployment such that the cluster domain equals the management domain.

Deploying WebLogic Integration Resources

For each server in a clustered domain, you can configure a variety of attributes that define the functionality of the server in the domain. These attributes are configured using the Servers node in the Administration Console.

This section describes WebLogic Integration resources and how they can be partitioned and distributed in a cluster. It contains the following topics:

Clusterable Resources

Table  2-1 describes the WebLogic Integration deployment resources. It contains the following information:

The following table describes the WebLogic Integration deployment resources.

Table 2-1 WebLogic Integration Deployment Resources  

Resource Group

(Single Node/Clusterable)

Resource Name

Administration Console Navigation


BPM master components

(Single node)

WLI-BPM Plugin Manager




BPM components


WLI-BPM initialization



WLI-BPM Server



WLI-BPM Event Processor MDBs



User-defined Event Processor MDBs






Connection Factories




Connection Factories



Tx Data Sources


B2B integration administration

(Single node: Administration Server)

B2B console



Web Applications

WLI-B2B Startup


Note: Deployed to the administration server and the clustered managed servers.



B2B integration components


WLI-B2B Startup





Startup & Shutdown



Tx Data Sources




Web Applications




WLI-B2B RN BPM Plug-in



WLI-B2B ebXML BPM Plug-in






Connection Factories




Connection Factories


Application integration administration

(Single node: Administration Server)2




Applications—>WLI-AI RAR Upload


Application integration components


WLI-AI Server



Application View Management Console


Deployments—>Web Applications—>wlai

WLI-AI Event Processor



WLI-AI Async Processor



WLI-AI BPM Plug-in



WLI-AI BPM Plug-in Help



Web Applications



Connection Factories


Application integration event adapter

(Depends on the adapter3)




Application integration service adapter

(Depends on the adapter3)

BEA . . . yyy . . . ADK_RAR1

Deployments—>Applications—> BEA . . . yyy . . . ADK_RAR1,4

BEA . . . yyy . . . ADK_WEB1

Deployments—>Applications—> BEA . . . yyy . . . ADK_WEB


Data Integration components


WLI-DI BPM Plug-in



WLI-DI BPM Plug-in Help


Deployments—>Web Applications


Resources that must be located on all servers in the domain


WLI-Repository (respository-ejb.jar)


WLI Error Listener (wli-errorlistener-






Java mail sessions used for the BPM Send E-mail action.




Connection Pools

Used for all database connections in WebLogic Integration.

Name represents a user-defined package or resource group.

You need to deploy wlai-admin.ear only when you deploy WebLogic Integration to a cluster; do not deploy it when you deploy in a single-node environment. For more information about the application integration administration component, see Load Balancing Application Integration Functions in a Cluster.

For example, the DBMS sample event adapter is deployed to a single node. For more information, see the documentation for the adapter you are using.

Event and service adapters reside in a single EAR file but they are deployed separately and are listed as separate resources in the WebLogic Server Administration Console. For more information, see the following section, Two-Phase Deployment of WebLogic Integration..


Two-Phase Deployment of WebLogic Integration

It is essential to have all WebLogic Integration application components deployed before your system attempts to process messages. To guarantee this, specify the TwoPhase attribute when you deploy WebLogic Integration. The following excerpt from a sample config.xml file illustrates an Application element, which specifies deployment of WebLogic Integration.

Listing 2-1 Deploying the WebLogic Integration Application

<Domain Name="MyCluster">
     <Application Name="WebLogic Integration" Path="WLI_HOME/lib"

Distribution Guidelines

A WebLogic Integration cluster deployment conforms to the following guidelines:

Targeting Resources to a Cluster

As shown in Deploying WebLogic Integration Resources, most WebLogic Integration resources are deployed to all the servers in a cluster. This deployment is specified in the configuration file (config.xml) for your domain.

You can use the WebLogic Server Administration Console to target components to nodes in your cluster. For more information, see Configuring a Clustered Deployment.

The following listing is an excerpt from the configuration file for a clustered domain, in which BPM components are specified. The listing shows how these components are targeted to a cluster named MyCluster.

Listing 2-2 Targeting WebLogic Integration Components to a Cluster

<Application Deployed="true" Name="WebLogic Integration"
       Path="C:/bea/weblogic700/integration/lib" TwoPhase="true">
       <EJBComponent Name="WLI Repository" Targets="MyCluster"
         URI="repository-ejb.jar" />
       <EJBComponent Name="WLI-BPM Server" Targets="MyCluster"
         URI="wlpi-ejb.jar" />
       <EJBComponent Name="WLI-BPM Event Processor"
         Targets="MyCluster" URI="wlpi-mdb-ejb.jar" />
       <EJBComponent Name="WLI-BPM Master Components"
Targets="MyServer-1" URI="wlpi-master-ejb.jar" />
       <EJBComponent Name="WLI-BPM Initialization"
         Targets="MyCluster" URI="bpm-init-ejb.jar"/>

In the preceding listing, note that all BPM components are targeted to the cluster, except the WLI-BPM master components (wlpi-master-ejb.jar). As specified in Table  2-1, the WLI-BPM master components must be deployed to one server in the cluster (in this case, MyServer-1).

Deployment Order in WebLogic Integration Application

The following file specifies all the components of WebLogic Integration:


Because the components are deployed in the order in which they are listed in application.xml, you must not change the order in which they are listed in the file. The specified order is critical because it reflects dependencies among components. EJBs and BPM plug-ins are included in this application because they must be accessible to BPM functions.

If you deploy custom resources (such as custom plug-ins, EJBs, message-driven beans, and so on) to a WebLogic Integration application, you must edit the application.xml file to specify your new component.

Warning: You can specify a custom resource as the last entry in the application.xml file, unless your new resource is a plug-in to BPM, in which case, you must specify the new component as the penultimate (second to last) entry in the file. That is, it must be defined immediately before the bpm-init-ejb.jar module, but after all the other modules in the application.

The bpm-init-ejb.jar module must be the last module specified in application.xml:




Deploying The Default Web Application

By default, when you create a domain based on any of the WebLogic Integration domain templates, it contains configuration for a Web server deployed to the administration server. The Web server configuration, in turn, specifies the default Web application (DefaultWebApp).

The deployment descriptor (web.xml) for this default Web application resides in the following location:


In the preceding line, DOMAIN_HOME represents the pathname of the domain you created.

A Web Application contains an application's resources, such as servlets, Java Server Pages (JSPs), JSP tag libraries, and any static resources such as HTML pages and image files.

Deploying Custom JSP and HTML Pages

If you deploy custom JSP or HTML pages as part of your WebLogic Integration application, your custom JSP and HTML pages should reside in the following directory:


In the preceding path, DOMAIN_HOME represents the root directory of the custom domain you created using the Configuration Wizard (see Step 2. Create a WebLogic Integration Domain), and node represents the name of a WebLogic Server instance in your cluster.

You must configure a Web server for each node in your cluster. The following excerpt from a config.xml file shows:

(Information of interest is in bold text for emphasis.)

Listing 2-3 WebServer Element for Managed Server in a config.xml File

<Server Name="managedserver1" ...
<WebServer Name="managedserver1" DefaultWebApp="DefaultWebApp_node"
       HttpsKeepAliveSecs="120" KeepAliveSecs="60"
<Application Deployed="true" Name="DefaultWebApp_node"
       StagedTargets="" TwoPhase="false">
       <WebAppComponent IndexDirectoryEnabled="true"
       Name="DefaultWebApp_node" Targets="managedserver1"

In the preceding listing, note that the DefaultWebApp attribute in the WebServer element references the default Web application component. The configuration for the default Web application is also shown in the preceding listing. It, in turn, references the directory where your JSP and HTML pages reside (node represents the name of a server in your cluster).

For more information about deploying Web applications, see Assembling and Configuring Web Applications, which is available at the following URL:

Note About Administration Servers

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.


Load Balancing in a WebLogic Integration Cluster

One of the goals of clustering your WebLogic Integration application is to achieve scalability. In order for a cluster to be scalable, each server must be fully utilized. Load balancing distributes the workload—>proportionally among all the servers in a cluster so that each server can run at full capacity. The following sections describe load balancing for various functional areas in a WebLogic Integration cluster:

Load Balancing WebLogic Server Functions in a Cluster

WebLogic Server supports load balancing for HTTP session states and clustered objects. For more information, see Communications in a Cluster in Using WebLogic Server Clusters, which is available at the following URL:

Load Balancing BPM Functions in a Cluster

BPM workflows require an event queue for processing event-based workflows. For more information, see Business Process Management Resources.

Event Queues and Associated Pools

The following types of pools are associated with each BPM event queue:

The following figure illustrates an event queue and the pools associated with it.

Figure 2-1 Event Queue and Associated Pools


The unordered event listener message-driven beans process messages in a nondeterministic order. Although messages are read in first-in, first-out (FIFO) order, messages can be processed out of order after they are read, depending on thread scheduling and the load at the time they are processed.

The ordered event listener message-driven beans guarantee that, for a particular order key (WLPIOrderKey), messages are processed in an ordered sequence. To achieve this, a single event listener message-driven bean in a cluster must be configured to process messages for WLPIOrderKey.

An order key must be an integer value, and the value must be the same for each event that you want processed in the order in which it is received. Ordered messages must also be sent to the same JMS queue. The message producer is responsible for delivering the messages in the queue in the correct order.

WLPIOrderKey is a custom JMS property that BPM uses. You can set this property in the WebLogic Integration Studio or you can set it programmatically:

A single JAR file (wlpi-mdb-ejb.jar) contains both ordered and unordered event listener message-driven beans for a particular queue. The message-driven beans provided in the wlpi-mdb-ejb.jar file consume messages from the default EventQueue. This JAR file must be targeted to the cluster.

BPM load balancing is achieved by deploying wlpi-mdb-ejb.jar to the cluster. This JAR file contains five ordered event listener message-driven beans and five unordered event listener message-driven beans. The message-driven beans consume messages from distributed destinations for validating and nonvalidating event queues. The distributed destinations contain one physical destination per JMS server, and one JMS server per instance of WebLogic Server. A single message producer on a distributed queue is bound to a single physical destination. Message-driven beans are bound to the physical destination in the server on which they are deployed (server affinity). Making use of server affinity means that a message is kept within the same JVM and WebLogic Server instance while it is being processed. Therefore, ordered messages sent by a given producer to a distributed destination are guaranteed to be consumed by the same ordered message-driven bean. This process guarantees ordered delivery of messages.

Creating New Pools

If you have sufficient processing power on a single server, you can increase the pool size and range for event listener message-driven beans in the wlpi-mdb-ejb.jar file, as described in Do You Have Enough Message-Driven Beans?.

For information about creating a custom JMS queue and event listeners for that queue, see "Configuring a Custom Java Message Service Queue" in Customizing WebLogic Integration in Starting, Stopping, and Customizing BEA WebLogic Integration.

Requirements for Load Balancing BPM Functionality

When you are load balancing BPM functionality in a WebLogic Integration cluster, consider the following requirements:

Timed Events

Like the message-driven beans for the event and validating event queues, timed event listeners are also deployed to the cluster in the wlpi-mdb-ejb.jar file. These message-driven beans pull work from com.bea.wli.bpm.TimerQueue.

Timed events are implemented using JMS delivery times. They are executed by two types of pools:

Load Balancing Application Integration Functions in a Cluster

It is possible to configure a homogenous cluster (that is, one in which all resources have the same managed server targets), subject to any constraints in the adapters themselves.

In contrast to BPM functionality, it is possible to load balance application integration functionality in a cluster using the default JMS queues and servers.

In a clustered deployment, you must deploy a single EJB (wlai-admin-ejb.jar) to the administration server only. This EJB is deployed from the wlai-admin.ear archive file. (See Table  2-1 in Deploying WebLogic Integration Resources.)

Note: The wlai-admin-ejb.jar is required only in a clustered deployment. Therefore do not deploy wlai-admin.ear when you deploy WebLogic Integration to a single server.

The following code excerpt is from a config.xml file for a clustered domain. It shows the deployment specification for the wlai-admin.ear file in the cluster.

Listing 2-4 Deploying the wlai-admin EJB in the config.xml File

<Application Name="WLI-AI Admin Server Only"
Path="WLI_HOME/lib/wlai-admin.ear" TwoPhase="true">
<EJBComponent Name="WLI-AI RAR Upload" Targets="admin_server_name"

Load Balancing B2B Integration Functions in a Cluster

B2B integration functionality does not require partitioning of work within a cluster; to support such functionality, you should configure a completely homogenous cluster. In other words, all B2B resources (JMS consumers, destinations, and producers) are available on all nodes in the cluster.

It is possible to load balance B2B integration functionality in a cluster using the default JMS queues and servers.

B2B integration resources are deployed homogeneously to all nodes in a cluster. Therefore, when shutdown of the B2B engine is requested, the B2B engine on all nodes in a cluster are shut down. It is not possible to shut down the B2B engine on a single node in a cluster; you must first remove the node from the cluster.

By using distributed destinations, WebLogic JMS balances the messaging load across multiple physical destinations, which can result in better use of resources and improved response times. The WebLogic JMS load-balancing algorithm determines the physical destinations (in a distributed destination set) to which messages are sent, as well as the physical destinations to which consumers are assigned. Message-driven beans are bound to the physical destination in the server on which they are deployed (server affinity).When a message is sent to a particular physical destination (or queue) on a particular server, the message is processed by that server.

B2B integration functionality takes advantage of the server affinity heuristic and in-memory caching in a clustered environment. During B2B message processing, the B2B decoder enqueues the message envelope for a B2B message into the BPM JMS event queue. A BPM message-driven bean dequeues the message and a B2B-specific plug-in is invoked to further process the message. The B2B-specific plug-in uses the message ID, the trading partner, and the delivery channel (URI) to retrieve the message payload from the MessageStore in-memory cache. Therefore, B2B integration functions can make use of in-memory caching, resulting in improved performance.


High Availability in a WebLogic Integration Cluster

Message-driven beans consume messages from JMS destinations. A number of message-driven beans are deployed on each WebLogic Integration destination. For a complete list of WebLogic Integration destinations (JMS queues and topics), see JMS Servers and JMS Destinations.

Highly Available JMS

The ability to configure multiple physical destinations as members of a single distributed destination set provides a highly available implementation of WebLogic JMS. Specifically, for each node in a cluster, an administrator should configure one physical destination for a distributed destination. If one node in the cluster fails, making the physical destination for that node unavailable, then other physical destinations configured as members of the distributed destination can provide service to JMS producers and consumers.

In the case of those destinations that must be deployed as singletons in a clustered environment, high availability is still achieved because a JMS server and all of its destinations can be migrated to another WebLogic Server within a cluster. However, destinations deployed as singletons are less desirable because the migration required for them is manual.

Message-driven beans consume messages from distributed destinations. Distributed destinations contain one physical destination for each instance of WebLogic Server. A single message producer on a distributed queue is bound to a single physical destination. Message-driven beans are bound to the physical destination in the server on which they are deployed (server affinity). Therefore, ordered messages sent by a given producer to a distributed destination are guaranteed to be consumed by the same ordered message-driven bean. This process guarantees ordered delivery of messages, and makes possible the B2B caching described in Load Balancing B2B Integration Functions in a Cluster.

When a managed server fails in a cluster, the message-driven beans from the failed server are migrated atomically, but not automatically, to prevent multiple message processing.

The following sections describe examples of how WebLogic Integration uses distributed destinations and server affinity to achieve high availability in a clustered deployment:

High Availability for Asynchronous Service Requests

WLAI_ASYNC_REQUEST_QUEUE and WLAI_ASYNC_RESPONSE_QUEUE queues are deployed as distributed destinations in a WebLogic Integration cluster, and the Asynchronous Service Request Processor is the associated message-driven EJB, which is deployed to all servers in a cluster. Asynchronous requests and responses are processed even after the JMS server that accepted them crashes.

If a physical queue fails before an asynchronous service request is received by a message-driven bean, the request remains unavailable until the physical queue comes back on line. The same scenario is true for asynchronous service responses.

For information about processing of synchronous and asynchronous invocations for application integration functions, see Application Integration Resources.

High Availability for Event Forwarding

Application integration adapters generate events that are consumed by BPM functionality or by WebLogic Workshop. Events are forwarded from an adapter to a JMS queue (WLAI_EVENT_QUEUE).

To obtain metadata about events, an event router communicates with a WebLogic Integration instance, using HTTP. If you want to achieve load balancing and high availability for event router callback communication, but you are not using a DNS name for your cluster address, you must set the wlai.clusterFrontEndHostAndPort property. For information about this property, see Setting the wlai.clusterFrontEndHostAndPort Property (Optional).

The WLAI_EVENT_QUEUE is a distributed destination containing multiple physical destinations. A message-driven bean (the AI Event Processor) listens on the WLAI_EVENT_QUEUE distributed destination. Because multiple servers participate in the processing of messages for this queue, a single server failure can be accommodated. For information about how adapter events are processed by WebLogic Integration, see Events.


Understanding JMS Resources

This section describes how to configure JMS resources for your WebLogic Integration application in a clustered environment. Specifically, it describes how to configure the following resources:

JMS resources are configured in the WebLogic Server Administration Console. To start the console, see "Starting the WebLogic Server Administration Console" in WebLogic Integration Administration and Design Tools in Starting, Stopping, and Customizing BEA WebLogic Integration.

JMS Connection Factories

The following JMS connection factories are configured in a WebLogic Integration domain that contains an administration server and clustered managed servers:

The following listing shows a sample specification for deployment of JMS connection factories in a WebLogic Integration cluster. Note the Targets and JNDI names for the connection factories, which are shown in bold.

Listing 2-5 JMSConnectionFactory Elements in the config.xml File

<!--Application Integration Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="false"
       DefaultDeliveryMode="Persistent" DefaultPriority="4"
       MessagesMaximum="10" Name="WLIJMSConnectionFactory"
       OverrunPolicy="KeepOld" Targets="MyCluster"
<!--B2B Integration Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="true"
       Name="B2BTopicFactory" Targets="MyServer-1"
<JMSConnectionFactory AllowCloseInOnMessage="true"
       Name="RNQueueFactory" Targets="MyCluster"
<!--BPM Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="true"
       Name="wlpiFactory" Targets="MyCluster"
<JMSConnectionFactory AllowCloseInOnMessage="true"
       Name="wlpiQueueFactory" Targets="MyCluster"


A JMS JDBC store must be defined for each JMS server in your deployment.

The following listing is an excerpt from a config.xml file, which defines JMS JDBC stores for a cluster (MyCluster) containing two managed servers (MyServer-1 and MyServer-2), administered by the myserver administration server. Note that the target for the connection pool lists both the cluster and the administration server.

Listing 2-6 JMSJDBCStore Elements in the config.xml File

<JMSJDBCStore ConnectionPool="wliPool"
       Name="JMSWLCStore-MyServer-1" PrefixName="MyServer_1"/>
<JMSJDBCStore ConnectionPool="wliPool"
       Name="JMSWLCStore-MyServer-2" PrefixName="MyServer_2"/>
<JMSJDBCStore ConnectionPool="wliPool" Name="JMSWLCStore-myserver"
<JDBCConnectionPool CapacityIncrement="1"
DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="1"
LoginDelaySeconds="1" MaxCapacity="15" Name="wliPool"
RefreshMinutes="0" ShrinkPeriodMinutes="15"
ShrinkingEnabled="true" Targets="myserver,MyCluster"

JMS Servers and JMS Destinations

One JMS server must be configured for each managed server in your cluster, and one for the administration server. (Only one destination (the B2B Topic) is deployed to the JMS server configured for the administration server, as shown in Table  2-2.) We recommend the following naming convention for your JMS servers: WLI_JMSServer_node, such that node represents the name of the server on which the JMS server is deployed.

The following table describes the destinations (JMS queues and topics) used by WebLogic Integration and specifies whether they are deployed as single or distributed destinations.

Table 2-2 JMS Destinations


Distributed or Single














Single managed server


Administration server only















The com.bea.wli.FailedEventQueue destination is used by all components of WebLogic Integration. It should be used as the error destination for any JMS destination that consumes messages in a JTA UserTransaction. For more information about the error queue, see Error Destination.


The following listing is an excerpt from a config.xml file. It shows selected JMS elements for a clustered configuration containing two managed servers (MyServer-1 and MyServer-2), administered by an administration server (myserver).

Listing 2-7 JMSServer Elements in the config.xml File

<!--Distributed Destinations-->
<JMSDistributedQueue JNDIName="com.bea.wli.bpm.EventQueue"
Name="WLI_BPM_Event" Targets="MyCluster">
        <JMSDistributedQueueMember JMSQueue="WLI_BPM_Event_MyServer-1"
       <JMSDistributedQueueMember JMSQueue="WLI_BPM_Event_MyServer-2"
<!--Administration Server-->
<JMSServer Name="WLI_JMSServer_myserver"
       Store="JMSWLCStore-myserver" Targets="myserver"
       <JMSTemplate Name="TemporaryTemplate"/>
       <JMSTopic JNDIName="com.bea.wli.b2b.server.B2BTopic"
<!--Managed Server-->
<JMSServer Name="WLI_JMSServer_MyServer-1"
Store="WLI_JMSJDBCStore_MyServer-1" Targets="MyServer-1 (migratable)"
        <JMSQueue JNDIName="com.bea.wli.bpm.Event.MyServer-1"
       Name="WLI_BPM_Event_MyServer-1" StoreEnabled="true"
       <JMSTopic JNDIName="com.bea.wli.bpm.EventTopic"
       Name="wlpiEvent" StoreEnabled="false"/>

Note the following information in the preceding listing:

Error Destination

The com.bea.wli.FailedEventQueue is the error destination for any JMS destination that consumes messages in a JTA User Transaction. For example, it is the error destination for the EventQueue, ValidatingEventQueue, and TimerQueue. Messages that do not find a target BPM workflow instance and those that fail a number of retries, at one minute intervals, are sent to the FailedEventQueue. (The default number of retry attempts is 10, but you can configure a different number.) When a JMS message arrives on the FailedEventQueue, a message-driven bean (com.bea.wli.common.errorlistener.ErrorListenerBean), which listens on the queue, writes log entries to the WebLogic Server log.

You can specify the number of retry attempts to be allowed by configuring attributes for redelivery in the WLI_JMSTemplate-node, which is the JMS template used by the error queue. The error queue is a distributed destination, and the redelivery attributes are configured for a node-specific physical destination, which is named WLI-FailedEvent-node. (For these names, node represents the name of a WebLogic Server instance in your cluster):

  1. In the WebLogic Server Administration Console navigation tree, choose Services—>JMS—>Templates—>WLI_JMSTemplate-node.

  2. Select the Configuration tab, followed by the Redelivery tab.

  3. Specify the redelivery attributes and the appropriate WLI-FailedEvent-node for which to configure those attributes.

  4. Click Apply.

For more information about configuring redelivery attributes for a JMS template, see JMS Template—>Configuration—>Redelivery in "JMS" in the Adminstration Console Online Help, which is available at the following URL: 

In addition, you have the option of creating your own custom message listener, adding it to the classpath, and referencing it in the FailedEventQueue message-driven bean deployment descriptor. By doing so, you can configure your system to persist error messages.

Creating a Store and Associating It with a Connection Pool

To create a store and associate it with a connection pool, complete the following steps:

  1. In the Administration Console navigation tree, go to the Services—>JMS—>Stores node and select Configure a new JMSJDBCStore. The Configuration tab should be selected by default.

  2. In the Name field, enter the name by which you want to identify this store.

    Every JMS server has its own JMSJDBCStore. Every managed server has its own JMS server. For instructions on creating such a server, see Creating a JMS Server and Associating It with the Store.

  3. In the Connection Pool field, select the connection pool that you want to use.

  4. In the Prefix Name field, enter the prefix to be appended (for example, WLI-AI).

  5. Click Create.

Creating a JMS Server and Associating It with the Store

To create a JMS server and associate it with a JMSJDBCStore, complete the following steps:

  1. In the Administration Console navigation tree, go to the Services—>JMS—>Servers node and select Configure a new JMSServer.

  2. In the Name field, enter the name by which you want to identify this JMS server.

  3. In the Store field, select the JMSJDBCStore with which you want to associate this JMS server.

  4. In the Temporary Template field, select one of the available templates:

    Note: You can access the properties for each of these JMS templates through the Services—>JMS—>Templates node in the Administration Console.

  5. Click Create.


Deploying Adapters

Run-time application integration features (synchronous service invocations, asynchronous service invocations, and events), described in Application Integration Resources, can be clustered for scalability and high availability. Application integration features that are available at design time (Application Views and Connection Factories) can be clustered for scalability but not for high availability, meaning that you cannot deploy or undeploy (edit) Application Views if any server in a cluster is not running. In other words, you can deploy and undeploy (edit) only in a healthy cluster.

An application integration adapter is typically composed of three components:

The resource adapter (RAR) file and the design time Web application (WAR) file should be deployed to the cluster. However the event generator Web application (WAR) file should, in most cases, be deployed to a single node in the cluster. (For specific information, see the documentation for the adapter you are using.)

For example, when a DBMS adapter is used, the DbmsEventRouter Web application must be targeted to a single node in a cluster. The following listing is an excerpt from a config.xml file. It shows an Application element that specifies the configuration for deployment of a DBMS adapter.

Listing 2-8 Configuration for Deploying an Application Integration Adapter

<Application Deployed="true" Name="BEA_WLS_DBMS_ADK" Path="/bea/weblogic700/integration/adapters/dbms/lib/
BEA_WLS_DBMS_ADK.ear" StagingMode="stage" TwoPhase="true">
        <ConnectorComponent Name="BEA_WLS_DBMS_ADK" Targets="MyCluster" URI="BEA_WLS_DBMS_ADK.rar"/>
        <WebAppComponent Name="BEA_WLS_DBMS_ADK_Web" Targets="MyCluster" URI="BEA_WLS_DBMS_ADK_Web.war"/>
        <WebAppComponent Name="DbmsEventRouter" Targets="MyServer-1" URI="BEA_WLS_DBMS_ADK_EventRouter.war"/>

Note the following information in the preceding listing. Information of interest is highlighted in bold text for emphasis:

Configuring Adapters for Deployment

WebLogic Integration domains created by the Configuration Wizard define the configuration for resource adapters. In the configuration created by the Configuration Wizard, the three components of an adapter are targeted for deployment to the cluster. However, as described in the preceding section (specifically, Listing  2-8), the event generator Web application (WAR) file should, in most cases, be deployed to a single node in the cluster. You must modify your domain configuration to meet this requirement. For information about how to modify the domain configuration, see Step 5. Configure Event Router WAR File for Adapters.

You can also deploy resource adapters after you start the servers in your cluster. For information about how to set up and start your clustered deployment, see Configuring a Clustered Deployment. For information about using the weblogic.Deployer command-line utility or the WebLogic Server Administration Console to deploy resource adapters to a running cluster, see Deploying Resource Adapters.

For more information about deploying adapters in the WebLogic Integration environment, see Deploying Adapters in Developing Adapters.


Back to Top Previous Next