Skip navigation.

eDocs Home > BEA WebLogic Platform 8.1 Documentation > Deploying WebLogic Platform Applications > Creating and Configuring the WebLogic Domain

Deploying WebLogic Platform Applications

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Creating and Configuring the WebLogic Domain

A domain is the basic administration unit for WebLogic Server. To run WebLogic Platform applications, you must create a domain that includes the appropriate WebLogic Platform resources. For more detailed information about WebLogic Server domains, see Overview of WebLogic Server Domains in Configuring and Managing WebLogic Server.

This section lists the tools that you can use to configure a WebLogic domain; provides considerations for configuring WebLogic resources, clusters, and targets; and describes how to set up and start the servers.

Topics include:

The following examples illustrate how to configure a WebLogic domain using scripts. Scripts facilitate controlled and repeatable creation of domains in different target environments.

Note: Before proceeding, review your promotion plan to understand the configuration and targeting requirements of each resource required for your application. For more information about promotion plans, see Planning the Promotion.

 

Tools for Configuring the Target Domain

The tools used to configure the target domain depend on whether you are creating a new target domain or the domain already exists. The tools are summarized in the following table.

Table 3-1 Tools for Configuring the WebLogic Domain 

To...

Do the following...

Create a new WebLogic domain

Create the WebLogic domain and define the required WebLogic resources using the Configuration Wizard or WebLogic Scripting Tool (WLST) Offline. A set of predefined configuration templates is provided to help get you started.

The Configuration Wizard or WLST Offline configures many of the resources for you, as explained in the following sections.

For more information about creating the WebLogic domain using:

After you create a new WebLogic domain, you can update it using one of the methods described below in Update an existing WebLogic domain.

Update an existing WebLogic domain

Update an existing WebLogic domain using one of the following tools:

  • Configuration Wizard, as described in Extending Domains in Creating WebLogic Configurations Using the Configuration Wizard


 

 

Considerations for Configuring and Targeting Resources

When creating a WebLogic domain, you need to configure and specify targets for the system resources. Table 3-2 provides tips for configuring and targeting resources in a production environment.

Note: The Configuration Wizard and WLST Offline have an autoconfiguration feature that streamlines the process of configuring resources in multi-server (e.g., clustered) domains. See Autoconfiguration Using the Configuration Wizard and WLST Offline.

Table 3-2 Considerations for Configuring and Targeting Resources 

Resource

Configuration Considerations

Targeting Considerations

Administration Server

  • Enable the Secure Sockets Layer (SSL) protocol if you wish to enable secure communication between applications connected through the Web. For additional information about security considerations, see Configuring Security.

  • Enable HTTP tunneling to enable a stateful connection by simulating a T3Connection. For more information, see Setting Up WebLogic Server for HTTP Tunneling in "Configuring Web Server Functionality for WebLogic Server" in Configuring and Managing WebLogic Server.

Related topics:

Ensure that the Administration Server IP address is not included in the cluster-wide DNS name. You should not include the Administration Server in the cluster for the following reasons:

  • There is no benefit to doing so. The administrative objects are not clusterable, and will not fail over to another cluster member if the Administration Server fails.

  • The Administration Server should not be configured to handle client requests.

Managed Servers

Related topics:

  • If you added a Managed Server to act as a proxy server, do not include it in the cluster.

  • Avoid deploying server instances in a cluster across a firewall. For more information, see "Firewalls Can Break Multicast Communication" in "One-to-Many Communication Using IP Multicast" in "WebLogic Server Communication in a Cluster" in Communications in a Cluster in Using WebLogic Server Clusters.

Cluster

  • Identify the address and port for multicast communications in the cluster. Multiple clusters on a network may share a multicast address and multicast port combination if necessary. Ensure that the multicast address for a cluster is not used for any purpose other than cluster communications.

  • Failover for entity beans and EJB handles requires that the cluster address be specified as a DNS name that maps to all server instances in the cluster and only server instances in the cluster. For more information, see "Failover for Entity Beans and EJB Handles" in "Replication and Failover for EJBs and RMIs" in Failover and Replication in a Cluster in Using WebLogic Server Clusters.

Related topics:

To review considerations for targeting applications to the cluster, see Application Targets.

Machines

Define machine names if:

  • You are running Node Manager on a machine that does not also host the Administration Server (e.g., a remote machine). In this case, do not set the Node Manager to localhost. If you identify the Listen Address by IP address, you must disable HostNameVerification on Administration Servers and Managed Servers that use Node Manager.

  • You are running more than one server instance per machine so that WebLogic Server does not replicate a session on the same machine.

Related topics:

N/A

JDBC Connection Pools

For each JDBC connection pool, set the database type and related information, such as the host and port information, to specify the production database. For a description of the predefined JDBC configuration information for the WebLogic Platform domain, see Deployment Targeting Reference.

Please note the following:

  • Configure all default connection pools (such as cgPool, cgJMSPool-nonXA, bpmArchPool, and so on).

  • If you change the name of a connection pool, target the existing data sources to the new connection pool.

  • Configure the cgJMSPool-nonXA pool with a nonXA driver.

  • If the reporting data tables are referenced through a different pool than cgPool, then when configuring bpmArchPool, configure it as the Reporting Datastore in the WebLogic Administration Console. For more information, see "Configuring the Reporting DataStore" in System Configuration in Managing WebLogic Integration Solutions.

