WebLogic Commerce Servers Configuration

 

WebLogic Commerce Servers Configuration includes the following topics:

Configuring Startup Files

Configuring Properties Files

Using the Cloudscape database with WLCS

Using an Oracle database with WLCS

Setting properties in the weblogic.properties file

Setting properties in the weblogiccommerce.properties file

Setting Up an Oracle Database

Recreating the Cloudscape Database

Setting Up the Reference Implementation Document Management System (DMS)

Installing and Configuring the WLCS/Interwoven TeamSite Interface

Installing and Configuring Documentum

Documentum bean environment variables

After installing WebLogic Commerce Servers, you might need to configure files, setup a database, set up the Document Management System (DMS), or perform other tweaks to the default installation. This document describes the changes to make to configure the server.

Note: Most default settings will work fine out of the box, especially if you run the server with the Cloudscape database and reference implementation DMS that ships with WLCS. If you use another database or DMS or if you need configuration information for setting up connection pools, servlets, security, etc., this document includes configuration information for these tasks.

 

---

Configuring Startup Files

WLCS uses two files to set environment variables when it starts the server: sethome.bat (sethome.sh for UNIX) and StartCommerce.bat (StartCommerce.sh for UNIX). Use StartCommerce to start WLCS.

• StartCommerce.bat (StartCommerce.sh for UNIX)

  • This file starts the server. It calls sethome.bat or sethome.sh to configure the environment settings and then starts the server. You don't need to make changes to the StartCommerce.bat or StartCommerce.sh file.

• sethome.bat (NT in <install-dir>\bin\win32) and sethome.sh (UNIX systems in <install-dir>/bin/solaris2)

  Note: This file contains most of the environment settings and is called by the StartCommerce script. The installation program configures the settings during installation. You should not have to change it if you use the Cloudscape database that ships with WLCS 2.0.1.

  • If you have problems with the server starting, ensure WL_COMMERCE_HOME is set to the directory that contains the WLCS install. Also ensure the DB_CLASSPATH property points to your database drivers and the JDK_HOME points to your JDK. All other settings should work as shipped.

 

---

Configuring Properties Files

This section contains detailed reference information for configuring the properties files for WLCS. The topics here discuss setting up connection pools, servlets, and portals, deploying EJBs, and setting up security realms, in addition to other WLCS properties.

Note: To run the Cloudscape database with the reference DMS that ships with the system, you should not have to configure any of the properties files here. The configuration options in this document cover database setup information for Oracle, DMS setup for Interwoven and Documentum products, and a variety of smaller topics relating to Service Manager entries, realms, security, etc.

The weblogic.properties and weblogiccommerce.properties files that ship with the system have corollary files with configuration information for the Cloudscape and Oracle databases. These corollary files, weblogic-cmp.properties and weblogiccommerce-cmp.properties for Cloudscape and weblogic-bmp.properties and weblogiccommerce-bmp.properties for Oracle, contain the default configuration information for each database. These stock files serve as templates for your weblogic.properties and weblogiccommerce.properties files.

Note: The weblogic.properties and weblogiccommerce.properties files that ship with the system contain the default Cloudscape database configuration information that is also contained in the corollary files, weblogic-cmp.properties and weblogiccommerce-cmp.properties files. If you use the Cloudscape database, you don't need to edit the weblogic.properties and weblogiccommerce.properties files.

Using the Cloudscape database with WLCS

Out of the box, the weblogic.properties and weblogiccommerce.properties files contain the same information as the weblogic-cmp.properties and weblogiccommerce-cmp.properties since the Cloudscape database runs the example applications.

Note: If you plan to use the Cloudscape database, you should not need to make modifications to the weblogic.properties and weblogiccommerce.properties files.

Using an Oracle database with WLCS

If you use an Oracle database, edit the following properties files, weblogic-bmp.properties and weblogiccommerce-bmp.properties, then copy the files over the weblogic.properties and weblogiccommerce.properties files.

Note: Basically, you need to rename weblogic-bmp.properties and weblogiccommerce-bmp.properties to weblogic.properties and weblogiccommerce.properties and make sure they're in the directory specified in the StartCommerce file (by default, the installation directory). This will enable WLCS to use an Oracle database instead of the default Cloudscape database. See Setting Up an Oracle Database for more information about configuring the databases.

