| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Platform > WebLogic Portal > Administration Guide > System Administration |
|
Administration Guide
|
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
If you create a clustered WebLogic Portal domain with the Configuration Wizard, there are a few tasks to perform after the domain is created. See "WebLogic Portal Domain Template" at http://download.oracle.com/docs/cd/E13196_01/platform/docs70/template/wlptemp.html#1008419.
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
Table 11-1 shows the locations of the start and stop scripts for the WebLogic Portal sample applications that BEA provides.
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 Table 11-1 shows the start and stop scripts for the WebLogic Portal domains you create with the Configuration Wizard. The default location for the start and stop scripts is <BEA_HOME>\user_projects\portalDomain. 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:
To give users WebLogic Server system administration rights, add them to the Administrators group in the domain using the WebLogic Server Console tool. For more information, Creating WebLogic Server System Administrators.
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:
All start scripts in Table 11-1 and Table 11-2 support installing the designated server as a Windows Service.
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.
If you created a WebLogic Portal domain with the Configuration Wizard, the default location of this project file is <domain>\beaApps\portalApp-project\portalApp-project.
If you are opening a project file for one of the sample applications, the location of the appropriate project file is <BEA_HOME>\weblogic700\samples\portal\<domain>\beaApps\
<app_name>-project\.
Figure 11-1 Setting the Path to the Enterprise Application Directory
If you need only one connection, deselect the Use independent connections for each task option, and select the connection you want to use in the All-Purpose Connection field.
If you need more than one connection, select the Use independent connections for each task option, and in each field, select the appropriate connection, as shown in Figure 11-3.
Figure 11-3 Setting Multiple Connections
Database Administration
This section includes information on the following subjects:
Supported Databases
For information on which databases are supported in this release, see "Supported Platforms" at http://download.oracle.com/docs/cd/E13196_01/platform/docs70/support/index.html.
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.
Note: If you are running WebLogic Portal as a Windows service, PointBase will not start automatically. For more information, see Running WebLogic Portal as a Windows Service.
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.
startPBServer.bat <path_to_domain>\db_settings.properties
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.
startPBConsole.bat <path_to_domain>\db_settings.properties
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.
For example, Listing 11-1 shows the Oracle section of the db_settings.properties file before and after modifications.
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.
The exact number of the db_version setting is important, because it controls which DDL is used. Table 11-3 shows which db_version number to use for each type of database.
Note: Table 11-3 shows databases that are not currently supported. For a list of currently supported databases, see "Supported Platforms" at http://download.oracle.com/docs/cd/E13196_01/platform/docs70/support/index.html.
Step 3: Start the Server Start the server. See Starting and Stopping 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
Stop the server. See Starting and Stopping 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.
LSNRCTL> status
LSNRCTL> start
LSNRCTL> stop
Step 8: Start the Server
Start the server. See Starting and Stopping 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:
<PORTAL_HOME>/db/oracle/817/admin
sqlplus username/password@net_service_name
@rebuild_indexes.sql
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.
For a complete reference of database schemas, see Database Schemas.
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.
For JRockit information and downloads, go to http://www.bea.com/products/weblogic/jrockit. For JRockit documentation, go to http://www.oracle.com/technology/documentation/index.html.
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
WebLogic Portal is configured for PointBase and -hotspot client. You can switch to different versions of HotSpot by using the appropriate option. For a list of the variations supported on each platform, see "Supported Platforms" at http://download.oracle.com/docs/cd/E13196_01/platform/docs70/support/index.html.
For more information on HotSpot, go to http://java.sun.com/products/hotspot.
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:
<BEA_HOME>\weblogic700\portal\db\db_vendor\db_version\...
For example, if you are using Oracle 8.1.7 on UNIX, the location is:
<BEA_HOME>/weblogic700/portal/db/oracle/817/...
Scripts BEA provides scripts to help set up the database schema needed for recording Behavior Tracking events, as well as the schema needed for recording data associated with WebLogic Portal. This data includes information from orders, catalogs, products, portals, and portlets. For more information about scripts, see, Step 2: Create the Behavior Tracking Databases.
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
Three tables are provided for the Behavior Tracking data. The EVENT table stores all event data. The EVENT_ACTION table logs actions used by third-party vendors against the recorded event data, and the EVENT_TYPE table references event types and categories in the EVENT table. Figure 11-5 shows a logical entity-relation diagram for the Behavior Tracking Database.
Figure 11-5 Entity-Relation Diagram for the Behavior Tracking Database
EVENT Database Table Table 11-5 describes the metadata for the EVENT table. This table stores all Behavior Tracking event data. The EVENT table has six columns; each column corresponds to a specific event element. Five of the EVENT table's columns contain data common to every event type. The XML_DEFINITION column contains all information from these five columns plus event data that is unique to each event type. See the section Constraints and Indexes for information about the constraint defined for this table. The Primary Key is EVENT_ID.
An XML document is created specifically for each event type. The data elements corresponding to each event type are captured in the XML_DEFINITION column of the EVENT table. These elements are listed in Table 11-6.
The EVENT_ACTION Database Table Table 11-7 describes the metadata for the EVENT_ACTION table. This table logs actions used by third-party vendors against the recorded event data. It is a fairly static. The Primary Key is composed of of EVENT_ACTION and ACTION_DATE.
The EVENT_TYPE Database Table Table 11-8 describes the metadata for the EVENT_TYPE table. This table references event types and categories in the EVENT table. This table is static. See the section Constraints and Indexes for information about the constraint defined for this 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.
If the Event service does not exist as a service for your application, use WebLogic Server Administration Console to add it.
To add the Behavior Tracking listener, take the following steps:
http://hostname:port/console—> sampleportalDomain—> Deployments—> Applications—> sampleportal—> Service Configurations—> Event Service—> Configuration Tab—> Synchronous Listeners
Figure 11-6 WebLogic Server Administration Console—Event Service
Note: You must configure your database before activating Behavior Tracking. For information on how to do this, see Creating Databases for a Production Environment.
Step 4: Configure the Behavior Tracking Service
Behavior Tracking events are placed in a buffer and then intermittently persisted to the Event tables in the database where they can be analyzed offline. An asynchronous service is used so that long-running event handlers can execute without delaying the application from a Web site visitor's perspective.
Note: Each Behavior Tracking event property must be configured in the WebLogic Server Administration Console.
Connection pool The buffered Behavior Tracking events are swept into the database using a pool of data connections. The default data source is weblogic.jdbc.jts.commercePool. You can use a different data source. To do this, create and configure the new data source (see Configure a Data Source (Optional)) and substitute the name of the default data source with the name of the new data source in the WebLogic Server Administration Console.
Properties The particular events that are persisted to the database are specified in the PersistEventTypes property. You can view and alter the list of the persisted events in the WebLogic Server Administration Console. The types in this list must match the type specified in the event; for example, the SessionBeginEvent has as its type the string "SessionBeginEvent".
Optimize performance The frequency of sweeping of events from the buffer is controlled by the following properties the Behavior Tracking service:
Tune these properties to optimize performance. A buffer sweep should be performed often enough that writing to the database is not too time consuming but not so frequent that the operation is wasteful.
Steps To configure the Behavior Tracking Service, do the following:
Notes: These steps provide information on how optimize performance in the Sample Portal. For your application, you would use similar steps.
If the Event service does not exist as a service for your application, use WebLogic Server Administration Console to add it.
Configure a Data Source (Optional)
This section provides a brief description about configuring a new data source for a connection pool used for persisting events in the Sample Portal. For your application, you would use similar steps.
To configure a new data source, take the following steps.
Note: For more information on using the WebLogic Server Administration Console, see the WebLogic Server documentation at http://download.oracle.com/docs/cd/E13222_01/wls/docs70/index.html.
http://hostname:port/console—> sampleportal—> Services—> JDBC—> Data Sources—> JDBCData Source Factories
Figure 11-8 WebLogic Server Administration Console—JDBC Data Sources
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