Related topics:

  • Target to the cluster; you can target the same JDBC connection pool to multiple clusters

  • Target to the Administration Server, if required (for example, if a JMS Server is targeted to the Administration Server)

  • Ensure that you target to the same servers and clusters as the related JDBC data sources

JDBC Data Source/
TX Data Source

Configure one JMS JDBC Store for each server that has a JMS Server defined.

Please note the following:

  • If you are using an XA driver, configure only one Tx Data Source per XA-compliant JDBC connection pool. Note that you can specify multiple JNDI names per Tx Data Source, separated by semicolons.

  • If you are using distributed transactions with non-XA drivers, configure all Tx Data Sources on the same connection pool.

  • If you are using only local transactions, use a Data Source. Otherwise, use a Tx Data Source, but ensure that you suspend and subsequently resume any global transaction currently associated with your thread around your local transaction boundary.

  • If you create multiple domains that share the same database, each domain must reference unique database schemas.

  • You should not edit the JNDI name of the JDBC data sources or Tx data sources.

  • When creating XA domains to support global transactions, review the JDBC configuration guidelines in "Creating XA Domains Using Configuration Templates" in How Do I...? in Creating WebLogic Configurations Using the Configuration Wizard.

  • When creating XA domains to support Oracle RAC, review the JDBC configuration guidelines in "How Do I: Create XA domains with MultiPools and an Oracle RAC Database?" in How Do I...? in Creating WebLogic Configurations Using the Configuration Wizard.

Related topics:

  • Target the same servers and clusters as the related JDBC connection pool

  • You can target the same JDBC data source to multiple clusters

JDBC MultiPools

Create JDBC MultiPools to provide additional load balancing support. MultiPools are not required to be used in a cluster.

  • Target to the cluster; you can target the same JDBC MultiPool to multiple clusters

  • Target to the Administration Server, if required

  • Ensure that you target to the same servers and clusters as the related JDBC data sources and connection pools

JMS Servers

To support JMS failover, target JMS Servers to migratable Managed Servers. This targeting is done automatically, when using the Configuration Wizard or WLST Offline to create the domain.

WebLogic JMS takes advantage of the migration framework implemented in the WebLogic Server core for clustered environments by configuring migratable targets for JMS Servers. This framework enables JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. If you do not configure a migratable target in a cluster, you can still migrate migratable services manually to any server instance in the cluster. For more information, see "Configuring Migratable JMS Server Targets" in Managing WebLogic JMS in Programming WebLogic JMS.

If you add a JMS server when creating a domain, autoconfiguration is not performed. For more information about autoconfiguration, see Autoconfiguration Using the Configuration Wizard and WLST Offline.

Note: WebLogic Integration system queues can be mixed with application queues on the same JMS server.

  • Target one JMS Server per Managed Server, as required

  • Target to the Administration Server, as required (for example, to support WebLogic Portal applications)

JMS Destinations/
Distributed Destinations

  • Create JMS distributed destinations when using a cluster to support high availability and load balancing of physical destinations. When using the Configuration Wizard or WLST Offline, by creating the destinations before you create the cluster, the destination will be configured automatically as a distributed destination with the same JNDI name, and the members will be configured as well.

  • Create one JMS distributed destination member for each Managed Server.

  • Set the RedeliveryLimit to a number of messages that is practical for the environment. By default, a JMS queue will redeliver error messages and warnings an infinite number of times.

  • Create an error destination for undeliverable messages.The error destination can be either a queue or a topic destination. It must be configured on the same JMS server as the destination for which it is defined. If no error destination is configured, then undeliverable messages are simply deleted. You should set the RedeliveryLimit to 0 for a JMS queue. For more information, see JMS Destination Tasks in the Administration Console Online Help.

Note: If you add a JMS Server and subsequently add a JMS destination to it when creating a domain, autoconfiguration is not performed. For more information about autoconfiguration, see Autoconfiguration Using the Configuration Wizard and WLST Offline.

Related topics:

Target to a single cluster.

By default, the Configuration Wizard automatically assigns each JMS distributed destination to the first cluster in the domain. Once the domain is created, you can modify the target using the WebLogic Server Administration Console (or equivalent tool).

JMS File/JDBC Store

  • Define JMS file stores or JDBC stores for each of the Managed Servers and the Administration Server, as required.

  • Configure the JMS JDBC Store with a non-XA JDBC connection pool.

N/A


 

Guidelines for Specifying the Names and Addresses of the Members in a Cluster

When configuring a cluster, you specify name and address information for the cluster and its members—the server instances that comprise it—using either IP addresses or DNS names. Consider the following when configuring the names and addresses:

For more information on the above, see "Identify Names and Addresses" in "Before You Start" in Setting up WebLogic Clusters in Using WebLogic Server Clusters.

Autoconfiguration Using the Configuration Wizard and WLST Offline

The Configuration Wizard and WLST Offline provide an autoconfiguration feature that streamlines the process of configuring resources in multi-server (e.g., clustered) domains.

When you add Managed Servers during domain creation, the Configuration Wizard and WLST Offline will automatically distribute resources on those servers.