You also need to change DEPLOYMENT_SET=cmp to DEPLOYMENT_SET=bmp in sethome.bat.

Setting properties in the weblogic.properties file

The following values need to be set in the weblogic.properties file for the WebLogic Server instance to use as the host for the WLCS components. A weblogic.properties file is provided in the installation.

Setting the listen port

Look in the entry for the TCP/IP port number in the weblogic.properties file in the Core System Properties section. You can change this value, and the default is 7601. The default entry looks like the following snippet:

# TCP/IP port number at which the WebLogic Server listens 
    for connections
weblogic.system.listenPort=7601

Setting the password

In the Core Security-Related Properties of weblogic.properties, the following entry sets the username and password. Note that system is the username and weblogic is the password for the entry. You need to enter these values when using the WLPS Administration Tools at http://<wlhost>:<port>/wlpsadmin.

weblogic.password.system=weblogic

Setting the document root

The document root must be set to include pages for the administration tools, portal pages, and other pages to be accessible via the web server. For example, if you create create a new portal, then its entries for homepage, workingdir, and defaultdest will be relative to the document root.

weblogic.httpd.documentRoot=/weblogicCommerce/server/public_html

Note: The document root should be set correctly out of the box. This is the default location and should not change unless you move the directory.

Deploying EJBs

The following jar files must be included in the weblogic.ejb.deploy property value to properly deploy the WLCS beans.

Note: There is no need for a drive specification if you're deploying jar files from the same file system of the <install-dir>. However, if you want to deploy jar files from another file system, then you should specify the complete path.

Example (installation directory file system):

Note: The first four jar files are different for Cloudscape and Oracle entries. Use the *-cmp jar files for Cloudscape deployments.

weblogic.ejb.deploy=\
        /weblogicCommerce/lib/axiom-bmp-deploy.jar,\
        /weblogicCommerce/lib/ebusiness-bmp-deploy.jar,\
        /weblogicCommerce/lib/foundation-bmp-deploy.jar,\
        /weblogicCommerce/lib/examples-bmp-deploy.jar,\
        /weblogicCommerce/lib/document.jar,\
        /weblogicCommerce/lib/usermgmt.jar,\
        /weblogicCommerce/lib/bridge.jar,\
        /weblogicCommerce/lib/foundation.jar,\
        /weblogicCommerce/lib/axiom.jar,\
        /weblogicCommerce/lib/portal.jar,\
        /weblogicCommerce/lib/ruleeditorbeans.jar,\
        /weblogicCommerce/lib/rulesservice.jar,\
        /weblogicCommerce/lib/schemamgr.jar,\
        /weblogicCommerce/lib/p13nadvisor.jar

Setting up connection pools

A JDBC jts pool, a typical JDBC connection pool, and a special connection pool to support the content management component must all be created to support the WLCS components. The following examples provide a guideline for setting up these pools. A developer needs to adjust the pool properties to properties appropriate for the deployment configuration.

Note: Use weblogic-cmp.properties for Cloudscape and weblogic-bmp.properties for Oracle and copy the file over weblogic.properties.

Example (using Cloudscape):

weblogic.jdbc.DataSource.weblogic.jdbc.jts.commercePool=
    commercePool

weblogic.jdbc.connectionPool.commercePool=\
       url=jdbc:cloudscape:Commerce,\
       driver=COM.cloudscape.core.JDBCDriver,\
       initialCapacity=5,\
       maxCapacity=10,\
       capacityIncrement=1,\
       props=user=test;password=test

# Add an ACL for the connection pool:
weblogic.allow.reserve.weblogic.jdbc.connectionPool.commercePool=everyone

