System Administration

System administration in WebLogic Portal involves traditional system administration tasks, such as backup and recovery, as well as tasks that are unique to WebLogic Portal, such as switching databases and helping configure a clustered environment.

This section includes information on the following subjects:

Post Configuration Wizard Tasks

Starting and Stopping the Server

This section, which provides instructions on starting and stopping a WebLogic Portal server, assumes that you created your WebLogic Portal domain with the Configuration Wizard.

Scripts for starting and stopping any WebLogic Portal server are located in your WebLogic Portal domain directory. The following sections show scripts and command-line arguments for stopping and starting a server in different server configurations.

This section also includes information on starting a WebLogic Portal server as a Windows service.

This section includes information on the following subjects:

Starting and Stopping WebLogic Portal Sample Domains

In Windows, you can also start these sample servers from the Start menu, using the following base Start Menu path:

Start  >  Programs  > BEA WebLogic Platform 7.0 > WebLogic Portal 7.0 > Portal Examples > ...

No login is required to start the example servers.

Note: You can also stop the server by clicking the close icon in the command window.

Starting and Stopping Domains Created with the Configuration Wizard

If you created your domain on a Windows server, and you selected the option in the wizard for creating a Start Menu shortcut, you can start the server from the Start Menu. The default shortcut location is Start  >  Programs  > BEA WebLogic Platform 7.0 > User Projects > domain_name  > Start Portal Server.

When prompted to log in, log in as the WebLogic Server system administrator. The default usernames/passwords are:

Note: You can also stop the server by clicking the close icon in the command window.

Running WebLogic Portal as a Windows Service

You can run WebLogic Portal as a Windows NT or 2000 service so that WebLogic Portal domains start automatically when you boot your Windows server. This is recommended for production, not development.

About PointBase

When starting your server as a Windows service, the PointBase database server does not start automatically. Therefore, you must do one of the following:

Installing as a Windows Service

As a best practice, start your server normally to make sure it starts successfully before installing it as a Windows service.

Use -installService on the command-line before any other command-line arguments. For example:

Uninstalling as a Windows Service

To remove a previously installed service, use the -uninstallService command-line argument instead. For example:

Setting up the E-Business Control Center

The E-Business Control Center is an application that runs on your local machine. Much of the E-Business Control Center functionality does not require a server connection. However, some functionality, such as synchronizing data to the server and accessing server-side resources for creating personalization and campaign logic, require one or more server connections.

After you run the Configuration Wizard to create a new domain, the E-Business Control Center is configured correctly to run in a single-server environment with the E-Business Control Center running on the server machine.

This section provides guidelines for ensuring the E-Business Control Center can connect and synchronize to the server, especially if you are running the E-Business Control Center on a machine other than the server or if you are using a multi-server environment.

Many administration procedures involve synchronizing from the E-Business Control Center to the server by clicking the Synchronize button on the E-Business Control Center toolbar. This procedure ensures that when you click the Synchronize button, synchronization is successful.

Database Administration

This section includes information on the following subjects:

Supported Databases

About PointBase

PointBase is the default database that BEA provides. It is used for the sample domains that BEA provides, and it is the default database used when you create a domain with the Configuration Wizard.

PointBase runs on its own server. The PointBase server must be running for your applications to access it. When you start WebLogic Portal server to run your applications, the PointBase server starts automatically.

Starting and Stopping PointBase

If you want to start the PointBase database for maintenance without running the WebLogic Portal server, or if you need to start PointBase manually because you are running WebLogic Portal as a Windows service, follow this procedure.

To stop PointBase, run the stopPBServer.bat or stopPBServer.sh scripts from the same directory as the start scripts.

Starting the PointBase Console

PointBase includes a Console tool that lets you view and manage your PointBase database. To launch the PointBase Console, follow this procedure.

Note: On Windows systems, a Start Menu shortcut is provided for launching the PointBase Console for each WebLogic Portal sample domain.