When you use WLST Offline to create the queues in a domain, the tool automatically configures each queue as a distributed queue and creates associated member queues on each Managed Server in the cluster. This must be done when creating the domain and before the cluster is created; this feature is not supported when updating an existing domain.

For more information about autoconfiguration, see "Autoconfiguration of Applications and Services" in Configuring Targets in Creating WebLogic Configurations Using the Configuration Wizard.

For a list of default targets for the predefined resources, see:

Note: Autoconfiguration for a cluster only works when you add the cluster when you create a domain, or when you add it when you update a domain using an extension template. This feature is not supported when updating an existing domain (without an extension template).

The Configuration Wizard and WLST Offline support autoconfiguration for single-cluster domains. When creating two clusters, you need to manually correct the targets assigned for the resources, services, and applications, as illustrated in Example: How to Configure a Multi-Cluster Platform Domain Using WLST Offline.

 

Adding Application Resources Required by the WebLogic Workshop Runtime

If Web services are configured to support asynchronous requests, WebLogic Workshop creates asynchronous request and error queues in the development environment to handle the requests. For each pair of queue elements, you must create a pair of corresponding JMS queues on the target server, and associate the asynchronous error queue with the asynchronous queue.

WebLogic Workshop defines the asynchronous queues in the /META-INF/wlw-manifest.xml file with the following element names: <con:async-request-queue> and <con:async-request-error-queue>. The queues are named using the following format: web_app.queue.AsyncDispatcher and web_app.queue.AsyncDispatcher_error, where web_app specifies the name of the Web application.

If the target domain is clustered, you must configure the queues as distributed queues. If you are using multiple clusters, you must create an additional set of queues for each cluster.

Note: When you use WLST Offline to create the queues in a domain, the tool automatically configures each queue as a distributed queue and creates associated member queues on each Managed Server in the cluster. This must be done when creating the domain and before the cluster is created; this feature is not supported when updating an existing domain. For more information, see Autoconfiguration Using the Configuration Wizard and WLST Offline.

For an example of setting asynchronous dispatcher queues, see Configure the Asynchronous Dispatcher Queues Required by the Application.

You can configure the server dispatch policy for asynchronous requests using the <async-dispatch-policy> element in the wlw-config.xml configuration file. The <async-dispatch-policy> element associates a project's asynchronous requests with a server-defined dispatch policy. The dispatch policy designates which server execute thread pool the EJB should run in. The value provided for this element is used to generate an <async-dispatch-policy> entry in the weblogic-ejb-jar.xml configuration file for the AsyncDispatcher and AsyncErrorDispatcher message-driven beans. For more information, see the <asynch-dispatch-policy> element description in WebLogic Workshop Online Help.

 

Configuring Servers to Start in Production Mode

Set the startup mode to prod. For information about the differences between development and production modes, see Differences Between Configuration Startup Modes in Creating WebLogic Configurations Using the Configuration Wizard. For an example of configuring the server startup mode, see Set Domain Options.

 

Setting the SDK

Set the SDK to one that is supported on the platform you are using, and that is optimized for production-level performance. Ensure that you configure the same SDK across all server instances in a cluster. For a list of the Java SDKs that are supported for a specific platform, see Supported Configurations for WebLogic Platform 8.1. For an example of configuring the SDK see Set Domain Options.

 

Setting Up the Managed Servers on Remote Machines

Once you have configured the target domain, you need to set up the Managed Server directories on remote machines and optionally configure Node Manager.

Setting Up the Managed Server Directories

To set up the Managed Server directories that run on remote machines:

  1. If you will not be using Node Manager to manage a remote Managed Server, create a domain on that server. Ensure that you configure the same JDK across all server instances in a cluster and that you set the mode to prod.

    2. If you will be using Node Managed, a remote Managed Server directory does not require the complete set of files that are located in the Administration Server directory, as the Administration Server maintains the configuration information for all Managed Servers within a domain.

  2. If you use WebLogic Workshop wlw-runtime-config.xml configuration file, you must copy it to the root directory of each Managed Server in the cluster.
  3. Ensure the key stores for the following security services are made available to the Managed Server.

    4. Security Service Requiring Key Stores

    Description

    WebLogic Server security

    Enables SSL transport traffic. For more information about WebLgoic Server security, see:

    "Secure Sockets Layer (SSL)" in Security Fundamentals in Introduction to WebLogic Security

    Configuring SSL in Managing WebLogic Security

    Web service security

    Enables message-level security for Web services. You must also ensure that the related WSSE policy files are made available to the Managed Servers. For more information about Web service security, see:

    Web Service Security in WebLogic Workshop Online Help

    "Overview of Web Services Security" in Configuring Security in Programming WebLogic Web Services

    Building a Secure Web Service using BEA's WebLogic Workshop at: http://dev2dev.bea.com/products/wlworkshop81/articles/sws_wlw.jsp

    WSRP security

    Enables security for the Web Services for Remote Portlets (WSRP) feature of WebLogic Portal. By default, the WSRP security keystore is stored in the wsrpKeystore.jks file. For more information about WSRP security, see Establishing WSRP Security in Using WSRP With WebLogic Portal.

    Trading Partner security

    Enables the security for Trading Partners. For more information, see Trading Partner Integration Security in Introducing Trading Partner Integration.


     