# this is the pool the beans reference
weblogic.jdbc.connectionPool.docPool=\
url=jdbc:beasys:docmgmt:com.beasys.commerce.axiom.document.ref.RefDocumentProvider,\
       driver=com.beasys.commerce.axiom.document.jdbc.Driver,\
       loginDelaySecs=1,\
       initialCapacity=1,\
       maxCapacity=5,\
       capacityIncrement=1,\
       allowShrinking=true,\
       shrinkPeriodMins=15,\
       refreshMinutes=10,\
       props=jdbc.url=jdbc:weblogic:pool:commercePool;\
             jdbc.isPooled=true;\
             docBase=/weblogicCommerce/dmsBase/;\
             schemaXML=/weblogicCommerce/dmsBase/doc-schema.xml
weblogic.allow.reserve.weblogic.jdbc.connectionPool.docPool=everyone

Example (using Oracle):

# Add a DataSource entry for JDBC connections. You will then
# reference it as:
# Initial Context initContext = new InitialContext();
# DataSource ds =
#    (javax.sql.DataSource)initContext.lookup("weblogic.jdbc.jts.
#    commercePool");
weblogic.jdbc.DataSource.weblogic.jdbc.jts.commercePool=commercePool

# In the entry below, server is hostname of database and 
#    TNSNAMES is the entry in tnsnames.ora
# Example: url=jdbc:oracle:thin@moab:1521:TEKA
weblogic.jdbc.connectionPool.commercePool=\
       url=jdbc:oracle:thin:@server:port:TNSNAME,\
       driver=oracle.jdbc.driver.OracleDriver,\
       initialCapacity=5,\
       maxCapacity=10,\
       capacityIncrement=1,\
       props=user=test;password=test

# Add an ACL for the connection pool:
weblogic.allow.reserve.weblogic.jdbc.connectionPool.commercePool=everyone

# Add an ACL for the connection pool:
weblogic.allow.reserve.weblogic.jdbc.connectionPool.jdbcPool=everyone

Note: If you use the com.beasys.commerce.axiom.contact.security.RDBMSRealm class, settings in the weblogiccommerce.properties file for the security realm must match these database settings.

Setting up servlets and new portals

Note: Leave the default entries for the demo portals and servlets that ship with WLCS 2.0.1. You only need to add entries for new portals and servlets.

The PortalServiceManager registration for exampleportal below shows an example of how to register a portal; the specific parameters are described in the section on Creating and Managing Portals.

Note: You should include the wlpsadmin tools entries directly.

You can view a table listing the valid PortalServiceManager parameters and values in the Creating and Managing Portals section. In the entry below, note the following name/value pairs:

• weblogic.httpd.register.exampleportal: URL of the portal or servlet. For example, http://<wlhost>:<port>/exampleportal

  Note: The default ListenPort value is 7601.

• portalname=exampleportal: Name of the portal assigned using the Portal Management administration tool.

• homepage, defaultdest, and workingdir locations are relative to weblogic.httpd.documentRoot

Examples:

weblogic.httpd.register.exampleportal=com.beasys.commerce.portal.admin.PortalServiceManager
weblogic.httpd.initArgs.exampleportal=\
    portalname=exampleportal,\
    homepage=/portals/example/portal.jsp,\
    defaultdest=/portals/example/portal.jsp,\
    workingdir=/portals/example/,\
    groupname=AcmeUsers,\
sessioncomparator=com.beasys.commerce.portal.admin.PortalSessionComparator,\
    refreshworkingdir=120,\
    repositorydir=/portals/repository/,\
    timeout=99999,\
    allowautologin=false

weblogic.allow.execute.weblogic.servlet.wlpsadmin=system

Setting up the security realm for user management

The weblogic.security.realmClass must be set to the appropriate WLCS class to handle authentication and to provide user and group information. It is unlikely a developer needs to change this value unless using external sources such as LDAP.

Example (in weblogiccommerce.properties):

weblogic.security.realmClass=com.beasys.commerce.axiom.contact.
security.RDBMSRealm

Note: This is for the default realm only.

The RDBMSRealm properties must be set according to the database setup for the installation. A developer is likely to need to adjust these values based on the deployment configuration. The example below shows entries for both Cloudscape and Oracle. Note that the dbUrl must match that of the JDBC connection pools as defined in the weblogiccommerce.properties file.

Example (in weblogiccommerce.properties):