Switching to Other Databases

This section walks you through the process of switching from one supported database, such as the default PointBase database, to another supported database, such as Oracle. Domains created with the Configuration Wizard include a PointBase database.

Step 1: Configure Your Database

Before you switch from the default PointBase database to another supported database, you must configure that database. For configuration instructions, see the README.html file for your database in the following location:

<BEA_HOME>\weblogic700\portal\db\<db_type>\<version>\admin.

Step 2: Edit db_settings.properties for Your Database Environment

In your domain directory, open the db_settings.properties file, and for the database type you are using, replace the @...@ variables with the actual values, and save the file.

Listing 11-1 The db_settings.properties file

Before

#------Oracle Thin Driver------------------------#
#
#@IF_USING_ORACLE_THIN@
#database=ORACLE_THIN
#db_version=817
#jdbcdriver=oracle.jdbc.driver.OracleDriver
#server=@ORACLE_NET_SERVICE_NAME@
#port=@ORACLE_PORT@
#dblogin=@ORACLE_USER@
#dbpassword=@ORACLE_PASSWORD@
#connection=jdbc:oracle:thin:@@ORACLE_SERVER@:@ORACLE_PORT@:
@ORACLE_SID@
#@ENDIF_USING_ORACLE_THIN@

After

#------Oracle Thin Driver------------------------#

#
#database=ORACLE_THIN
#db_version=817
#jdbcdriver=oracle.jdbc.driver.OracleDriver
#server=MY817SVC
#port=1521
#dblogin=WEBLOGIC
#dbpassword=WEBLOGIC
#connection=jdbc:oracle:thin:@myhost:1521:MY817SID
#@ENDIF_USING_ORACLE_THIN@