Configuring the Managed Server Start Attributes

You need to configure the ServerStart attributes for each Managed Server if you want to start the Managed Server remotely using Node Manager.

The following table defines the attributes that need to be set for each Managed Server. For information about the start attributes that can be set for a server using the WebLogic Server Administration Console, see ServerStart in WebLogic Server Configuration Reference.

Table 3-3 ServerStart Attributes for the Managed Server 

Attribute

Description

Arguments

Startup arguments to use when starting this server.

BEA Home

Location of the WebLogic Platform installation.

ClassPath

Classpath to use when starting the server. For sample classpath settings for default domains, see Table 3-4.

JavaHome

Java home directory.

Name

Name of the configuration.

Notes

Optional information that you can include to describe the configuration.

Password

Password of the username used to boot the server and perform server health monitoring.

RootDirectory

Root directory to be used to start the server.

SecurityPolicyFile

Security policy file to use when starting this server.

Username

Username to use when booting the server and performing server health monitoring.


 

The following table identifies the required CLASSPATH settings for the default domains.

Note: The classpath value may differ from that defined in the table, depending on your environment. To access the CLASSPATH information for your environment, start the Administration Server and capture the CLASSPATH information that displays to the command window (stdout).

Table 3-4 CLASSPATH Settings for Default Domains 

Domain

CLASSPATH Value

Basic WebLogic Platform

%WL_HOME%\server\lib\weblogic_knex_patch.jar;
%WL_HOME%\common\lib\log4j.jar;
%WL_HOME%\server\lib\debugging.jar;
%WL_HOME%\server\lib\knex.jar;
%WL_HOME%\javelin\lib\javelin.jar;
%WL_HOME%\server\lib\wlw-lang.jar;
%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;
%WL_HOME%\server\lib\weblogic.jar;
%WL_HOME%\server\lib\ant\ant.jar;
%JAVA_HOME%\jre\lib\rt.jar;
%WL_HOME%\server\lib\webserviceclient.jar;
%WL_HOME%\server\lib\webserviceclient+ssl.jar;
%WL_HOME%\server\lib\xbean.jar;
%WL_HOME%\server\lib\wlxbean.jar;
%WL_HOME%\server\lib\xqrl.jar;
%WL_HOME%\server\lib\netui\netui-compiler.jar;
%WL_HOME%\server\lib\wli.jar;
%WL_HOME%\server\lib\fop.jar;
%WL_HOME%\integration\adapters\sample\lib\sample-eis.jar;
%WL_HOME%\portal\lib\wps_system.jar

Basic WebLogic Server

%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;
%WL_HOME%\server\lib\weblogic.jar;
%JAVA_HOME%\jre\lib\rt.jar;
%WL_HOME%\server\lib\webservices.jar

For more information, see Setting the CLASSPATH in WebLogic Server Command Reference.

Basic WebLogic Portal

%WL_HOME%\server\lib\weblogic_knex_patch.jar;
%WL_HOME%\common\lib\log4j.jar;
%WL_HOME%\server\lib\debugging.jar;
%WL_HOME%\server\lib\knex.jar;
%WL_HOME%\javelin\lib\javelin.jar;
%WL_HOME%\server\lib\wlw-lang.jar;
%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;
%WL_HOME%\server\lib\weblogic.jar;
%WL_HOME%\server\lib\ant\ant.jar;
%JAVA_HOME%\jre\lib\rt.jar;
%WL_HOME%\server\lib\webserviceclient.jar;
%WL_HOME%\server\lib\webserviceclient+ssl.jar;
%WL_HOME%\server\lib\xbean.jar;
%WL_HOME%\server\lib\wlxbean.jar;
%WL_HOME%\server\lib\xqrl.jar;
%WL_HOME%\server\lib\netui\netui-compiler.jar;
%WL_HOME%\server\lib\wli.jar;
%WL_HOME%\server\lib\fop.jar;
%WL_HOME%\integration\adapters\sample\lib\sample-eis.jar;
%WL_HOME%\portal\lib\wps_system.jar

Basic WebLogic Integration

%WL_HOME%\server\lib\weblogic_knex_patch.jar;
%WL_HOME%\common\lib\log4j.jar;
%WL_HOME%\server\lib\debugging.jar;
%WL_HOME%\server\lib\knex.jar;
%WL_HOME%\javelin\lib\javelin.jar;
%WL_HOME%\server\lib\wlw-lang.jar;
%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;
%WL_HOME%\server\lib\weblogic.jar;
%WL_HOME%\server\lib\ant\ant.jar;
%JAVA_HOME%\jre\lib\rt.jar;
%WL_HOME%\server\lib\webserviceclient.jar;
%WL_HOME%\server\lib\webserviceclient+ssl.jar;
%WL_HOME%\server\lib\xbean.jar;
%WL_HOME%\server\lib\wlxbean.jar;
%WL_HOME%\server\lib\xqrl.jar;
%WL_HOME%\server\lib\netui\netui-compiler.jar;
%WL_HOME%\server\lib\wli.jar;
%WL_HOME%\server\lib\fop.jar;
%WL_HOME%\integration\adapters\sample\lib\sample-eis.jar

Basic WebLogic Workshop