#--------------Cloudscape------------------#
commerce.usermgmt.RDBMSRealm.driver=COM.cloudscape.core.JDBCDriver
commerce.usermgmt.RDBMSRealm.dbUrl=jdbc:cloudscape:Commerce;create=true;autocommit=false
commerce.usermgmt.RDBMSRealm.dbUser=none
commerce.usermgmt.RDBMSRealm.dbPassword=none

#----------------Oracle--------------------#
commerce.usermgmt.RDBMSRealm.driver=oracle.jdbc.driver.OracleDriver
commerce.usermgmt.RDBMSRealm.dbUrl=jdbc:oracle:thin:@server:port:TNSNAME
commerce.usermgmt.RDBMSRealm.dbUser=test
commerce.usermgmt.RDBMSRealm.dbPassword=test

Note: This is for the default realm only.

Setting properties in the weblogiccommerce.properties file

The weblogiccommerce.properties file is used to set values for the WLCS components. A sample weblogiccommerce.properties file is included in the installation.

Setting up internal values

These properties are used to set up values to be used internally to identify pools, classes, and home names. It is unlikely a developer would ever need to change these values, so these lines should remain unchanged.

Example:

commerce.jdbc.pool.name=jdbcPool
commerce.jts.pool.name=commercePool

commerce.schemaGroupHomeName.USER=com.beasys.commerce.foundation.property.Schema
commerce.schemaGroupHomeName.REQUEST=com.beasys.commerce.foundation.property.Schema
commerce.schemaGroupHomeName.SESSION=com.beasys.commerce.foundation.property.Schema
commerce.schemaGroupHomeName.CONTENT=com.beasys.commerce.axiom.document.DocumentSchema

commerce.home.p13n.AdvisorHome=com.beasys.commerce.axiom.p13n.advisor.PersonalizationAdvisorHome
commerce.home.rules.RulesServiceHome=com.beasys.commerce.axiom.reasoning.rules.service.RulesServiceHome
commerce.home.property.SchemaManagerHome=com.beasys.commerce.foundation.property.SchemaManager

Setting up portals

The portal component has a number of properties that it uses as defaults for when a new portal gets created. A developer might want to adjust these values based on the nature of the portal being built. The defaults can be overridden using the portal administration tools.

Note: These portals will be copied from the weblogic.httpd.documentRoot/<repository> directory into the corresponding portal/ directories if they do not exist already.

Example:

commerce.default.portal.headerURL=header.jsp
commerce.default.portal.contentURL=portalcontent.jsp
commerce.default.portal.footerURL=footer.jsp
commerce.default.portal.cols=3
commerce.default.portal.suspendedURL=suspended.jsp
commerce.default.portlet.dir=portlets/
commerce.default.portlet.image.dir=portlets/images/
commerce.default.portlet.titlebarURL=titlebar.jsp
commerce.default.banner.color=#666666
commerce.default.titlebar.bgcolor=#333399
commerce.default.show.borders=false
commerce.default.content.bgcolor=#CCCCCC
commerce.default.titlebar.font.color=#FFFFFF
commerce.default.body.bgcolor=#FFFFFF
commerce.default.portal.password=guest

The following property tells the portal component which property set to use as the default for portal users. A developer may want to change this value based on property sets created using the Property Set Management administration tool.

Example:

commerce.default.portal.schemaName=_DEFAULT_PORTAL_SCHEMA

The following portal properties are for internal use and should not be altered by a developer.

Example:

commerce.application.minimum.build=57998
commerce.default.category.name=Home

Setting up the RDBMS Realm

If you need to change the settings in the weblogiccommerce.properties file for the RDBMSRealm, change the database settings in a similar fashion to the database pools in weblogic.properties. Set the dbDriver, dbUrl, dbUser, and dbPassword to use the same database that the commercePool uses in weblogic.properties.

Setting up user management tables

The following properties are used to identify the internal names for tables for use by the user management component. It is unlikely a developer would ever need to change these values.

Example:

commerce.usermgmt.UserTable=WLCS_USER
commerce.usermgmt.GroupTable=WLCS_GROUP
commerce.usermgmt.UserGroupHierarchyTable=
    WLCS_USER_GROUP_HIERARCHY