Note: Do not comment or uncomment (using the #) any lines in this file yet. You will do that in a later step.

Step 3: Start the Server

Step 4: Set up the Connection Pools and Realm in the WebLogic Server Console

For this procedure, open the db_settings.properties file in your domain folder, and copy values from this file into the WebLogic Server Console.

Step 5: Stop the Server

Step 6: Edit db_settings.properties to Uncomment Your Database

Open the db_settings.properties file, uncomment the properties for the database you are using (remove the # from the beginning of each line), comment out the PointBase database settings (put a # at the start of each line), and save the file.

Step 7: Run create_db

Run the create_db script in your domain folder to create and populate the database. Verify that the output written to create_db.log does not contain fatal errors.

If you receive a com.bea.p13n.db.internal.DbLoaderException, you probably have a configuration error. If you are using the Oracle thin driver, check the Oracle server listener configuration.

Step 8: Start the Server

Step 9: Run loadads and loaddocs

To load your content and metadata:

Step 10: Run sync

Run the sync command in your domain folder to update the server with the new database data.

Setup is now complete. You should now be able to start and run the Portal application against your database.

Step 11: Oracle Only - Rebuild Indexes

The create_db script places the WebLogic Portal domain indexes in the default tablespace (WEBLOGIC_DATA). To rebuild indexes in the WEBLOGIC_INDEX tablespace:

About Database Schemas

Use the information provided in the Database Schemas topic to learn how to restructure your database to better customize or extend the technologies provided in WebLogic Portal.

Backup and Recovery

Use the same procedures for backup and recovery of WebLogic Portal as those you use for other data. Following are a few guidelines:

Performance Tuning

Use the following guidelines to increase the performance of your applications.

This section includes information on the following subjects:

Adjust Database Connections Available at Startup

To optimize database pool performance for your Web site, do the following:

For more information on database connection pools, refer to the WebLogic Server Console online help.

Catalog Size

The number of product items in the catalog tables and their corresponding attributes can have a significant effect on response time, especially for catalog queries. Because searching for products is a key aspect of the browsing experience, it is important to ensure that your database is large enough to handle this product information.

Campaigns

The following factors affect performance of campaigns and related items.

Referencing events- Always make scenario rules dependent on a particular event. This allows optimizations based on the event types referenced in the scenario rules.

Avoiding firing extraneous events- Whenever possible, avoid firing any extraneous events. The campaign services must listen to all events. Use events to signify important occurrences on the site.

Increase Ad Display-Count Buffer Size

The Campaign service uses display counts to determine whether a campaign has met its end goals. Each time an ad placeholder finds an ad to display as a result of a scenario action, the Campaign service updates the display count.

By default, the Campaign service does not update the display count in the database until an ad placeholder has found ten ads to display as a result of one or more scenario actions. If the server crashes before the Campaign service flushes this display-count buffer to the database, you can lose display-count updates, up to the number of display counts that are in the buffer.

Use the following procedure in the WebLogic Server Console to determine the number of display counts that are stored in memory before the Campaign service updates the database.

Location of Java Virtual Machines (JVMs)

Although clustered environments offer benefits in terms of both load balancing and failover, it is important to consider the location of clustered nodes as they relate to application scalability. If a single machine is assigned multiple IP addresses, scalability is improved because replication of HTTP session data does not require traversing the network. However, this is less desirable where failover is critical (for example, in situations where customers should never lose their shopping cart). If you choose to run Java Virtual Machines (JVMs) on different machines to ensure failover, the scalability of your application might be negatively affected.

Using the JRockit Virtual Machine

BEA WebLogic JRockit is a Virtual Machine with exceptional performance. JRockit is designed for large-scale, enterprise server-side execution of Java applications and includes technology that works with I/O, memory management, and multi-threading.

Using the HotSpot Virtual Machine

Hot Spot enhances JDK 1.3 performance. It provides several implementations, which vary depending upon the operating system. HotSpot is an optimized VM with several variations.

The HotSpot variations are set using the following options. These options must appear before any other options in the command.

To invoke hotspot when you start your server, you can add one of the following lines to the start script(s) you are using:

set JAVA_VM=-hotspot, or

set JAVA_VM=-server

Internationalization Performance Tuning

When you use the <i18n> JSP tags and resource bundles for presenting internationalized content, you can determine how often WebLogic Portal checks for updated content in resource bundles.

In the <BEA_HOME>\weblogic700\portal\weblogiccommerce.properties file, set the i18n.bundle.reload.seconds property to the desired value. For example:

# Personalization configuration for changing the timeout on
# resource bundles for the I18N tags
#
i18n.bundle.reload.seconds=300

The default value is 300 seconds (5 minutes). Changing the value is a balance between flexibility and performance. If your resource bundle content changes frequently, lowering the value makes WebLogic Portal update content more frequently, though at a cost to performance. If your resource bundle content stays relatively static, increase performance by choosing a higher value, such as 86400 (24 hours).

Persisting Behavioral Tracking Data

To record how online visitors are interacting with your Web site, you can record event information to a database. These kinds of events are called Behavior Tracking events. E-analytics and e-marketing systems can then analyze these events offline to evaluate visitor behavior and transactional data. You can use the knowledge gained from analysis to create and optimize personalization rules, set up product offers, and develop interactive marketing campaigns. This section describes the requirements and database schema needed to log event data for analytical use. The steps are listed below:

Step 1: Understanding Data Storage and Table Structure

Before setting up and using a database for recording Behavior Tracking data, you need some background information about how Behavior Tracking uses relational databases. The first step to persisting Behavior Tracking data is to understand the structure of Behavior Tracking database schemas and tables. This information is also useful to third-party vendors for extracting Behavior Tracking data to use in data mining.

The following sections provide information relevant to persisting Behavior Tracking data:

Relational Databases

Relational databases have both logical and physical structures. Logically you may define one or more databases. Each database may contain one or more tables and indexes, and each table may have multiple columns and rows. The logical structure of databases is quite similar between vendors. However, the physical structure of a database is very vendor-specific. Essentially, the physical structure defines areas on disk drives where the data is stored. Each database environment uses its own terminology and implementation for storing data at the operating system level. For example, Oracle uses the term tablespace and the Microsoft SQL Server uses the term filegroup.

Recommendation    When a database structure is defined by a database administrator, you must be pay attention to the location of specific tables. Some tables are static in that they do not change much; some tables are dynamic in that many rows are being added and deleted; and some tables are read frequently and some rarely. Depending on their behavior, tables should be placed on different physical locations. Some of the most highly-used tables in WebLogic Portal are used for Behavior Tracking. The activity of a single visitor moving around your site may generate multiple table entries. Therefore, it is recommended that you place these tables on the fastest drives in the computer.

Experienced database administrators are aware of many techniques for monitoring and configuring a database installation for optimal performance. If you do not have a database administrator working with your installation and you have a lot of activity on your site, bring in a well-qualified database administer for regular maintenance of your system.

Database Directory Paths

The default database directory paths are:

For example, if you are using Oracle 8.1.7 on UNIX, the location is:

For Oracle databases, the tablespaces created for WebLogic Portal data are the WEBLOGIC_DATA and WEBLOGIC_INDEX.

Note: WEBLOGIC_DATA and WEBLOGIC_INDEX are tablespace names created by BEA scripts. If you use a particular naming convention, you can rename them.

Behavior tracking uses a tablespace called WEBLOGIC_EVENT_DATA. This tablespace stores all Behavior Tracking tables, indexes, and constraints. Because of the potential for high volumes of data, this tablespace should be monitored closely.

Behavior Tracking Database Schema

Figure 11-5 Entity-Relation Diagram for the Behavior Tracking Database

The Primary Key is EVENT_ID.

The EVENT_ACTION Database Table

The Primary Key is composed of of EVENT_ACTION and ACTION_DATE.

The EVENT_TYPE Database Table

The Primary Key is EVENT_TYPE.

Note: To record custom events, you must create an entry in this table. If a custom event does not have a record in this table, you cannot persist it to the EVENT table.

Constraints and Indexes

There is a single foreign key constraint between the EVENT_TYPE columns in the EVENT and EVENT_TYPE tables. As previously mentioned, if a custom event does not have a record in the EVENT_TYPE table, it cannot be persisted to the EVENT table.

Other than Primary Keys on each of the tables, there are only two indexes on the EVENT table. One index is on the EVENT.EVENT_DATE column and the other index is comprised of the EVENT.EVENT_TYPE and EVENT.EVENT_DATE columns.

Step 2: Create the Behavior Tracking Databases

BEA provides scripts to create the Behavior Tracking database schema and tables for all databases except PointBase. (Behavior Tracking database objects already exist for PointBase; executing create_db.bat/sh recreates them.) This step provides information about the database structures for the following environments:

Creating a Database for a Development Environment

In a development environment, you may not want or need separate databases or tablespaces for recording Behavior Tracking events from the databases or tablespaces used for WebLogic Portal. Accordingly, you can include the Behavior Tracking database objects along side the database objects of these products. The easiest way to accomplish this is to execute the create_all script found in the event directory of your database installation.

Log into Oracle using SQL*Plus and execute the create_all.sql script in this location:

%BEA_HOME%/weblogic700/portal/db/oracle/817/event/create_all.sql

The create_all scripts in the event subdirectory executes the following scripts:

Creating Databases for a Production Environment

This scenario is intended for use in an Oracle production environment where multiple tablespaces and their corresponding elements, such as tables and indexes, can reside in separate tablespaces and potentially on a different database server than WebLogic Portal database objects.

Before enabling the Behavior Tracking events, complete the following steps:

Step 3: Enable the Behavior Tracking Listener

Before Behavior Tracking events can be recorded to a database, you must enable the Behavior Tracking listener. This is accomplished by adding a listener class.

Notes: This step provides information on how to add a listener class in the Sample Portal. For your application, you would use similar steps.