%WL_HOME%\server\lib\weblogic_knex_patch.jar;
%WL_HOME%\common\lib\log4j.jar;
%WL_HOME%\server\lib\debugging.jar;
%WL_HOME%\server\lib\knex.jar;
%WL_HOME%\javelin\lib\javelin.jar;
%WL_HOME%\server\lib\wlw-lang.jar;
%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;
%WL_HOME%\server\lib\weblogic.jar;
%WL_HOME%\server\lib\ant\ant.jar;
%JAVA_HOME%\jre\lib\rt.jar;
%WL_HOME%\server\lib\webserviceclient.jar;
%WL_HOME%\server\lib\webserviceclient+ssl.jar;
%WL_HOME%\server\lib\xbean.jar;
%WL_HOME%\server\lib\wlxbean.jar;
%WL_HOME%\server\lib\xqrl.jar;
%WL_HOME%\server\lib\netui\netui-compiler.jar;
%WL_HOME%\server\lib\wli.jar;
%WL_HOME%\server\lib\fop.jar;
%WL_HOME%\integration\adapters\sample\lib\sample-eis.jar


 

Configuring Node Manager

Node Manager enables you to perform common operations for a Managed Server, regardless of its location with respect to its Administration Server. You can use Node Manager to perform the following operations:

To take advantage of Node Manager capabilities, you must run a Node Manager process on each machine that hosts Managed Servers, and configure Node Manager to:

For complete details about each of the steps required to configure Node Manager in a production environment, see "Configuration Checklist (Production Environment)" in "Configuring Node Manager" in Configuring, Stopping, and Starting Node Manager in Configuring and Managing WebLogic Server.

 

Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline

The following example illustrates how to create a WebLogic Platform domain that contains a single cluster, as illustrated in Single-Cluster Platform Domain Example, using WLST Offline.

Steps include:

For more information about WLST Offline, see the documentation and examples provided with the WLST Offline kit at the following URL: https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97

Define WLST Variables

You can define variables in the WLST Offline script and reference them using the WLST Offline commands to facilitate reuse of the scripts in different target environments. For example, you can "hard-code" the variable values within the script or pass the values to the WLST Offline script from the command line.

For example, if you define the following variables within the WLST Offline script to specify the WebLogic home directory, domain name, and domain template name:

weblogic_home="/bea/weblogic81"
domain_template="platform.jar"

You can then reference the variables in the script instead of the values. For example:

readTemplate(weblogic_home + '/common/templates/domains'+ domain_template)

Note: For readability, the following code excerpts use actual values and not variables.

Open the Template for Domain Creation

The following code excerpt opens the Basic WebLogic Platform Domain template for domain creation and sets the name of the domain using the cmo variable. The cmo variable stores the Current Management Object, which is set to the configuration bean instance to which you navigate using WLST Offline—in this case the root of all configuration management objects, DomainMBean.

readTemplate('/bea/weblogic81/common/templates/domains/platform.jar')

Configure an Administrative Username and Password

The following code excerpt sets the password for the pre-configured administrative account.

cd('/Security/platform/User/weblogic')
cmo.setPassword('password')

Configure the Administration Server

The following code excerpt configures the Administration Server by setting the listen address and port, enabling SSL, and setting the SSL port. To review considerations for configuring the Administration Server, see Considerations for Configuring and Targeting Resources.

cd('/Server/cgServer')
cmo.setListenAddress('host')
cmo.setListenPort(9301)

cd('SSL/cgServer')
cmo.setEnabled(1)
cmo.setListenPort(9302)

Configure the Asynchronous Dispatcher Queues Required by the Application

The following code excerpt configures a set of asynchronous dispatcher queues and their associated error queues, as required by the application. To determine if you need to create asynchronous dispatcher queues, review the contents of the wlw-manifest.xml file, which provides information about the server resources referenced by the application, as described in Adding Application Resources Required by the WebLogic Workshop Runtime.

Tip

By creating the asynchronous queues before you create the cluster, the queue will be configured automatically as a distributed queue with the same JNDI name.

 

  queueNames = 'IntApp.queue.AsyncDispatcher', \
    'PortApp.queue.AsyncDispatcher'

  # Predefined  JMS Server included in the domain template
  cd ('/JMSServer/cgJMSServer') 

  for qName in queueNames:
    errqName = qName + "_error"
    
    # Create asynchronous dispatcher error queue
    create(errqName, 'JMSQueue')
    cd ('JMSQueue/' + errqName)
    cmo.setJNDIName(errq	Name)
    errqMBean = cmo
    cd ('../..')

    # Create asynchronous dispatcher queue
    create(qName, 'JMSQueue')
    cd ('JMSQueue/' + qName)
    cmo.setJNDIName(qName)

    # Associate asynchronous dispatcher error queue
    cmo.setErrorDestination(errqMBean)
    cd ('../..')

Configure the JDBC Connection Pools

The following code excerpt configures the database type and related information to specify the production database for each of the four default JDBC connection pools, including bpmArchPool, cgJMSPool-nonXA, cgPool, and portalPool. To review considerations for configuring JDBC connection pools, see Considerations for Configuring and Targeting Resources.

