Deploying WebLogic Platform Applications
|
 |
 |
|
 |
 |
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.
To create the database schema and load a database for use with WebLogic Platform applications, perform the following steps:
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.
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.
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.
CREATE TABLE <TableName>(
CG_ID varchar(768) not null,
LAST_ACCESS_TIME number(19,0),
CG_DATA BLOB,
PRIMARY KEY (CG_ID)
)
For an example of creating the conversational state database tables using Ant, see Example: How to Create the Conversational State Database Tables Using Ant
The following sections describe the steps required to promote existing database information to the enterprise-level production database.
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.
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.
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.
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.
|
Create the database tables that store conversational state information, as described in Creating Conversational State Database Tables. |
|
|
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. |
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: https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=97
Note: For readability, the following code excerpts use actual values and not variables. For information about using WLST variables, see Define WLST Variables.
The following code excerpt opens the domain template that you want to use to load the database.
readTemplate('/bea/weblogic81/common/templates/domains/platform.jar')
The following code excerpt configures a predefined JDBC connection pool, cgJMSPool-nonXA using an Oracle database.
existingPoolName = 'cgJMSPool-nonXA'
cd ('/JDBCConnectionPool/' + existingPoolName)
cmo.setDriverName('oracle.jdbc.driver.OracleDriver')
cmo.setUserName('user')
cmo.setPassword('password')
cmo.setDbmsHost('myDBhost')
cmo.setDbmsPort('1521')
cmo.setDbmsName('myDB')
The following code excerpt loads the database for the specified JDBC connection pool.
loadDB('9i',existingPoolName)
The following code excerpt closes the template without creating the domain.
closeTemplate()
The following example illustrates how to load the application database using Ant. For more information about Ant, see:
http://ant.apache.orgTo 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, myprops.properties:
scripts.dir=scripts
app1dbaccnt.type=9i
db.host=host
db.port=1531
db.dbname=ora920
db.driver=oracle.jdbc.driver.OracleDriver
db.sqltask.url=jdbc:oracle:thin:@${db.host}:${db.port}:${db.dbname}
db.delimiter=;
db.user=user
db.password=password
The file is referenced in the Ant build file as follows:
<property file="myprops.properties"/>
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"
value="${scripts.dir}/db/${app1dbaccnt.type}/APP1DDL.sql"/>
</antcall>
</target>
The following code excerpt defines the run-sql-script target, which performs an SQL database call.
<target name="run-sql-script">
<sql
driver="${db.driver}"
url="${db.sqltask.url}"
delimiter="${db.delimiter}"
userid="${db.user}"
password="${db.password}"
onerror="continue"
autocommit="true"
classpathref="basic.classpath"
print="true"
src="${db.script}"/>
</target>
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:https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=76
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.
|
|
|