Skip navigation.

Deploying WebLogic Platform Applications

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

Configuring the Production Database

When deploying to a production environment, you need to set up an enterprise-level database instance and define the database tables.

This section describes how to configure the WebLogic Portal and WebLogic Integration database tables, and promote the existing data to the target environment.

Note: This section describes configuring databases to meet the requirements of the WebLogic Platform product runtime. Configuring databases for application-specific requirements is beyond the scope of this document. It is assumed that users will ensure that databases are properly set up to support application business logic and application data requirements.

Topics include:


Creating and Preparing a Production Database

To create the database schema and load a database for use with WebLogic Platform applications, perform the following steps:

  1. Review Supported Configurations for WebLogic Platform 8.1 to ensure that your configuration is supported.
  2. Create your vendor database(s).
  3. If you want to use the WebLogic Portal behavior event tracking in a production environment, consider using a separate database for behavior event tracking. For more information, see WebLogic Portal Database Administration Guide.

  4. Prepare the database as required by the WebLogic Platform applications.
  5. BEA provides several sample initialization scripts that need to be modified and run on the vendor database before using the database with WebLogic Platform components. The initialization scripts load the appropriate information into the database tables.

    To prepare the database for WebLogic Platform applications that implement WebLogic Portal features, see the following sections in the WebLogic Portal Database Administration Guide, based on your vendor type:

    To prepare the database for WebLogic Platform applications that implement WebLogic Integration features, see Configuring a Production Database in Managing WebLogic Integration Solutions.


Creating Conversational State Database Tables

If your application uses Web services or Timer controls, WebLogic Workshop uses database tables in the development domain to store the conversational state.

WebLogic Workshop lists the conversational state tables in the /META-INF/wlw-manifest.xml file with the following element name <con:conversation-state-table>.

For each conversational state table element defined in the wlw-manifest.xml file, you must configure a corresponding table in the target database. SQL scripts for defining the conversational state tables for specific databases are described in Step 2 of "To Manually Create Required Resources on the Production Server" in How Do I: Deploy a WebLogic Workshop Application to a Production Server? in the WebLogic Workshop Online Help.

For example, for Oracle, you can use the following SQL script to create the conversational state tables, where <TableName> specifies the name of the table that appears in the <con:conversation-state-table> element.

CG_ID varchar(768) not null,
LAST_ACCESS_TIME number(19,0),

For an example of creating the conversational state database tables using Ant, see Example: How to Create the Conversational State Database Tables Using Ant


Promoting Database Information to the Production Database

The following sections describe the steps required to promote existing database information to the enterprise-level production database.

Promoting WebLogic Portal Datasync Information

WebLogic Portal datasync information consists of user segments, content selectors, campaigns, discounts, and the following property sets: user profile, catalog, event, and session and request. This information must be managed carefully when moving from development to production, and bootstrapped as a separate process during deployment, as described in Steps to Deploy the Application.

In a development environment, portal application datasync information is created and stored as a special Datasync Project within WebLogic Workshop. The files are stored in the META-INF/data directory of the portal application and exposed in WebLogic Workshop in the <portalApplication>/data directory. Datasync data is modified by developers, as well as business users and portal administrators, who can modify user segments, campaigns, placeholders, and content selectors within the WebLogic Administration Portal, and is updated by both WebLogic Workshop and WebLogic Administration Portal.

In a production environment, users need to be able to modify portal definitions using the WebLogic Administration Portal. The method that you use to enable updates to the datasync information in the production environment depends, in part, on how the portal application is deployed, as described in the following table.

Table 4-1 How Datasync Information is Updated Based on Archive Type 

If the portal application is deployed as...


A compressed EAR file

All datasync data must be loaded from the file system into the database so the application can be updated.

When an application is deployed, if the JDBC datasync repository is empty, then the files in the archive will be used to bootstrap, or initialize, the database. Datasync information is stored in the following tables: DATA_SYNC_APPLICATION, DATA_SYNC_ITEM, DATA_SYNC_SCHEMA_URI, and DATA_SYNC_VERSION.

An exploded EAR

The deployed portal application on the Administration Server is the primary store of datasync definitions. You can update the information from any server in the domain using the WebLogic Administration Portal, unless the EAR directory is read-only. If you update the datasync information using a Managed Server, the changes are automatically synchronized with the primary store.