cd ('/JDBCConnectionPool')
nonXApools = 'cgJMSPool-nonXA',
for pool in nonXApools:
   cd (pool)
   cmo.setDriverName('oracle.jdbc.driver.OracleDriver')
   cmo.setUserName('username')
   cmo.setPassword('password')
   cmo.setDbmsHost('myDBHost')
   cmo.setDbmsPort('1521')
   cmo.setDbmsName('myDB')
   cd ('..')
XApools = 'cgPool', 'bpmArchPool', 'portalPool'
for pool in XApools:
  cd (pool)
  cmo.setDriverName('oracle.jdbc.xa.client.OracleXADataSource')
  cmo.setUserName(`user')
  cmo.setPassword(`password')
  cmo.setDbmsHost('myDBHost')
  cmo.setDbmsPort('5321')
  cmo.setDbmsName('myDB')
  cmo.setSupportsLocalTransaction(1)
  cmo.setKeepXAConnTillTxComplete(1)
  cd ('..')

Configure the Cluster, Managed Servers, and Machines

The following code excerpt performs the following tasks:

cd ('/')
# Define the servers
clusterConfig = 'platformCluster','multicast_addr',9101
ms1 = 'ms1','host1',9111,9112,'machine1'
ms2 = 'ms2','host2',9121,9122,'machine2'
ms3 = 'ms3','host3',9131,9132,'machine1'
ms4 = 'ms4','host4',9141,9142,'machine2'
mss = ms1, ms2, ms3, ms4

#Create the cluster
cl_name, mc_addr, mc_port = clusterConfig
cluster = create(cl_name, 'Cluster')

#Configure the machines
machine = None
prev_ms_machine = ""
cl_addr = ""
for msConfig in mss:
   ms_name, ms_addr, ms_port, ms_ssl_port, ms_machine = msConfig
   if ms_machine != "" and ms_machine != prev_ms_machine:
     prev_ms_machine = ms_machine
     machine = create(ms_machine, 'Machine')

     #Configure the Node Manager name and listen address
     cd('Machine/' + ms_machine + '/NodeManager/' + ms_machine)
     cmo.setName(ms_machine)
     cmo.setListenAddress(ms_addr)
     cd('../../../..')

   #Configure the Managed Server, target it to a machine 
   ms = create(ms_name,'Server')
   
   cd('Server/' + ms_name)
   cmo.setListenAddress(ms_addr)
   cmo.setListenPort(ms_port)
   if machine != None:
      cmo.setMachine(machine)
   cd('SSL/' + ms_name)
   cmo.setEnabled(1)
   cmo.setListenPort(ms_ssl_port)
   cd('../..')
   assign('Server', ms_name, 'Cluster', cl_name)

   # Configure Node Manager StartServer properties
   create(ms_name, 'ServerStart')
   cd('ServerStart/' + ms_name)
   cmo.setBeaHome('/bea')
   cmo.setJavaHome('/bea/weblogic81/jrockit81sp4_142_05')
   cmo.setRootDirectory('/bea/user_projects/domains/platform')
   # See Table 3-4 for CLASSPATH settings
   cmo.setClassPath(`classpath')
   cmo.setSecurityPolicyFile('/bea/weblogic81/server/lib/weblogic.policy')
   cmo.setArguments('-Xms512m -Xmx512m -da -Dwlw.iterativeDev=false
 -Dwlw.testConsole=false -Dwlw.logErrorsToConsole=true -Dweblogic.ProductionModeEnabled=true')
   cmo.setUsername('user')
   cmo.setPassword('password')

   cd('../..')
   # Tune execution threads
   cd('ExecuteQueue/weblogic.kernel.Default')
   cmo.setThreadCount(15)
   cmo.setThreadsIncrease(5)

   cd('../..')
   # Accumulate addresses and ports for setting cluster address
   cl_addr = cl_addr + ms_addr + ':' + str(ms_port) + ','

# Set the cluster address, multicast address, and multicast port
cl_addr = cl_addr[:-1] # slice off trailing','
cluster.setClusterAddress(cl_addr)
cluster.setMulticastAddress(mc_addr)
cluster.setMulticastPort(mc_port)

Configure the Web Proxy Server

The following code excerpt configures the Web proxy server. For more information, see Using Load Balancers and Web Proxy Servers.

create('platproxy','Server')
cd('/Server/platproxy')
cmo.setListenAddress('host')
cmo.setListenPort(9431)
# Set this server as the proxy server for the cluster
cd ('/Cluster/platformcluster')
cmo.setProxyServer('platproxy')

Set Domain Options

The following code excerpt sets the following domain options:

setOption('OverwriteDomain','true')
setOption('CreateStartMenu','false')
setOption('ServerStartMode','prod')
setOption('JavaHome','/bea/weblogic81/jrockit81sp4_142_05')

Write the Domain and Close the Template

The following code excerpt writes the domain to the specified directory and closes the configuration template.

writeDomain('/bea/user_projects/domains/platform')
closeTemplate()

 

Example: How to Configure a Multi-Domain Environment Using WLST Offline

This section describes how to configure an environment that consists of two domains—a Basic WebLogic Integration Domain and a Basic WebLogic Portal Domain—as illustrated in Multi-Domain Example.

Steps include:

For more information about using WLST Offline, see the documentation and examples provided with the WLST Offline kit at the following URL: https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97

Create the Basic WebLogic Integration Domain

The process used to configure the Basic WebLogic Integration domain using WLST Offline is similar to the process illustrated in Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline, with the following exceptions:

Create the Basic WebLogic Portal Domain

The process used to configure the Basic WebLogic Portal domain using WLST Offline is similar to the process illustrated in Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline, with the following exceptions:

 

Example: How to Configure a Multi-Domain Environment Using the Configuration Wizard in Silent Mode

Clusterizing End2End on WebLogic Platform 8.1 on the dev2dev Web site provides an example of configuring a target domain using the Configuration Wizard in silent mode. You can access this article, and download its associated samples files at: http://dev2dev.bea.com/products/wlplatform81/articles/clusterizing_E2E.jsp

Note: Code samples and utilities are posted on dev2dev for your convenience. They are not products supported by BEA.

This article describes how to promote and extend the WebLogic Platform Tour from a development to a production environment, and describes how to configure the following two domains using the Configuration Wizard silent mode:

Note: This environment is depicted in Multi-Domain Example.

To view the Configuration Wizard silent mode scripts, download the E2ECluster.zip file that contains the sample code and extract the following files:

Note: The scripts are designed to be called from an Ant script. They reference properties, such as @DOMAIN_TEMPLATE@, that are resolved in a properties file imported to the Ant script. Using Ant scripting and properties in this way facilitates automation and reuse of the scripts in different target environments.

 

Example: How to Configure a Multi-Cluster Platform Domain Using WLST Offline

When you want to configure more than one cluster in a WebLogic Platform domain, you must explicitly retarget some of the resources, services, and applications. You must do this because of the following:

Tip

A strategy for configuring two clusters in a WebLogic Platform domain is to leverage autoconfiguration for a single cluster as much as possible. You can designate the first cluster in the domain to be the WebLogic Integration cluster and the second cluster to be the WebLogic Portal cluster. Because a WebLogic Integration cluster requires JMS queues and topics, this strategy leverages autoconfiguration to set up these resources. You then target the remaining resources, services, and applications correctly. And, finally, you edit the config.xml file to add JMS resources for the second, WebLogic Portal cluster.

The following example illustrates how to create a WebLogic Platform domain that contains two clusters, as illustrated in Multi-Cluster Platform Domain Example, using WLST Offline.

Steps include:

Note: For readability, the following code excerpts use actual values and not variables. For information about using WLST variables, see Define WLST Variables.

For more information about using WLST Offline, see the documentation and examples provided with the WLST Offline kit at the following URL: https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97

Create a Domain With Two Clusters

The process used to configure a multi-cluster domain using WLST Offline is similar to the process illustrated in Example: How to Configure a Single-Cluster Platform Domain Using WLST Offline, except that you need to create two clusters rather than a single cluster.

For example, the following code excerpt performs the following tasks:

Compare this code excerpt to the equivalent excerpt for the single cluster domain, described in Configure the Cluster, Managed Servers, and Machines.

cd ('/')
# Define the servers
wli_ms1 = 'wlims1','host1',9111,9112,'wlimachine1'
wli_ms2 = 'wlims2','host2',9121,9122,'wlimachine2'
wli_mss = wli_ms1,wli_ms2
wli_clusterConfig = 'wlicluster','multicast1_addr',9101,wli_mss

wlp_ms1 = 'wlpms1','host3',9211,9212,'wlpmachine1'
wlp_ms2 = 'wlpms2','host4',9221,9222,'wlpmachine2'
wlp_mss = wlp_ms1,wlp_ms2
wlp_clusterConfig = 'wlpcluster','multicast2_addr',9201,wlp_mss

#Create the two clusters
clusterConfigs = wli_clusterConfig,wlp_clusterConfig

machines_created = ""
for clusterConfig in clusterConfigs:
  cl_name, mc_addr, mc_port,mss = clusterConfig
  cluster = create(cl_name, 'Cluster')

  #Configure the machines
  machine = None
  cl_addr = ""

  for msConfig in mss:
    ms_name, ms_addr, ms_port, ms_ssl_port, ms_machine = msConfig

    # check for existence of ms_machine
    create_this_machine = 'yes'
    if machines_created == "":
      machines_created = ms_machine
    else:
      if machines_created.find(ms_machine) == -1:
        machines_created = machines_created + "," + ms_machine
      else:
        create_this_machine = 'no'

    if ms_machine != "" and create_this_machine == 'yes'
      machine = create(ms_machine, 'Machine')

      #Configure the Node Manager name and listen address
      cd('Machine/' + ms_machine + '/NodeManager/' + ms_machine)
      cmo.setName(ms_machine)
      cmo.setListenAddress(ms_addr)
      cd('../../../..')

    #Configure the Managed Server, target it to a machine   
    ms = create(ms_name,'Server')
    ms.setListenAddress(ms_addr)
    ms.setListenPort(ms_port)

    if machine != None:
      ms.setMachine(machine)
  
    cd('Server/' + ms_name + '/SSL/' + ms_name)
    cmo.setEnabled(1)
    cmo.setListenPort(ms_ssl_port)
    cd('../../../..')

    assign('Server', ms_name, 'Cluster', cl_name)

    # Configure Node Manager StartServer properties
    cd('Server/' + ms_name)
    create(ms_name, 'ServerStart')
    cd('ServerStart/' + ms_name)
    cmo.setBeaHome('/bea')
    cmo.setJavaHome('/bea/weblogic81/jrockit81sp4_142_05')
    cmo.setRootDirectory('/bea/user_projects/domains/platform')
    # See Table 3-4 for CLASSPATH settings
    cmo.setClassPath('classpath') 
    cmo.setSecurityPolicyFile('/bea/weblogic81/server/lib/weblogic.policy')
    cmo.setArguments('-Xms512m -Xmx512m -da -Dwlw.iterativeDev=false
 -Dwlw.testConsole=false -Dwlw.logErrorsToConsole=true -Dweblogic.ProductionModeEnabled=true')
    cmo.setUsername('user')
    cmo.setPassword('password')
    cd('../../../..')
    # Accumulate addresses and ports for setting cluster address
    cl_addr = cl_addr + ms_addr + ':' + str(ms_port) + ','

# Set the cluster address, multicast address, and multicast port
cl_addr = cl_addr[:-1] # slice off trailing ','
cluster.setClusterAddress(cl_addr)
cluster.setMulticastAddress(mc_addr)
cluster.setMulticastPort(mc_port)

#Configure the JMS JDBC Store for the WebLogic Portal Cluster
cd('/JDBCConnectionPool/cgJMSPool-nonXA')
connPoolMBean = cmo
cd('/JMSTemplate/TemporaryTmplt')
jmsTemplateMBean = cmo
cd('/')
jdbcstorePrefix = "cgJMSStore_wlp_auto_"
a = ['1', '2']
for n in a:
  storename = jdbcstorePrefix + n
  store = create(storename,"JMSJDBCStore")
  store.setConnectionPool(connPoolMBean)    
  store.setPrefixName('wlp_' + n)

Correct Targets for the Resources, Services, and Applications

The Configuration Wizard and WLST Offline support autoconfiguration for single-cluster domains only. When creating two clusters, you need to manually correct the targets assigned for the resources, services, and applications, as described in the following procedure. (For more information about autoconfiguration, see Autoconfiguration Using the Configuration Wizard and WLST Offline.

Note: For default targeting requirements, refer to Deployment Targeting Reference - Single Cluster WebLogic Platform Domain. To identify resources, services, and application product components, see Default Domain Resource Reference - By Product Component.

  1. Correct the targets for the system resources.

    2. For example, unassign the portalPool and bpmArchPool JDBC connection pools from the WebLogic Integration and WebLogic Portal clusters, respectively.

    unassign('JDBCConnectionPool', 'portalPool', 'Target', wliClusterName)
    unassign('JDBCConnectionPool', 'bpmArchPool', 'Target', wlpClusterName)
  2. Correct the targets for the WebLogic services.

    3. For example, unassign the WebLogic Integration startup and shutdown classes from the WebLogic Portal cluster.

    WLIStartupShutdownClasses = (('ShutdownClass','WLI Shutdown Class'),\
       ('StartupClass','WLI Startup Class'),\
       ('StartupClass','WLI Post-Activation Startup Class'))
    for classNVpair in WLIStartupShutdownClasses:
       cname,cvalue=classNVpair
       unassign(cname, cvalue, 'Target', wlpClusterName)
  3. Correct the targets for the applications.
    1. Unassign all applications from the following resources: Administration Server, First Managed Server defined for the WebLogic Integration cluster, and WebLogic Integration and WebLogic Portal clusters

      2. For example:

      unassignAll('Application', 'Target', adminName)
      unassignAll('Application', 'Target', wlims1Name)
      unassignAll('Application', 'Target', wliClusterName)
      unassignAll('Application', 'Target', wlpClusterName)
    2. Re-assign the applications to the appropriate targets.

      3. WLST Offline does not support resource names that contain period (".") or slash ("/") characters. Therefore, you must temporarily substitute all period (".") and slash ("/") characters in application names when assigning them to targets. Once assigned, you must restore the original application name for the application to function properly within the domain. For example, in the following excerpt, the following temporary substitutions have been made:

    • .workshop/worklist/EJB/ProjectBeans has been temporarily renamed as follows:
      _workshop_worklist_EJB_ProjectBeans
    • .workshop/worklist/EJB/GenericStateless has been temporarily renamed as follows:
      _workshop_worklist_EJB_GenericStateless

      • For example:

      assign('Application', 'B2BDefaultWebApp', 'Target', adminName)
      assign('Application', 'WLI AI RAR Upload', 'Target', adminName)
      assign('Application', 'wliconsole', 'Target', adminName)
      assign('Application', 'B2BDefaultWebApp', 'Target', wliClusterName)
      assign('Application', '_workshop_worklist_EJB_ProjectBeans',\ 'Target', wliClusterName)
      assign('Application', '_workshop_worklist_EJB_GenericStateless',\ 'Target', wliClusterName)
      assign('Application', 'worklist', 'Target', wliClusterName)
      assign('Application', 'WLIAdmin', 'Target', wliClusterName)
      assign('Application', 'WLI Admin Helper', 'Target', wliClusterName)
      ...

Manually Edit the config.xml File to Add JMS Resources for the Second Cluster

Manually edit the config.xml file to create the following resources for the second cluster, in this example, the WebLogic Portal cluster:

 

Skip navigation bar  Back to Top Previous Next