commerce.usermgmt.GroupHierarchyTable=WLCS_GROUP_HIERARCHY
commerce.usermgmt.EntityIdTable=WLCS_ENTITY_ID
commerce.usermgmt.ProfileTypeTable=WLCS_UNIFIED_PROFILE_TYPE

Setting up documentation name and location

The following properties are used to set up the documentation for the Personalization Server components.

Example:

commerce.p13n.document.dev.name=index.html
commerce.p13n.document.dev.version=20
commerce.p13n.document.dev.docRootDir=docs

 

---

Setting Up an Oracle Database

For information on the Oracle database and driver that this release supports, see the Supported Platforms section of the WLCS Release Notes.

For development and production purposes, WLCS requires a DBMS with specific database configurations. This WLCS distribution includes several SQL scripts that create the initial database information.

Note: You must have a JDBC driver and have configured connection pools (EJB) to access your database in the WebLogic Server.

To create a new Personalization DBMS for Oracle databases:

1. Create a new database user.

2. Make sure the user has all the necessary permissions for creating and modifying tables, indices, etc.

3. Log in to an SQL tool, such as SQL Worksheet, and run one of the following scripts, depending on the client's operating system. The scripts are located in <install-dir>\db\oracle. For NT clients, use create-p13n-oracle-nt.sql. For UNIX clients, use create-p13n-oracle-unix.sql. Note that if you use a remote database, the database host machine's operating system does not affect the script; you should run the script that matches the client machine.

   The SQL scripts create the database schemas, including both the commerce tables and personalization tables, and populate the tables with default data. However, the example applications (see Example Applications for more information) will not work without completing Step 4 below to populate the remainder of the database.

   Note: If the scripts are not in the default directory, change the path in <install-dir>\db\oracle\createp13n-oracle.sql to match the correct path. Then just run this file alone and reference the others.

4. Update the DB_CLASSPATH environment variable within the sethome.bat (sethome.sh for UNIX) in the installation bin\win32 (bin/solaris2 for UNIX systems) directory to include your JDBC database drivers.

   Note: The DB_CLASSPATH is preset with hooks into the Cloudscape database. To use an Oracle database, change this environment variable to your DBMS JDBC database driver in sethome.bat or sethome.sh. The entry should be one of the following two entries:

   • Cloudscape: SET DEPLOYMENT_SET=cmp

   • Oracle: SET DEPLOYMENT_SET=bmp

5. Configure your database connection pools.

   1. Open the weblogic-bmp.properties file that resides in your installation directory.

   2. Change the commercePool connection properties to reflect your database configuration.

      Note: The properties file is preset with hooks into the Cloudscape database. So change the commercePool entries to reflect your database. For more information on the JDBC pools, see http://www.weblogic.com/docs/admindocs/properties.html#conpools. Make sure you edit the appropriate *-cmp (Cloudscape) or *-bmp (Oracle) database configuration files. Make sure you copy the Oracle file over the weblogic.properties file.

   3. Make the same change in weblogiccommerce-bmp.properties and then copy it over weblogiccommerce.properties.

6. Populate the remainder of the tables by performing the following steps:

   1. Start WebLogic Server.

   2. Run DataLoader.bat (<install-dir>\bin\win32 for NT) or DataLoader.sh (<install-dir>/bin/solaris2 for UNIX systems) from the appropriate directory to populate the tables.

   3. Restart WebLogic Server.

 

---

Recreating the Cloudscape Database

You might need to recreate the default Cloudscape database if your Cloudscape database becomes corrupted or to clear out the current tables. To recreate the database:

1. Run BuyBeansDropCloudscape.sql to remove the buybeans tables from the database in the existing Cloudscape database.

2. To create the new database, run CloudscapeDatabaseCreator.bat (NT) or CloudscapeDatabaseCreator.sh (UNIX) in <install-dir>\db\cloudscape.

 

---

Setting Up the Reference Implementation
Document Management System (DMS)

This release ships with a default DMS using the WLPS reference implementation. To index content, the DMS uses the BulkLoader, a command-line utility that indexes all content under the \dmsBase directory. Use the loaddocs.bat (NT) and loaddocs.sh (UNIX) files to run the BulkLoader. Refer to the Content Management component documentation for detailed information about the command-line switches provided for the BulkLoader utility.