When you initially deploy a WebLogic Portal application to a production environment, as a compressed or exploded archive, the datasync information is bootstrapped, or initialized in the database automatically.

In addition, each portal application contains a Datasync Web application that enables you to view the datasync repository and upload new content. You can access the Datasync Web application using the following URL: http://servername:port/appNameDataSync, where servername and port are the name and port number for the server and appName is the WebLogic Portal application name.

If you need to make incremental updates to the portal data, you can use the Datasync Web application to load new information as part of a redeploy operation or independently, using a separate standalone JAR file. Extreme care must be used so as not to remove or inadvertently modify valid data. You can also retrieve datasync information from the production environment and save it to your staging environment.

For more information about promoting and retrieving datasync information, see Using the Datasync Web Application in the WebLogic Portal Production Operations User Guide.

Promoting LDAP and Portal Database Data

The WebLogic Portal LDAP data includes global roles, enterprise application roles, Web application roles (such as delegated administration and visitor entitlement roles), delegated administration assignments/definitions, and visitor entitlement assignments/definitions. The database data includes any data that is created or modified with the WebLogic Administration Portal.

The WebLogic Portal Propagation Utility enables you to promote application LDAP and database data to the production environment. You can also retrieve LDAP and portal database information from the production environment and save it to your staging environment.

The Propagation Utility is a portal Web application packaged inside an enterprise application archive EAR. The utility must be deployed on both the source domain and the target domain. Contact BEA Support to obtain the latest copy of the Propagation Utility.

In a clustered environment, you should only promote to the Administration Server, which will automatically promote data to the Managed Servers. When propagating database data:

For more information about using the Propagation Utility to promote LDAP and portal database data, see Using the Propagation Utility in the WebLogic Portal Production Operations User Guide.

Promoting WebLogic Integration Application Database Information

In addition to the WebLogic Integration database tables, you might also need to create or promote additional database information based on your application requirements, as defined in the following table.

Table 4-2 Additional WebLogic Integration Production Database Requirements 

If you your application uses...

You must...

Web service or Timer controls

Create the database tables that store conversational state information, as described in Creating Conversational State Database Tables.

Trading partner management data

If the server is not running, use the Bulk Loader to import the information, as described in Using the Trading Partner Bulk Loader in Managing WebLogic Integration Solutions.

If the server is running, use the WebLogic Integration Administration Console to ensure that the running servers have consistent data in their memory cache, as described in Trading Partner Management in Managing WebLogic Integration Solutions.



Example: How to Load the Domain Database Using WLST Offline

The following example illustrates how to load the domain database 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:

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

Open the Template

The following code excerpt opens the domain template that you want to use to load the database.


Configure the JDBC Connection Pool

The following code excerpt configures a predefined JDBC connection pool, cgJMSPool-nonXA using an Oracle database.

existingPoolName = 'cgJMSPool-nonXA'
cd ('/JDBCConnectionPool/' + existingPoolName)

Load the Database

The following code excerpt loads the database for the specified JDBC connection pool.


Close the Template

The following code excerpt closes the template without creating the domain.



Example: How to Load the Application Database Using Ant

The following example illustrates how to load the application database using Ant. For more information about Ant, see:

Define the Properties in the Ant Script

To facilitate automation and reuse of the scripts in different target environments, the code excerpt references properties, such as ${scripts.dir}, that are resolved in a properties file imported to the Ant script. For example, the following properties are defined in a separate properties file,


The file is referenced in the Ant build file as follows:

<property file=""/>

The following code excerpt loads the database data for app1 using the APP1DDL.sql file.

<target name="load-app1-tables">
<antcall target="run-sql-script">
<param name="db.acct" value="app1dbaccnt"/>
<param name="db.script"

The following code excerpt defines the run-sql-script target, which performs an SQL database call.

<target name="run-sql-script">


Example: How to Create the Conversational State Database Tables Using Ant

The PO Sample on the dev2dev Web site provides an example of creating the conversational state database tables using Ant. You can access this article, and download its associated samples files at:

A sample Java utility, ManifestReader, is included in the kit to read the wlw-manifest.xml file and extract the information necessary to create the conversational state database tables. This utility is referenced from a Jython script, create_app_db_scripts, which creates a DDL file with SQL commands to drop and create the conversational state database tables listed in the wlw-manifest.xml file.

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


Skip navigation bar  Back to Top Previous Next