Chapter 3
Configuring Your System
This chapter contains the following sections:
Configuring Oracle
The default installation is sized for a small sample database. The Oracle database should be set up and configured to meet the specific requirements of your marketplace. Some recommendations on configuring Oracle are provided in this section. For more details, refer to the document, Oracle 8.1.7 / 9i Designing and Tuning for Performance.
Setting Oracle Initialization Parameters
-
The following are the recommended changes to the Oracle initialization parameters in the init<SID>.ora file.
Resize the System Global Area (SGA).
-
The SGA is the memory area that is available to an iPlanet Market Maker installation. To achieve optimal performance, it is recommended to set the SGA size as large as possible, depending on the memory available on the server. This can be achieved by changing the values for shared SQL pool and data block buffer cache settings.
Set shared SQL pool—The value for this setting can be changed by setting shared_pool_size parameter (in bytes). Start by setting this value to 400 MB, and monitor the usage of shared SQL pool.
Set data block buffer cache size—The data block buffer cache size is set by the db_block_buffers init.ora parameter (in database blocks). The recommended size of data block buffer cache is 2 percent of the database size. The recommended db_block_size for the iPlanet Market Maker installation is 8192 bytes. Start by setting this value to 96000 and monitor the cache hit ratio.
Improve sorting operation—Set the sort_area_size and sort_area_retained_size to minimize the sorts (disk) to less than 5% of the total sorts, because searching the catalog is resource intensive due to the hierarchical nature of queries and the interMedia option.
Set the db_block_lru_latches parameter to a number equal to the number of CPUs on a multiple-CPU system.
Oracle Initialization Parameters
Performance tests were conducted on an iPlanet Market Maker installation for the functions:
The installation was sized to handle 500 concurrent users and a 2 GB database. The following parameter settings are recommended based on the results of the above test
Table 3-1 Oracle Initialization Parameters
|
Name
|
Value
|
|
Oracle Version compatible
|
8.1.0
|
|
db_block_buffers
|
96000
|
|
db_block_lru_latches
|
30
|
|
db_block_size
|
8192
|
|
instance_name
|
VORTEX
|
|
enqueue_resources
|
20000
|
|
log_buffer
|
5120000
|
|
open_cursors
|
500
|
|
rollback_segments
|
(RBS0, RBS1, RBS2, RBS3, RBS4, RBS5, RBS6, RBS7, RBS8, RBS9, RBS10, RBS11, RBS12, RBS13, RBS14, RBS15, RBS16, RBS17, RBS18, RBS19, RBS20, RBS21, RBS22, RBS23, RBS24, RBS25, RBS26, RBS27, RBS28)
|
|
shared_pool_size
|
419430400
|
|
sort_area_retained_size
|
1024000
|
|
sort_area_size
|
5120000
|
For an explanation of other parameters, refer to the Oracle 8.1.7 / 9i Administrators Guide.
Configuring Net8
All the installation scripts use SQLPLUS, which in turn connects using the Net8 configuration to support installation from client machines. If you are installing on the server machine, make sure that Net8 is configured.
SQLPLUS should be able to connect to the net_service_name setup in Net8. For example
-
sqlplus userid/passwd@net_service_name
Configuring iPlanet Market Maker for the Databases
After the installation, the iPlanet Market Maker software needs to be configured to ensure that the connections to the LDAP and the Oracle databases are available from the iPlanet Market Maker host and that the job scheduler runs properly.
The following sections discuss the tasks involved:
Connecting to Remote LDAP Instances
Presently the iPlanet Market Maker Installer is not equipped to carry out a remote login and installation of the LDAP schema and data from a web server/iPlanet Market Maker host. However, the Installer queries the user for the remote host names, port numbers, user name, and password of the LDAP, even while carrying out the installation of the iPlanet Market Maker core, in order to make the appropriate settings in the property files. Specifying the correct locations of these hosts and port numbers during installation of the iPlanet Market Maker software makes the appropriate changes to the VortexConfiguration and userxConfiguration files. Nonetheless, the following settings should be checked to ensure that they point to correct locations after the installation.
To connect to a remote LDAP instance
On the iPlanet Application Server/iPlanet Market Maker hosts, in the userxconfig.properties file, change the following settings to point to the correct host and port locations:
-
ldaphost: <remote host name>
-
ldapport: <port name on which the ldap instance listens >
On the web server/iPlanet Market Maker hosts, LDAP read and write user name and passwords can be found in the VortexConfiguration.properties file.
LDAP Connection Pool Settings
On the iPlanet Application Server/iPlanet Market Maker hosts in the userxconfig.properties file, change the following settings to new values:
-
ldappool.minimum=150 (Default Value : 10)
-
ldappool.maximum=300 (Default Value : 20)
Each connection handles client requests serially. The minimum and maximum settings depend on the number of concurrent users. 150/300 per LDAP connection pool is a safe setting for an expected number of 300 concurrent users per web server.
Connecting to Remote Oracle Instances
The setting that points to the database URL for the type four drivers needs to be changed to ensure that the remote host name is included in the URL instead of the local host name.
On the iPlanet Application Server/iPlanet Market Maker hosts in the VortexConfiguration.properties file, change the following setting to point to the correct host and port locations:
-
CFG_DATABASE_URL=-jdbc:oracle:thin:@<remote host name>:1521:<instance_name>
Oracle Connection Pool Settings
On the web server/iPlanet Market Maker hosts in the VortexConfiguration.properties file, change the following settings to new values:
-
CFG_CPOOL_MAXIMUM=500 ( Default Value : 30)
Multiple database connections per user are required to be opened for some of the requests received from the code. To avoid running out of database connections, 500 is a safe value for the maximum connection pool size/web server for loads of up to 300 concurrent users through each iPlanet Market Maker host.
Configuring the Schemas
Each module (Catalog, Pricing, Community, Architecture (also known as Common), Auction, RFx, Exchange, and Order Management System) has its own database schema owner. The schema owners are CAT, PRI, COM, CMN, AUC, RFX, OMS and EXC. The passwords are entered during installation for each module (for example, CAT/CAT_PWD). All the objects (that is, tables, sequences, and so on) owned by these schema owners are granted to the application user VORTEX. The password for VORTEX user is entered during installation. The iPlanet Market Maker user interface connects to the database from the application servers using the application user (VORTEX).
Table 3-2 lists the values that need to be given for the Oracle settings during installation.
Table 3-2 Oracle Settings
Module Name
|
Schema / Password
|
Default Tablespaces
|
|
Data
|
Index
|
Temporary
|
|
Architecture (common)
|
CMN/CMN_PWD
|
CMN_TS
|
CMN_XTS
|
TEMP
|
|
Catalog
|
CAT/CAT_PWD
|
CAT_TS
|
CAT_XTS
|
TEMP
|
|
Pricing
|
PRI/PRI_PWD
|
PRI_TS
|
PRI_XTS
|
TEMP
|
|
Auction
|
AUC/AUC_PWD
|
AUC_TS
|
AUC_XTS
|
TEMP
|
|
Negotiations
|
RFX/RFX_PWD
|
RFX_TS
|
RFX_XTS
|
TEMP
|
|
Order Management System
|
OMS/OMS_PWD
|
OMS_TS
|
OMS_XTS
|
TEMP
|
|
Exchange
|
EXC/EXC_PWD
|
EXC_TS
|
EXC_XTS
|
TEMP
|
|
iPlanet Market Maker
|
VORTEX/VORTEX_PWD
|
CMN_TS
|
CMN_XTS
|
TEMP
|
Oracle schema creation is done as a part of installation using the iPlanet Market Maker Installer. The iPlanet Market Maker Installer provides the option of installing the following independently:
Make sure that the option to create Oracle schema is checked (check box). The Installer uses the $IMM_HOME/setup/bin/installsql.sh script by passing the appropriate parameters. This install script uses the file $iMM_HOME/setup/etc/ backendmodules which has a list of modules to be installed in the right order for the database schema. The module names correspond to the directories under $IMM_HOME. The main installation script calls sql install script $IMM_HOME/ <module>B/sql/install.sh. These module specific install scripts create tablespaces, users, and all the database schema objects owner using the $IMM_HOME/ <module>B/sql/installParams.env file. All the SQL scripts that create the schema have drop statements before creating the objects.
The following points are worth noting during schema creation:
All the data table spaces are created in the directory, which is provided as "datafile location/datafile name" given during installation. The recommended naming convention for the data files is:
-
<abbreviated_name_of_module>01_Oracle_SID
-
An example for the Auctions module:
-
auc01_vortex
All the index tablespaces are created in the directory which is provided as "index datafile location/datafile name" with the same data file size during installation.
All the schema and application users are created, and their temporary tablespace set to use TEMP tablespace.
The initial installation uses the default settings for storage parameters provided by the scripts for create table and index statements.
The SQL scripts have a drop statement before each of the create statements. During initial installation, all the drop statements would throw errors, because there are no iPlanet Market Maker objects in the database. Subsequent runs will drop and recreate the tablespaces, users, and objects.
|
Caution
|
Running the $IMM_HOME/setup/bin/installsql.sh script, or any SQL script, erases the iPlanet Market Maker schema without warning. Do not run these scripts in a production system when the iPlanet Market Maker installation is running and has data in it. These are install scripts and should be run only during installation.
|
An execution log is generated each time the script runs. Also, a post install log file, which contains all the database script logs including the script execution and errors, is created. These logs can be helpful in trouble shooting. The script stops if it encounters any SQL statement errors due to create statements or connect statements. Otherwise, it will continue the execution even though there are other errors due to drop statements; these should be ignored.
During installation, and before running the scripts, the Installer unzips and copies all the scripts to their appropriate locations. To make the changes to the schema scripts for storage and others, the scripts need to be edited and run again.
|
Note
|
Make a backup of the file and do not change the name of the file.
|
Sizing Objects (Tables and Indexes)
It is recommended that the deployment team estimate the storage requirements for the modules and modify the storage parameters (hard disk space) of the tables and indexes for the production installation.
The installation scripts for iPlanet Market Maker software can be found in the $IMM_HOME/setup/sql and $IMM_HOME/<module_name>/sql directories. The directory $IMM_HOME/setup/sql/schema contains the create SQL script which creates the tablespaces and schema users. The Installer passes the datafile, index file location, and its sizes to this script. Also, each module (for example, cmn, auc, catalog and so on) has a directory sql, which contains the create table scripts (for example: $IMM_HOME/setup/catalog/db/sql/schema/*.sql files). Each table is created using these scripts. The storage parameters for the create tables scripts need to be examined, and changed based on the size of the marketplace. Default values are given to most of the create table parameters such as pctfree, pctused, initial extents, next, and pctincrease.
Database administrators are advised to change the sizing parameters for the tables depending on the data storage requirements for the tables. Appendix A "Oracle Table Sizing Information" serves as a guide in calculating the storage parameters. The average row lengths presented in the table are based on performance tests carried out on iPlanet Market Maker installation in the test labs. The actual row lengths for each installation will vary, so the DBA should add 10 to 30 percent to the provided values based on their judgement.
There are two ways to recreate the schema using the changed parameters:
Re-installing the Database Schema Using the Installer
Run the iPlanet Market Maker Installer.
Uncheck the iPlanet Market Maker Core and iPlanet Market Maker Directory Server database.
Ensure that the iPlanet Market Maker Oracle database is checked.
Re-enter the same parameters that have been used during initial installation for encryption, passwords, LDAP details, and so on. Do not make any changes from initial input when re-installing.
Verify changes in the database.
Re-installing the Database Schema Using Scripts
Follow the installation instructions in the "Importing and Configuring Data" section.
Make sure that the VORTEX_SID environment parameter is set to net_service_name.
Verify that the module passwords (for example, auc_pwd) are set in the environment before running the script.
Verify changes in the database.
|
Caution
|
The iPlanet Market Maker software does not support any changes to the database schema. No addition, modification, or deletion should be made to tables, columns, or indexes. The iPlanet Market Maker software does not support the use of SQLPLUS or any third party tools to manipulate the data directly. The iPlanet Market Maker APIs should be used to manipulate the data in accordance with the customization guidelines. For details, refer to the iPlanet Market Maker Customization Guide.
|
Catalog Module
The size of the catalogs (both the master catalog and the buyer catalogs) affects the response times of the search and browse operations directly. When the master catalog is loaded, some of the main tables opened are CAT_MASTER_ENTRY, CAT_ATTR, and CAT_SEARCH_ATTR. The number of initial and next 'extents should be configured to match the size of the catalog to achieve best performance. When buyers log in and create buyer catalogs (catalog views and not Oracle views), the table CAT_VIEW_ENTRY is populated with the pointers to the tables CAT_MASTER_ENTRY and CAT_ATTR. A seller catalog of 100K entries in CAT_MASTER_ENTRY can have 500K rows in CAT_VIEW_ENTRY, if five views are created by five different buyers (showing all the master catalog). So the number of rows in CAT_VIEW_ENTRY can grow as buyers create views of master catalogs. Creation of buyer catalogs also adds records into the CAT_ATTR table for each category.
The following table gives the recommended sizes of extents for core tables and their indexes for the Catalog module. These numbers can vary depending on catalog structure (categories and items) and the number of attributes for each item.
Table 3-3 Recommended Sizes of extents for Catalog Database
|
Oracle Table (Indexes)
|
Rows
(Catalog items)
|
Recommended storage
Size of extents
|
|
CAT_MASTER_ENTRY
|
100000
|
20 MB
|
|
CAT_MASTER_ENTRY(index)
|
100000
|
20 MB
|
|
CAT_VIEW_ENTRY
|
275000
|
60 MB
|
|
CAT_VIEW_ENTRY(index)
|
275000
|
60 MB
|
|
CAT_ATTR
|
800000
|
130 MB
|
|
CAT_ATTR(index)
|
800000
|
130 MB
|
|
CAT_SEARCH_ATTR
|
20000
|
3 MB
|
|
CAT_SEARCH_ATTR(index)
|
20000
|
3 MB
|
Auctions Module
The size of extents for the core tables and indexes of the Auctions module is determined by the number of auctions and the number of bids for each auction
Table 3-4 Recommended Sizes of extents for Auctions Database
|
Oracle Table (Indexes)
|
Rows
(Auction components)
|
Recommended storage
size of extents
|
|
AUC_AUCTION
|
30000
|
50 MB
|
|
AUC_AUCTION(indexes)
|
30000
|
25 MB
|
|
AUC_BID_HISTORY
|
400000
|
100 MB
|
|
AUC_BID_HISTORY(indexes)
|
400000
|
60 MB
|
Exchange Module
The size of extents for the core tables and indexes of the Exchange module is determined by the number of orders and the number of trades.
Table 3-5 Recommended Sizes of extents for Exchange Database
|
Oracle Table (Indexes)
|
Rows
(Exchange components)
|
Recommended storage
size of extents
|
|
EXC_PROCESSED_MESSAGES
|
100000
|
30 MB
|
|
EXC_NVP_PASSIVE_ORDER
|
100000
|
30 MB
|
|
EXC_NVP_PASSIVE_AXIS
|
300000
|
60 MB
|
|
EXC_ORDER_REQUESTS
|
100000
|
40 MB
|
|
EXC_ORDERS_TEMP
|
100000
|
40 MB
|
|
EXC_ORDER_REQUEST_CRITERIA
|
1000000
|
40 MB
|
|
EXC_ORDER_REQUEST_LIFESPAN
|
100000
|
25 MB
|
|
EXC_ORDER_SCHEDULER
|
1000000
|
20 MB
|
|
EXC_ORDERS
|
100000
|
40 MB
|
|
EXC_0RDER_AXES
|
300000
|
80 MB
|
In-Box Notification
In-box notifications and messages are stored in the iPlanet Market Maker infrastructure under the tables INBOX_ENTRY and CMN_PLM. The INBOX_ENTRY table contains all the inbox notifications. CMN_PLM is the container for all the custom messages for each object based on Java property files.
Table 3-6 Recommended Sizes of extents for In Box Notification
|
Oracle Table (Indexes)
|
Rows
(Auction components)
|
Recommended storage
size of extents
|
|
INBOX_ENTRY
|
100000
|
60 MB
|
|
INBOX_ENTRY(indexes)
|
100000
|
25 MB
|
|
CMN_PLM
|
540000
|
45 MB
|
|
CMN_PLM(indexes)
|
5400000
|
12 MB
|
|
CMN_PLM_STRING
|
650000
|
30 MB
|
|
CMN_PLM_STRING(indexes)
|
650000
|
14 MB
|
The extent sizes are calculated based on default sizing parameters (percent free, and so on) for the respective tables, as provided in the iPlanet Market Maker table scripts. If the values for other parameters are changed, the extent sizes should be recalculated.
Setting the Job Scheduler
The job scheduler runs in its own JVM, separate from the JVM in which the presentation and runtime layers of the iPlanet Market Maker software run.
The job scheduler process reads the loaded properties from the VortexConfiguration.properties file. This file has to be included in the classpath for the job scheduler process. The following properties must be modified for the job scheduler process:
Maximum Heap Size for the JV
To set the maximum heap size for the JVM in which the job scheduler process runs, set the Xmx256M option to 256 MB. This maximum heap size is sufficient for about 600 jobs registered with the job scheduler process.
-
#CFG_JS_EXE
-
# - The JobScheduler process.
-
37=java -Djava.compiler=NONE -Dvortex.logFile=jobscheduler.log -Xmx256m
-
com.iplanet.ecommerce.vortex.util.scheduler.JobSchedulerProcess
OnceOnly and Repeatable Timer Thread Pool Sizes
Notifications about marketplace events, such as bidding on auctions, submitting orders to vendors, or approval of requisitions, are sent to users by email or to the users Shared In-Box. Users can configure this notification job, and the job scheduler is the process that ensures that such notification jobs are triggered.
The job scheduler process has a OnceOnly timer thread and a Repeatable timer thread.
These two threads keep a Job List updated for two worker thread pools:
To provide for concurrent job requests, the numbers of workers in these two worker thread pools must be set to appropriate values.
OnceOnly Worker Thread Pool Size
The major load on the OnceOnly worker threads will be auctions opening and closing events. The actual value of the pool size should be determined based on the volume of auctions opening/closing on a site each day. For a fairly auction- intensive site, the safe value is 20, because all 20 worker threads will be called from their wait state only if there are 20 concurrent open auction or close auction jobs at the same instant on the site.
-
# CFG_JS_ONCEONLY_NUM_WORKERS
-
# Total number of workers in the thread pool for the OnceOnly Timer.
-
38=20 ( Default value = 3 )
Repeatable Worker Thread Pool Size
The two repeatable timers that can be registered with the job scheduler are the Transactional Mail Scheduler and the RFx job scheduler.
The Transactional Mail Scheduler is a repeatable timer implemented for reading new entries in mail_info and handing over the registered notifications to the Notifier thread pool for delivery to the Mail Transfer Agent.
The RFx job scheduler is the RFx reaper that marks as pending those RFx requests and replies that are due to expire in less than or equal to one day.
To account for any concurrent repeatable requests from these timers, 4 is a safe value for the Repeatable thread pool size.
-
#CFG_JS_REPEAT_NUM_WORKERS
-
# - Total number of workers in the thread pool for the Repeat Timer.
-
39=4 ( Default value = 3 )
Sleep Interval for OnceOnly Thread
The OnceOnly database polling thread polls the cmn_job_scheduler_entry table in order to read any new or revised timers after the last read in order to keep the job queue for the OnceOnly thread pool in synchronization with additions and changes to the timers.
Asleep of two minutes between polls is a lower load on the database and is not too great a sacrifice in terms of synchronizing with the current status of timers and the job queue for the OnceOnly pool.
In a rare case, one would have auction-open timers registered for opening within two minutes of the job registry or have close times extended just two minutes before auction close time. In such rare occurrences, the two-minute sleep could result in unacceptable delayed callbacks. In such cases, decrease the sleep interval to an appropriate value.
-
#CFG_JS_ONCEONLY_SLEEP_INTERVAL
-
# - Sleep interval for the OnceOnly timer database thread in milliseconds.
-
40=120000 ( Default value = 30000 )
Repeat Sleep Interval
The Repeat database polling thread polls the cmn_job_scheduler_entry table in order to read any new or revised timers since the last read in order to keep the job queue for the Repeat thread pool in synchronization with additions and changes to the timers.
The two-minute sleep between polls is a good trade off between the load on the database and the synchronizing of the current repeat timer status and the job queue for the Repeat thread pool. The Transactional Mail Scheduler and the RfxJobScheduler repeat timers are registered at module initialization time and are not expected to have any immediate changes after registry.
-
#CFG_JS_REPEAT_SLEEP_INTERVAL
-
# - Sleep interval for the Repeat timer database thread.
-
41=120000 ( Default value = 60000 )
Transactional Mail Scheduler Interval
The Transactional Mail Scheduler (TMS) is a repeatable timer registered by the application for the purpose of sending out email notifications. The time for callback can be configured by a setting in the VortexConfiguration.properties file. On callback, the TMS reads the entries in the table mail_info and makes calls to the Notification API to send out the emails and deletes the entries in the mail_info table after they have been handed over to the Notification API.
The sleep interval for the TMS can be increased from its default value of 30 seconds to 120 seconds. This lowers the database load considerably while sacrificing a bit on the up-to-the-current-second correctness of the email notifications. The time lag between handing over an email notification to the Notifier Thread Pool and it actual delivery depends largely on the settings in the mail transfer agents involved in the delivery chain. Therefore, this sacrifice is negligible if it buys some performance gains.
-
#CFG_TRANSACTIONAL_MAIL_SCHEDULER_INTERVAL
-
# - Timeout interval parameter for the MailScheduler callback. (used for Notifications)
-
60=120000 ( Default value = 30000 )
Max Threads in Notifier Pool
The Notification API hands over the dispatch of all emails to a set of worker threads called the Notifier Thread pool. Increasing the sleep interval of the Transactional Mail Scheduler would result in a larger load of emails the TMS hands over to the Notifier Thread Pool whenever its callback is run. The larger load on the pool necessitates a corresponding increase in the thread pool size. The actual setting will depend on the volume of email notifications expected to be generated in the sleep period for the Transactional Mail Scheduler.
-
#CFG_MAX_THREADS_IN_NOTIFIER_POOL
-
# - Number of threads in the notifier thread pool.
-
32=30 ( Default value = 10 )
-
|
Note
|
At various places in this document, it is described how to configure the user interface and the performance parameters by changing the settings in the VortexConfiguration.properties and userxconfig.properties files. The Installer places two copies of all the properties files in two different locations as follows:
Whenever you change the value or the parameter for any property, you should make the changes in both locations and restart the iPlanet WebServer and the iPlanet Application Server.
After the installation of iPlanet Market Maker software, you can find the file VortexConfiguration.properties file in the following two locations:
<iAS_Install_Dir>/ias/APPS/imm40/imm40/WEB-INF/classes
<iMM_HOME>/resources
You can find the userxconfig.properties file in:
|
Importing and Configuring Data
The iPlanet Market Maker software works with two types of schema and data iPlanet Directory Server (LDAP) and Oracle. Catalogs are stored in the Oracle database.
|
Note
|
The Installer does the configuration, but if you need to import and configure data manually, follow the steps in this section.
|
This section contains the following sections:
Creating the LDAP Schema
Source the mm.kshrc file.
For iDS 4.13:
-
In the <iPlanet-Home>/slapd-<instance name>/config/ns-schema.conf file (where <iPlanet-Home> is the directory where you installed the directory server), append these three lines:
-
include <IMM_HOME>/community/ldap/schema/ iplanet-marketmaker-schema.conf
-
include <IMM_HOME>/community/ldap/schema/ iplanet-userx-schema.conf
-
include <IMM_HOME>/community/ldap/schema/ iplanet-ecommerce-schema.conf
-
For iDS 5.0 SP1:
-
Copy $IMMHOME/infrastructure/ldap/schema/iDS50SP1/60iplanet-ecs.ldif to your iDS50SP1 install directory, <iPlanetHome>/slapd-<instance name>/config/schema
Restart iPlanet Directory Server.
For iDS 4.13:
-
In the directory <IMM_HOME>/infrastructure/ldap/schema, there is a file called createimmsuffix.ldif, which should be imported before loading the data.
-
For iDS 5.0 SP1:
-
In directory $IMMHOME/infrastructure/ldap/schema/iDS50SP1/ there is a file called createiMMSuffixDb.ldif, which should be imported before loading the data
Load the LDAP data.
|
Note
|
Presently, there is no utility for bulk loading the community data other than making the data available in an LDIF format conforming to the iPlanet Market Maker LDAP schema.
|
Deleting the Existing LDAP Data
To delete the LDAP data:
Source the environment using the $IMM_HOME/mm.kshrc file or the $IMM_HOME/mm.cshrc file.
If required:
-
cd $IMM_HOME/bin
Run the DeleteCommunity.sh script with hostname slapd_port, "cn=Directory Manager" directory_manager_passwd.
Creating the Oracle Schema
Source the environment using the $IMM_HOME/mm.kshrc or the $IMM_HOME/mm.cshrc file.
Create environment variables as follows:
-
VORTEX_SID=<net_service_name>
-
COM_PWD=<schema password>
-
CMN_PWD=<schema password>
-
CAT_PWD=<schema password>
-
AUC_PWD=<schema password>
-
PRI_PWD=<schema password>
-
OMS_PWD=<schema password>
-
EXC_PWD=<schema password>
-
RFX_PWD=<schema password>
-
VORTEX_PWD=<schema password>
-
These environment variables will be passed to the execution scripts which will overwrite the parameters in the installparams.env file.
Run the $IMM_HOME/setup/bin/installsql.sh schema script.
Run the $IMM_HOME/setup/bin/installsql.sh seed script.
Import the Oracle sample data:
Follow the instructions in Steps 1 and 2 above.
Run the $IMM_HOME/setup/bin/installsql.sh sample script.
Running iPlanet Market Maker Software Over SSL (Secure Sockets Layer)
Viewing HTTPS Sites (External URLs) in the iPlanet Market Maker Software
The iPlanet Market Maker software facilitates a user to embed an external site on any iPlanet Market Maker page.
HTTP sites are non-secure and can be embedded on any iPlanet Market Maker page, while HTTPS sites are secure and cannot be embedded.
The URL class in JDK1.2.2 does not recognize HTTPS as a legal protocol. When using JSSE 1.0.2, the HTTPS protocol becomes a legitimate protocol for JDK1.2.2. It can then be recognized to access any secure site, as long as the certificate is installed on the server.
Install and Customize the iPlanet Market Maker Software for Secure Site Access
|
Note
|
Installation and Customization should be done on the machine where the iPlanet Market Maker software is installed.
|
"Download JSSE 1.0.2 from the Sun Site"
"Install JSSE Pack"
"Install the Certificate of the Secure Site"
"Set the Security Provider"
"Set the Configuration Parameters"
Download JSSE 1.0.2 from the Sun Site
The JSSE 1.0.2 pack can be downloaded from the following site:
http://java.sun.com/products/jsse/index-102.html
JSSE 1.0.2 is supplied as an extension to the java-2 platform. JSSE is implemented via a Java Cryptography Architecture (JSA) security provider class called sunJSSE.
|
Note
|
Choose the appropriate path separator for Windows and Solaris.
|
When <ias-java-home> is used in this document, it refers to the \iplanet\ias6\ias\usr\java\jre directory.
Install JSSE Pack
JSSE is a zip file. When the zip file is extracted, it creates the jsse1.0.2 directory, with two subdirectories named doc and lib.
Select the jsse.jar, jcert.jar, and jnet.jar files from the jsse1.0.2\lib directory.
Copy them to the <ias-java-home>\lib\ext directory.
Install the Certificate of the Secure Site
Install a JSSE-specific cacerts file.
It can be installed in the <ias-java-home>\lib\security directory with the name jssecacerts.
Sun's JSSE implementation checks for an alternate cacert file before falling back on the standard cacerts file, so you can provide a JSSE-specific set of trusted root certificates separate from the ones that might be present in cacerts for code signing purposes. The search order for the locating the trust store is:
<ias-java-home>/lib/security/jssecacerts
<ias-java-home>/lib/security/cacerts
-
If the file jssecacerts exists, then cacerts is not consulted.
Set the Security Provider
JSSE 1.0.2 comes standard with a Cryptographic Service Provider, or provider, named SunJSSE. Although the SunJSSE provider is supplied with every JSSE 1.0.2 installation, it still must be configured explicitly before its services can be accessed.
Add the SunJSSE Provider to Your List of Approved Providers
To add the security provider statically, add the following statement in <ias-java-home>/lib/java.security file:
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
|
Note
|
Do not delete security.provider.1=sun.security.provider.Sun that is the default security provider existing in the java.security file.
|
Set the Configuration Parameters
Open the vortexconfiguration.properties file and set the following properties:
java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
If you use proxy:
https.proxyHost=<your proxy host>
https.proxyPort=<your proxy port number>
These properties are read by the com.iplanet.ecommerce.vortex.arch.JvmSettings class and set as the system properties.