See Installing and Configuring the WLCS/Interwoven TeamSite Interface for information about using Interwoven's TeamSite DMS and see Installing and Configuring Documentum for information about using the Documentum DMS.

Note: The demo database ships with the default content already indexed. For UNIX systems, change sethome.sh and loaddoc.sh files in <install-dir>/bin/solaris2/ to contain the paths to the installation directory.

 

---

Installing and Configuring the WLCS/Interwoven TeamSite Interface

All configuration documented in this section applies to the Interwoven TeamSite Server. If you are not using Interwoven TeamSite for content management, skip this configuration procedure.

Installing and configuring the WLCS interface begins only after successful installation of version 4.2 of the TeamSite, TeamSite Templating, Open Deploy and Data Deploy components, and version 5.1 of the WebLogic server and version 2.0 of the WebLogic Commerce Server. This includes configuration and testing of the Data Deploy Automation Server (DAS) component.

The installation of the WLCS interface involves the following steps:

1. Install the WLCS database server client interface on the TeamSite server.

The current version of the WLCS interface executes on the TeamSite server and may require certain components to be installed to provide remote connection with the WCLS database. This step is unnecessary if the WLCS database and TeamSite server are on the same platform. In addition, there may be environment variables that must be defined to allow a valid connection. Refer to vendor documentation for specific installation requirements.

1. Modify the database connection parameters to access the WLCS database.

The DNR scripts, teamsite_wlcs_trans.ipl and teamsite_wlcs.ipl, require a user id and password for an account with access to the WLCS database and a valid Data Source Name (DSN) as defined by the Perl Data Base Interface (DBI) standard. The scripts are written in Perl and use the DBI interface for accessing all databases - both TeamSite and WLCS. The connection command to the destination database must be modified to use these parameters to establish a connection. This command is identified in each of the scripts as shown below:

# The following is used to connect to the database. The format is:

# DataSourceName, User, Password

# Replace the hard-coded User ID and Password (scott, tiger) with a valid account
# for the destination database. Replace the Data Source Name with a valid
# specification for the destination database. The DSN is database specific.

my $DES = DBI->connect("DBI:ODBC:ORAIWOV","scott","tiger", {RaiseError => 1} );

In the above example, the parameter scott would be replaced with a valid Oracle User Id, tiger would be replaced with the corresponding password, and ORAIWOV would be replaced with a valid Data Source Name (DSN). The DSN is the most likely source of error. On NT resident databases, the easiest approach to defining a valid DSN is to create a system DSN via the ODBC control panel component. For a Unix database target the DSN is normally the name of the database server host, its listening port (for example, Oracle uses 1521 as the default port number), and sometimes the database name. For example, an Oracle database DSN could be specified:

DBI:ODBC:<server host name>:<port>

If the target database platform provides a DBD driver that can be installed on the TeamSite server (client) then that driver can be used instead of the ODBC DBD driver shown above. For example:

DBI:ORACLE:<server host name>:<port>

Refer to the vendor specific documentation for the correct format of the DSN specification. The parameters used can be tested using the dbish utility provided with TeamSite 4.2.

1. Modify the TeamSite Data Deploy database connection parameters.

This step is optional depending on the TeamSite Data Deploy configuration chosen when setting up the Data Deploy Automation Server (DAS). The current implementation does not attempt to access those configuration files to determine what options were selected. The default configuration uses the SQL Anywhere database that ships with TeamSite. This is also the configuration that the DNR scripts use by default. Therefore, if all defaults were taken, then the DNR script should require no modification. Please note, however, that the SQL Anywhere license provided with TeamSite only supports a single connection. This means that multiple deployments cannot be run in parallel, and, that DAS actions cannot occur simultaneously with deployment. A warning message is generated and the deployment terminated if this condition occurs.

1. Modify the location of the mime.types file.

The interface looks up the mime type of a document based on its extension using the standard mime.types file. The location of this file needs to be specified in the DNR script. This is done by setting the value of the $MIME_TYPE_PATH variable as shown in the following example (Note: make sure the path ends in either a "\", for NT clients, or a "/" for Unix clients):

$MIME_TYPE_PATH = "D:\"

Note: If not specified, the mime.type file must reside with the DNR scripts.

1. Modify the Open Deploy client configuration file.

This step is a standard part of using Open Deploy's DNR feature. The client configuration file must be edited to specify the path to the DNR script (either teamsite_wlcs_trans.ipl or teamsite_wlcs.ipl should be selected depending on whether transaction mode is required) and a single parameter that identifies the EDITION being deployed.

Note: The illustration below inserts newlines for readability. These should not be left in the client configuration file; refer to the Administering Open Deploy manual.

deployment=webEdition
    teamsite_based
    area=//IWSERVER/default/main/www/EDITION
    previous_area=//IWSERVER/default/main/www/EDITION/IW_PREV
    deploy_run_script=d:\iw-home\iw-perl\bin\iwperl.exe
       d:\teamsite_wlcs_trans.ipl
      //IWSERVER/default/main/www/EDITION
      when=client_after_deploy
.
.
.
;

• This is a transaction mode, teamsite-based deployment. This is the recommended configuration. A directory based deployment from a staging area is supported but it will deploy all data from the staging area Data Deploy based tables, whether new or modified, and will not remove data records that were previously deployed and deleted from the staging area.

• The area (area and previous area) must either be an edition or a staging area. The string EDITION in the area version path (vpath) is used to identify an edition deployment area. The string STAGING at the end of an area version path is used to identify a staging area as the deployment area. Specifying an EDITION based deployment results in a comparison between the specified edition and the previous edition (using the iwcmp CLT) and the results used to determine which data records should be deployed. The criteria used to select records for deployment includes:

  • If the file is new or modified in the current area.

  • If the file has been deleted in from the current area

  • If the file is new and insert is performed in the WLCS database tables. If the file is modified, an update is performed in the WLCS database tables. If the file has been deleted, a deletion is made against the WLCS database table wlcs_document. This deletion cascades to the wlcs_document_metadata table. This is a limitation of the current reference implementation and will not likely remain in the product version of this interface.

• The when clause of the DNR specification must be defined as client_after_deploy. This results in the DNR being run on the client after a successful deployment.

• The use of correctly formatted version paths. The above example illustrates a valid version path for NT. An alternate version for NT is to use the file system interface. For example,

  Y:\default\main\www\EDITION

For Unix, a version path can be specified using the following notation:

/iwmnt/default/main/www/EDITION

Refer to the TeamSite Command Line Tool reference manual for a discussion of version paths.

Completion of the above steps should result in a valid deployment.

 

---

Installing and Configuring Documentum

Perform the following steps to use Documentum with the BEA WebLogic Commerce Servers. Refer to Documentum's documentation for more information on setting up the Documentum Document Management System (DMS).

1. Add the documentum.jar to be deployed.

   • Add the following line to the EJB Deployment section in the weblogic.properties file:

     /weblogicCommerce/ejb/documentum.jar,\

   • The weblogic.properties entry should now contain:

     weblogic.ejb.deploy=\
     /weblogicCommerce/ejb/jar1.jar,\
     /weblogicCommerce/ejb/jar2.jar,\
     .
     .
     .
     /weblogicCommerce/ejb/documentum.jar,\

2. Modify the CLASSPATH to include Documentum's JDBC Driver classes and Dfc.jar.

   • Modify the sethome.bat (sethome.sh for UNIX) to set the following variables:

   • Set DCTM_HOME environment variable to the folder in which the Documentum classes and shared libraries are copied.

   • For NT, set DCTM_HOME=%WL_COMMERCE_HOME%\documentum

   • For UNIX, DCTM_HOME=$WL_COMMERCE_HOME/documentum; export DCTM_HOME

   • Add the following to the WEBLOGIC_CLASSPATH

     For NT, %DCTM_HOME%\dfc.jar;%DCTM_HOME%

     For UNIX, $DCTM_HOME/dfc.jar:$DCTM_HOME

3. Modify the PATH so that all the native shared Libraries required by the Dfc.jar are accessible.

   • For NT, set PATH=%PATH%;%DCTM_HOME%

   • For UNIX, add LD_LIBRARY_PATH=$LD_LIBRARY_PATH;$DCTM_HOME; export LD_LIBRARY_PATH

4. Set up the Environment Variable DMCL_CONFIG to indicate the location of the dmcl.ini.

   DMCL_CONFIG=%DCTM_HOME%\dmcl.ini

5. Modify the dmcl.ini file to point to the correct DocBroker.

   [DOCBROKER_PRIMARY]
   host = my_host

   Note: Please see the Documentum Server User's Guide for a list of parameters in the dmcl.ini and their purpose.

6. Create a connection pool for Documentum connections.

   • Modify weblogic.properties to create a connection Pool dctmPool

     weblogic.jdbc.connectionPool.dctmPool=\
     url=jdbc:documentum:oca,\
     driver=com.documentum.oca.jdbc.jdbc20.DjdbcDriver,\
     loginDelaySecs=1,\
     initialCapacity=1,\
     maxCapacity=5,\
     capacityIncrement=1,\
     allowShrinking=false,\
     shrinkPeriodMins=15,\
     refreshMinutes=10,\
     props=user=docbase_user;password=docbase_password;
     database=docbase_name;server=domain_name
     weblogic.allow.reserve.weblogic.jdbc.connectionPool.
     dctmPool=everyone

   • user is the Docbase User

   • password is the Docbase Password for that user.

   • database is the name of the DocBase

   • server is the domain name, if required (applicable only for NT Docbases)

Documentum bean environment variables

The following are the environment properties used by the Documentum Document Bean and Documentum Schema Bean:

1. DOC_TYPES is of type java.lang.String and is a comma-separated list of all the Documentum Types that are available to be queried. This value is used in two instances:

   1. During creation of Rules users could select one of the types mentioned in the DOC_TYPES to create the rule.

   2. When the DctmDocumentSmartBMP receives a query, it does not know against which Object Types in the Docbase to query. So, the types mentioned in the value of DOC_TYPES would be queried in the order they appear in the comma-separated list. For example, if the Expression consists of a query object_name == `junk', the DctmDocumentSmartBMP searches for the matching rows in the object type newsitem first, i.e.,

      select r_object_id from newsitem where object_name= `junk'

      Then in promotion,

      select r_object_id from promotion where object_name= `junk'

      and then in dm_document

      i.e. select r_object_id from dm_document where object_name= `junk'

      Note: One important thing to note here is that the results returned would be a union of all the results retrieved. The reason being as in this instance is there is a possibility of having both a type and its subtype in the DOC_TYPES. Here promotion and newsitem are both subtypes of dm_document.

      So all the results retrieved in the select from newsitem would be a subset of the results returned in the select from dm_document query.

      Note: For more efficiency, if only a particular subtype is to be searched, include any additional attribute from that subtype in the Search Expression.

      For example, If newsitem as a subtype of dm_document and has an attribute called news_start_date , include the news_start_date in the Search Expression. If the Expression consists of the query object_name == `junk' && news_start_date >= now, then only the type newsitem would be queried for, because the attribute news_start_date is present only in the type newsitem from within all the types present in the variable DOC_TYPES.

2. CONNECTION_URL is of type java.lang.String, and the value is jdbc20:weblogic:pool:dctmPool, where dctmPool is the Connection Pool created for Documentum Sessions.

3. SmartBMPClass is of type java.lang.String and the value is com.documentum.vendor.beasys.DctmDocumentSmartBMP, the class com.documentum.vendor.beasys.DctmDocumentSmartBMP is Documentum's SmartBMP Class to retrieve the Content from the DocBase.

4. SmartBMPUpdate is of type java.lang.String and defaults to false.

5. SmartBMPLoadOnGetter is of type java.lang.String and defaults to false.

6. PropertyCase is of type java.lang.String and defaults to lower. This is not required for the Schema bean.

The easiest way to configure the beans is to edit the ejb-jar.xml deployment descriptor contained in the documentum.jar from the install. After making the changes, recompile the EJBs in documentum.jar (i.e., run ejbc).