Professional Documents
Culture Documents
SIEBEL SERVER
INSTALLATION GUIDE
SIEBEL 2000
VERSION 6.3.1
10PA1-SI00-06310
MAY 2001
Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404
Copyright © 2001 Siebel Systems, Inc.
All rights reserved. Published 2001
Printed in the United States of America
No part of this publication may be stored in a retrieval system, transmitted, or reproduced in any way, including
but not limited to photocopy, photographic, magnetic or other record, without the prior agreement and written
permission of Siebel Systems, Inc.
The full text search capabilities of Siebel eBusiness Applications include technology used under license from
Fulcrum Technologies, Inc. and are the copyright of Fulcrum Technologies, Inc. and/or its licensors.
Siebel, the Siebel logo, TrickleSync, TSQ, Universal Agent, and other Siebel product names referenced herein
are trademarks of Siebel Systems, Inc., and may be registered in certain jurisdictions.
All other product names, marks, logos, and symbols may be trademarks or registered trademarks of their
respective owners.
U.S. GOVERNMENT RESTRICTED RIGHTS. Programs, Ancillary Programs and Documentation, delivered
subject to the Department of Defense Federal Acquisition Regulation Supplement, are “commercial computer
software” as set forth in DFARS 227.7202, Commercial Computer Software and Commercial Computer Software
Documentation, and as such, any use, duplication and disclosure of the Programs, Ancillary Programs and
Documentation shall be subject to the restrictions contained in the applicable Siebel license agreement. All
other use, duplication and disclosure of the Programs, Ancillary Programs and Documentation by the U.S.
Government shall be subject to the applicable Siebel license agreement and the restrictions contained in
subsection (c) of FAR 52.227-19, Commercial Computer Software - Restricted Rights (June 1987), or
FAR 52.227-14, Rights in Data—General, including Alternate III (June 1987), as applicable. Contractor/licensor
is Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404.
Proprietary Information
Siebel Systems, Inc. considers information included in this documentation and
in Siebel Online Help to be Confidential Information. Your access to and use of
this Confidential Information are subject to the terms and conditions of: (1) the
applicable Siebel Systems software license agreement, which has been executed
and with which you agree to comply; and (2) the proprietary and restricted
rights notices included in this documentation.
Siebel Server Install Guide
Contents
Introduction
Who Should Use This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-2
How This Guide Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-3
Sequence of Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-3
Other Books You Will Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-4
What’s New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-5
Additional Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-6
Contacting Siebel Technical Support . . . . . . . . . . . . . . . . . . . . . . . . Intro-7
Siebel Welcomes Your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . Intro-8
Chapter 1. Overview
About the Siebel Server Installation Guide . . . . . . . . . . . . . . . . . . . . . . 1-2
The Siebel Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Siebel Client Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Siebel eBusiness Application System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Siebel File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
Siebel Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
Before You Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Useful Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Index
This guide provides information, instructions, and guidelines for installing your
Siebel eBusiness Applications product.
Siebel System Persons responsible for the whole system, including installing,
Administrators maintaining, and upgrading Siebel products.
Database Persons who administer the database system, including data
Administrators loading; system monitoring, backup, and recovery; space
allocation and sizing; and user account management.
Installers Persons responsible for setting up Siebel systems for initial use. An
installer is typically a system administrator, a database
administrator, or someone from the Information Services
department.
Configurators Persons responsible for planning, implementing, and configuring
Siebel applications. A configurator is typically a consultant or
someone from the Information Systems department.
This guide provides information that is necessary to install Siebel Server and Client
applications. It is organized to provide a logical and sequential explanation of the
steps necessary to install Siebel software.
Each chapter is devoted to a different topic. Except for Chapter 1, “Overview,” and
Chapter 2, “Preparing for the Installation,” the material in this book is divided into
parts that focus on particular types of installations. To make the best use of this
manual, read Chapter 1 and Chapter 2 first.
At the beginning of each chapter is a section titled “About This Chapter,” which
covers information you will need if you are responsible for the part of the
installation process covered in that chapter.
When you need to refer to outside documentation, you will find specific
information about what you should read and where. For example, there are several
junctures within the installation process that will require you to refer to the Siebel
Client Installation and Administration Guide and the Siebel Server Administration
Guide to complete the instructions provided in this guide.
Version 6.2 of Siebel eBusiness Applications has the following new features:
Feature Description
AIX UNIX support Supports the AIX UNIX platform at mid-tier for the Siebel
at mid-tier Gateway and Siebel Servers. Installation of the Siebel
Gateway and Siebel Server on the AIX platform is identical
to previous installation instructions for the Solaris
platform. Installation instructions particular to AIX users
can be found in Chapter 21, “Installing and Configuring the
.COM Applications Under UNIX” and Chapter 23,
“Installing the Siebel Report Server Under UNIX.”
IBM HTTP Server Supports use of IBM HTTP Server for use by customers
support working on the AIX UNIX platform. For information, see
Chapter 21, “Installing and Configuring the
.COM Applications Under UNIX.”
UTF-8 UNICODE Supports use of UTF-8 UNICODE for the Oracle 8i
support on the Enterprise Server. For information, see Chapter 14,
Oracle RDBMS “Configuring the Oracle Database Server.”
Your Siebel implementation may not have all the features described in this guide,
which documents all features of all available configurations or platforms. Your
system will have the features provided by the software modules you have
purchased.
Because all versions of the UNIX operating system are case-sensitive, if you are
running your Siebel eBusiness Applications under UNIX, treat all filenames,
directory names, pathnames, parameters, flags, and command-line commands as
lowercase, unless you are instructed otherwise in the product.
If you currently run under Windows NT, but may switch to a UNIX environment at
some time in the future, it is a good idea to follow this same practice.
If you are running under IBM’s OS/390, you will want to make sure that these file
names, pathnames, parameters, and flags are all uppercase.
Siebel Release Notes provide the most up-to-date installation information and
supplemental instructions, as well as other useful information unavailable at the
time of printing for this Siebel Server Installation Guide. Siebel System Requirements
and Supported Platforms describes system requirements and supported platforms.
This guide does not provide information about installing Siebel components on a
dedicated client; general software concepts, such as records and queries; or using
Windows and UNIX. Neither does it provide instructions for basic navigation of
Siebel applications. For instructions on how to install Siebel on a dedicated client,
refer to the Siebel Client Installation and Administration Guide. For general
concepts about Siebel applications, refer to Siebel Basics.
For copies of these documents, please use Siebel Books Online, accessible through
the Global Services tab on the Siebel Systems Web site
(http://www.siebel.com). Through Siebel Books Online, you can order
additional Siebel documentation and copies of the Bookshelf for Siebel eBusiness
Applications CD-ROM.
For the most current and accurate documentation, see the Documentation Updates
section of the Siebel SupportWeb site (http://supportweb.siebel.com). The
SupportWeb page contains changes that we have made to the documentation since
it was released.
You will find information about Siebel Technical and Professional Services in the
Guide to Siebel Global Services.
Do you know how to access Siebel Technical Support? It is crucial that you
understand the requirements for getting support before you encounter technical
issues that require Siebel Technical Support’s assistance. This will facilitate smooth
resolution of any issues. If you have questions, please do not hesitate to contact us.
To provide efficient and timely support, and to empower you in the process:
Please submit your technical issues and updates to Siebel SupportWeb (http://
supportweb.siebel.com). If you do not have a SupportWeb account, or if you
have a question, please contact us at suppor@siebel.com or call your local Siebel
Support Center below:
Outside of local support center hours, Gold and Rollout Support Option customers
can call +1 800 214 0400 or +1 650 295 57 24.
doc@siebel.com
This guide provides information and instructions for installing your Siebel
Enterprise Server components.
Familiarity with the Windows platform (Windows 95, Windows 98, or Windows
NT) under which your Siebel Dedicated Clients will run.
The guide also explains how to install your Siebel application on several databases,
operating system, and application server platforms. However, specific database and
operating system platforms, as well as certain combinations of them, may not be
supported in the current release. For a list of all operating system platforms and
RDBMS products supported by this release, consult Siebel Release Notes and Siebel
System Requirements and Supported Platforms, included with your Siebel product.
This chapter contains an overview of your Siebel application and how it works.
Below is a summary of the entities that make up the Siebel eBusiness Applications.
In the following sections are a diagram that illustrates the architecture of a Siebel
deployment and, following that, detailed descriptions of each type of server and
client.
The Siebel Gateway Server. The Gateway Server, as its name suggests, handles
connections between clients and servers in a Siebel deployment. The Gateway
Server consists of the Name Server and optional Resonate Central Dispatch
servers.
The Siebel Server. A Siebel Server, depending on which Siebel components are
installed on it, manages one or more components of the Siebel application. One
or more of these servers provides both batch mode and interactive services to
Siebel clients.
The Siebel Database Server. The database server stores your business data in a set
of predefined tables and provides that data to Siebel Servers and dedicated
clients on request.
The Siebel File System. This is a network-accessible hard disk directory tree that
stores the files used by Siebel clients that the database does not manage.
Siebel Clients. Siebel Clients provide the interface for accessing data managed by
the Enterprise Server. Siebel clients include dedicated clients, mobile clients, and
thin clients of several different types.
Figure 1-1 is a logical diagram of the entities that make up the Siebel eBusiness
Applications environment.
Server Manager
Siebel File
System
Siebel
Database
You can deploy a mixture of dedicated, mobile, and thin clients. In addition to these
Siebel clients for individual users, you will need to install and configure one Siebel
dedicated client to be used as the server manager to administer the servers.
As you can see in Figure 1-1 on page 1-4, all Siebel eBusiness Applications
installations consist of the following four functional parts:
Siebel Clients
Siebel Enterprise Server (consisting of one or more Siebel Servers and one Siebel
Gateway Server)
The various Siebel clients connect to various servers (depending on the type of
client) to request data and analyze it in a wide variety of ways. Each of the Siebel
eBusiness entities is discussed in detail in the sections that follow.
The Siebel client is a computer that operates the Siebel Sales, Call Center, Field
Service, and/or Marketing client applications, accessing data and services from one
or more servers.
Dedicated client. The dedicated client (also known as the Siebel client and the
connected client) can operate in two modes:
Dedicated mode. Connects directly to the Siebel Database Server and the
Siebel File System. The dedicated client may also interact with Enterprise
Server components for additional functionality. A dedicated client does not
store any Siebel data locally.
Mobile mode. Makes use of a local database. The mobile client (typically a
laptop computer used by a field sales or service representative) operates
without a real-time connection to any of the servers. The mobile client
downloads a portion of the Siebel Database and the Siebel File System to the
laptop so that users access the data locally. The mobile client periodically
accesses the Siebel Server by a dial-up, WAN, or LAN connection to
synchronize data changes with the Database Server and File System.
Thin client. Siebel thin clients run inside a standard Web browser from the client
PC, or (in the case of the Java Thin Client) are invoked through the Web browser,
but run in an independent window. Like the dedicated client, thin clients do not
store data locally. Unlike the dedicated client, thin clients connect directly to the
enterprise server and, in some cases, the Web server, but not to any other server.
The Siebel Server executes all business logic for the thin client.
Siebel Clients
Siebel Enterprise Server (consisting of one or more Siebel Servers and a Siebel
Gateway Server)
Name Server
The Name Server provides persistent backup storage of the configuration
information for all Siebel Servers within the Siebel Enterprise Server group or
groups it supports, including component definitions and assignments, operational
parameters, and connectivity. As this information changes—for example, during the
installation of a Siebel Server or as the Siebel Server is configured through the
Server Manager—the configuration information is written to the Name Server.
When starting up, the Siebel Server obtains its configuration information from the
Name Server.
Only one Name Server exists for each Siebel deployment. Siebel supports the high-
availability features of some platforms to ensure high availability of the Name
Server.
Scheduler. Brokers Siebel connection requests across Siebel Servers and also
monitors the load of each Siebel Server.
Central Dispatch does not require dedicated server hardware; its components are
installed on all application servers that will support a Siebel Server or a Siebel
Gateway Server.
NOTE: For best system performance and availability, Siebel Systems recommends
that you install the primary scheduler on one dedicated application server that does
not run any other Siebel components.
In version 6.x, the Siebel Gateway Server can provide connection brokering for the
following client connections to Siebel Server components:
Connections from all Siebel Thin Clients or the Siebel Web Engine.
Siebel Dedicated Client requests to the Request Processor or Request Agent
server components, which provide interactive access to the Assignment
Manager and other server components.
NOTE: One Siebel Gateway Server can support multiple Siebel Enterprise Servers,
but Siebel Systems does not recommend this except for development and test
environments due to possible impact on system availability and performance.
Siebel Servers are fully integrated with the Central Dispatch scheduler. The
configuration information that the Gateway Server uses to broker connections is
automatically updated as Siebel Servers are started or stopped, or as their
configurations are modified.
All Siebel Servers that connect to a common database must be installed within the
same Enterprise Server; that Enterprise Server can support only that single database
and the Siebel Servers connected to it.
The Enterprise Server itself has no processes and hence cannot have a state.
However, start and stop operations can be executed at the Enterprise level to apply
to all Siebel Servers within the Enterprise.
Siebel Server
Each Siebel Server is part of an Enterprise Server consisting of at least itself. The
Siebel Server supports both back-end and interactive processes for all the Siebel
eBusiness Applications clients.
Many of the Siebel Server components are multithreaded, and multiple instances of
components can run on multiple Siebel Servers simultaneously to support increased
numbers of users or larger batch workloads. The Siebel Server Manager, discussed
in the next section, allows the Siebel Administrator to modify the parameters
governing the operation of each component and to determine on which Siebel
Servers a given component can operate.
Start, stop, pause, and resume Siebel Servers, components, and tasks.
Monitor status and collect statistics for all multiple tasks, components, and
Siebel Servers within an Enterprise.
Configure the Siebel Enterprise Server, individual Siebel Servers within the
Enterprise, individual components, and tasks.
Any server or other machine that uses the command-line version for automating
control of the Enterprise Server.
On Windows NT–based systems, the Server Manager GUI should be used for most
administrative duties. The GUI offers a more intuitive view into the operation of the
Siebel Servers than the command-line interface. For customers with Windows-only
servers and clients, the GUI provides the only administration option.
For customers using Windows clients and UNIX servers, a Windows client can still
be used to administer the Siebel Server. To administer Siebel Servers directly from
a supported UNIX system, you will need to use the command-line interface.
Customers using only UNIX servers and clients will use only the UNIX command
line tool.
When the Server Manager is invoked, it connects to the Siebel Gateway Server,
which knows exactly what each of the Siebel Servers in the Enterprise is doing,
which clients are connected to which servers, and which servers are available to
handle new connections. It retrieves the information it needs, and then connects
with each of the Siebel Servers in the Enterprise and starts an Administration
Manager component task.
All files in the Siebel File System are compressed and stored using a specialized
naming convention. Users should never access files directly from the File System.
Instead, these are manipulated through the Siebel client, which automates the
compression and naming tasks. When these files are initially accessed, they may
take longer to display because they must first be decompressed. Once opened, an
uncompressed file is cached, and its subsequent display will be faster.
Siebel Dedicated Clients read and write files directly to and from the Enterprise’s
File System. Siebel Mobile Clients have a local File System, which they synchronize
with the server-based File System periodically. Siebel Thin Clients access the File
System through the Siebel Server.
All files in the File System are stored in a single directory and are distinguished by
filename prefix.
The Siebel Database Server stores the data used by Siebel eBusiness Applications.
Siebel eBusiness Applications supports several popular relational database
management systems (RDBMSs); the Siebel Database Server scripts configure the
database automatically. Siebel dedicated clients and Siebel Server components,
including those that operate in conjunction with the Siebel Thin Client, connect
directly to the Database Server and make changes in real time. Siebel Mobile Clients
download a subset of the server’s data to use locally, and periodically synchronize
with the Database Server through the Siebel Server to update both.
Before you start your Siebel installation, complete the following steps:
1 Carefully read Chapter 2, “Preparing for the Installation,” and fill out the
Deployment Planning Worksheet. A master copy of the Deployment Planning
Worksheet is located in Appendix A, “Deployment Planning Worksheet.” You
should photocopy this and fill out the copy as instructed.
2 Carefully read the relevant server installation chapters in this guide to ensure
that you understand the complete installation process for your operating system
and RDBMS platform combination.
4 Read the Siebel System Requirements and Supported Platforms and Siebel Release
Notes to be sure you know the supported computer and operating system
platforms and supported third-party programs for this release of your Siebel
application and for last-minute information.
Useful Resources 1
Your Siebel implementation team will perform a number of actions to install and
implement your Siebel application and will use several different Siebel documents
in the process:
If you are upgrading an existing Siebel deployment, you will need the Siebel
Upgrade Guide as well. If you have licensed Siebel Tools, you will find information
about configuring Siebel eBusiness Applications in the Siebel Tools Guide and the
Siebel Configuration Concepts Guide.
This chapter provides the preparation steps you must take before you begin
installing Siebel eBusiness Applications software. It also introduces you to the
Deployment Planning Worksheet, an integral part of the installation process.
As you work through the preparation steps in this chapter, you will be prompted to
record specific information you will need while installing and configuring Siebel
eBusiness Applications at your site.
Siebel components should be installed in the sequence in which they are introduced
in this book and illustrated in Figure 2-1.
No
Install Siebel
Gateway Server
Install Siebel
Server(s)
Install Siebel
Dedicated Client
No
Yes
Install Web Server Install Web Server ?
No
No
How many different Siebel Servers your Enterprise will need, and what
services will they provide? (Read about dedicating Siebel Servers for specific
services under “Dedicating Siebel Servers for Specific Services” on page 2-8.)
How many computers will you need to run the different servers your
enterprise will require? (Read about planning the number and types of
servers you deploy under “Planning the Topology of Your Siebel
Deployment” on page 2-10.)
Where to locate the servers for best connectivity and maintenance. (Read about
planning the layout of your servers also under “Planning the Topology of Your
Siebel Deployment” on page 2-10.)
Deployment Team 2
Write this information down in the copy you have made of Appendix A,
“Deployment Planning Worksheet.”
After you have determined which Siebel environments you will install, you must
determine:
On which machines and under which directory you want to install Siebel
components.
You should direct further sizing questions to your Siebel TAM (technical account
manager) or to Siebel Expert Services. For more information, see also the Siebel
Guide to Technical Services.
Verify which RDBMS products, versions, and patch levels are supported, check
Siebel System Requirements and Supported Platforms.
Choose the platform on which your database server will run, consult your
RDBMS manufacturer’s documentation and Siebel System Requirements and
Supported Platforms to determine which platforms are supported and what
issues must be addressed.
NOTE: No more than one RDBMS platform can exist within an enterprise. For
example, you cannot run both the Oracle and DB2 UDB databases.
When you have determined which RDBMS you will use, check off the proper choice
in Section 2: Deployment Overview on page A-2.
Do not make your production environment share servers with development and test
environments. While less intensively used Siebel environments, such as
development and test environments, may share the same physical equipment, your
production environment should have its own dedicated servers. In general, do not
load any one application server too heavily, or your Siebel system performance will
suffer.
For more information on establishing and using Siebel environments, see the Step-
by-Step Guide: An Example Implementation.
When you have determined which environments you will install on your site and
how many people each will support, write this information on your copy of
Appendix A, “Deployment Planning Worksheet.”
The installation process for all these servers is the same, with one exception—
Siebel Marketing. For this reason, installation instructions for Siebel Marketing are
located in the Siebel Marketing Guide rather than in this guide. Otherwise, you must
simply determine which Siebel products you will install, provide appropriate
computers for them, and include them in your planning. For example, you may
want to provide a dedicated server for Siebel Enterprise Integration Manager (EIM),
Siebel Remote, or other Siebel products.
When you have determined the number and types of Siebel Servers you require, and
how many people each will support, record this information in the copy you made
of Appendix A, “Deployment Planning Worksheet.”
One Siebel File System. Each file system must belong to one and only one
Enterprise Server.
Multiple Siebel Servers. Each Enterprise Server must have at least one Siebel
Server. Each Siebel Server must belong to one and only one Enterprise Server.
Siebel Servers execute business logic for Siebel clients, particularly for thin
clients, and access the database server on the clients’ behalf.
One Siebel Gateway Server. The Gateway Server does not have to be reserved for
the exclusive use of a single Enterprise Server, but each Enterprise Server can
only be connected to one Gateway Server.
Siebel Systems recommends that you have one dedicated Gateway Server with
only one Enterprise Server in a production environment.
One Siebel Database Server. Each database instance can only support one
Enterprise Server, and each Enterprise Server can support only one database
platform.
One application server must be configured to act as the primary Central Dispatch
scheduler and another to act as a secondary, or backup scheduler. Siebel
Systems strongly recommends that these two application servers be dedicated
for this purpose and that no Siebel components operate from them.
The topology of your Siebel deployment—the number, type, and capacity of your
computers (also referred to as application servers in this guide), and the distribution
of Siebel components across them—will vary considerably depending on the
number and type of Siebel clients that you are deploying.
Give each Siebel Server its own dedicated application server for best performance.
While you can install all the Siebel components—the Database Server, File
System, Gateway Server, and Siebel Server—on a single computer, the Siebel
architecture is expressly designed to scale by distributing these components
across multiple application servers. For maximum performance and scalability,
each Siebel Server should be installed on a dedicated application server.
Give the Database Server its own high-performance application server. Your RDBMS
must be sized appropriately for your deployment. For information on sizing and
tuning your RDBMS for optimum performance, refer to the documentation
provided by your RDBMS vendor.
Install enough Siebel Servers to run the components you need for the number of users
you will support. If you install several Siebel Servers, the workload can be
distributed among them to support larger numbers of Siebel Server components
and users. Resonate Central Dispatch can be used to balance requests for specific
server components automatically across multiple Siebel Servers.
Microsoft SQL Server users should not include brackets [] in their Siebel
Server and Enterprise Server names.
If you do not install the Central Dispatch scheduler on a dedicated server, install
it on an application server that will not support connection-brokered Siebel
Server components. Otherwise, the Central Dispatch scheduler attempts to route
connections away from the server on which it operates. If that server is operating
connection-brokered components, poor load balancing will result; the Siebel
Server on the primary scheduler will not be optimized, although load-balancing
will still occur, based on the rules established in Central Dispatch.
Note the IP address or host name of the servers that will support the primary
and secondary schedulers, and record this in a copy of Appendix A,
“Deployment Planning Worksheet.” This information will be required when you
are configuring Central Dispatch.
When using connection-brokering for large numbers of users, put the Central Dispatch
primary scheduler on one separate, dedicated application server and the Central
Dispatch secondary scheduler on a second. If your enterprise will make extensive
use of connection-brokering, Central Dispatch performs best if you locate the
primary and secondary Central Dispatch schedulers on their own dedicated
computers.
Connect the computers on which your Siebel applications will run to fast LANs. Siebel
Servers require high-speed local area network (LAN) connectivity. Siebel
Systems strongly recommends an FDDI, Fast Ethernet, or other high-speed LAN
to connect the Gateway Server, Siebel Servers, and Database Server.
Make sure that the LAN or mobile connections are adequate for your Siebel clients. All
dedicated clients require full-time network connectivity to the Siebel Database
Server and File System, and may also sometimes connect with the Enterprise
Server for additional functionality. Mobile clients must periodically connect to
the Siebel Server to synchronize data and files and can connect through a LAN
or through dial-up.
For information regarding supported network protocols for Siebel clients, see
Siebel System Requirements and Supported Platforms.
To provide both dynamic load balancing and high availability, implement both MSCS and
connection brokering in the same Siebel eBusiness Applications deployment. In this
hybrid installation scenario, the Siebel Gateway Server operates under MSCS for
high availability, as do those Siebel Servers operating non-connection-brokered
components. Other Siebel Servers operating connection-brokered components
such as the Application Object Manager can be installed on cluster nodes, but
do not operate under Microsoft clusters. Instead, connection brokering ensures
high availability and scalability for these components by distributing requests
between these components running on both cluster nodes.
If you will be implementing Microsoft Cluster Server (MSCS) and the connection-
brokering features of the Siebel Gateway Server, be aware that the two technologies
address very different operational requirements. You must plan your deployment
carefully to take advantage of the benefits of each technology.
MSCS is best suited to ensure the availability of those Siebel Enterprise Server
components that must be accessible on a specific physical server.
NOTE: Siebel strongly recommends that you operate the Siebel Gateway Server
on a cluster for high availability. You may also choose to operate Siebel Remote
or other Siebel Server components on a cluster, depending on your operational
requirements.
The Siebel Gateway Server can coexist with a Siebel Server or can be installed on
another physical machine. The only precondition is that the Gateway Server meet
the hardware, operating system, and other requirements detailed in Siebel
System Requirements and Supported Platforms. There is always only one Siebel
Gateway Server communicating with multiple Siebel Servers.
When planning server names, remember the following:
Under UNIX, Siebel Server names must be 30 characters or less in length and
must not contain spaces or punctuation.
Siebel Server and Enterprise Server names must be unique on the Gateway
Server.
NOTE: If you are installing multiple versions of Siebel eBusiness Applications, each
must be installed in a unique directory. Siebel Systems recommends that, in this
case, you use a naming convention that reflects the components and the version
number being installed.
The Gateway Server must be installed in its own directory; similarly, each Siebel
Server installed on an application server must also be installed in a unique
directory.
NOTE: If you will be installing Resonate Central Dispatch, you must install it in
a directory separate from Siebel entities.
If you will be installing the CORBA Object Manager, consider installing it on a dedicated
application server. The CORBA Object Manager may be installed on an
application server that also supports the Siebel Enterprise Server components,
although for best performance and scalability you should install the CORBA
Object Manager onto a dedicated application server.
Record the directory names you decide on in the copy you made of Appendix A,
“Deployment Planning Worksheet.”
The UNIX Enterprise Server component installers use /siebel as the default for
SIEBEL_ROOT. Unless otherwise specified, all other Enterprise Server entities
subsequently installed on the application server will be installed under this same
SIEBEL_ROOT directory.
You should also locate each SIEBEL_ROOT directory under a common Siebel
directory. For example, you might use /siebel6xx/gtwy/ as the SIEBEL_ROOT
directory for the version 6.x Siebel Gateway Server supporting your production
environment.
Record the SIEBEL_ROOT directory names for your installation in your copy of
Appendix A, “Deployment Planning Worksheet,” under the
Enterprise Server/Siebel root field, and leave the other installation directory
information blank for entities you will install on the same application server.
If you will be installing Resonate Central Dispatch, you must install it in a directory
separate from Siebel entities. Siebel Systems recommends that you install the
Central Dispatch software in a separate directory under a common directory
shared by Siebel entities. For example, you might use the directory
/siebel6xx/resonate6xx for the version of Resonate Central Dispatch shipped
with version 6.x of Siebel Applications.
If you will be installing the CORBA Object Manager, consider installing it on a dedicated
application server. The CORBA Object Manager may be installed on an
application server that also supports the Siebel Enterprise Server components,
although for best performance and scalability you should install the CORBA
Object Manager onto a dedicated application server.
Record the directory names you decide on in the copy you made of Appendix A,
“Deployment Planning Worksheet.”
Verify that the computers you have chosen meet all requirements for running your
Siebel application, as well as the required third-party software, and are able to
support the Siebel File System, the Siebel Gateway Server, the Siebel Server, Siebel
Database Server, and the Siebel Server Manager administrator’s workstation. For
size limitations and information on required third-party software, refer to Siebel
System Requirements and Supported Platforms.
Regardless of the types of Siebel clients that you plan to deploy, you must install at
least one Siebel Dedicated Client for use by the Siebel administrator to run the
Server Manager.
Siebel Service Owner Account. This is the user account on your Siebel Servers
under which all Siebel processes and components operate. The Siebel Service
Owner Account is required whether or not you are using Resonate Central
Dispatch for connection brokering.
Under UNIX, this account should be a regular user account with appropriate
permissions set; the account will also be used to start and stop Siebel processes.
Siebel Monitoring Account. This account is required for the Resonate Central
Dispatch connection brokering server. Therefore, you only need this account if
you install connection brokering.
Under both Windows NT and UNIX, this account must have login privileges on
each application server, but requires no additional privileges.
Both of the accounts mentioned above must exist on each host on which Central
Dispatch has been installed.
If you will be installing the Siebel Enterprise Server under Windows NT, complete
the following steps to create the required Siebel accounts.
Set up the accounts so that the user does not have to change the password at the
next logon. This precaution prevents the user from changing the password. It
also allows you to create a password that never expires.
Do not disable the accounts. They must be enabled to connect to the node where
the accounts were created.
3 Create a Siebel Service Owner account using this user ID and password on the
domain server with the following characteristics:
The account password must not require a change on next logon and must be
set not to expire. Because the Siebel Server components store the password
in encrypted format, any change to the password will require that these
components be reconfigured.
NOTE: Be sure to use the same user ID and password for the service owner
account on each application server.
4 Add this user to the Administrators’ group in each application server that will
run a Siebel Server, on the application server that will run the Gateway Server,
and on the primary and backup Central Dispatch scheduler, if these are separate
machines.
The account must have the advanced user right “Log on as a service” on each
Windows NT application server.
If you will be using Siebel eMail Response, this account must correspond
with the accounts on your corporate email system.
NOTE: To add or verify Windows NT account privileges, from the User Manager
click Policies User Rights.
To add logon as a service privilege to the account
1 From the Windows Start menu, choose Programs Administrative Tools User
Manager.
2 Select the user who requires the service privilege, and then choose
Policies User Rights.
As with the Windows NT Administrator account you created for Siebel Services,
this account password must be set not to change or expire.
If you will be installing the Siebel Enterprise Server under a supported UNIX
version, complete the following steps to create the required Siebel accounts.
Prevent users from being able to actually log on using either the
Administration mode account or the Monitor mode account. You can do this
by not assigning a login shell to that account. (If you do not assign a login
shell to the account, you also do not need to assign a home directory to the
account.)
The account password must not require a change on next logon and must be
set not to expire.
NOTE: Be sure to use the same user ID and password for the Service Owner
account on each application server.
The login name and password for the administration account must be the
same on all the computers in the Central Dispatch site, including the monitor
mode account.
NOTE: The “Central Dispatch site” includes the entire deployment network
controlled by any one Siebel Gateway Server.
Set up the accounts, so that users neither have to change the password at the
next logon, nor can they change it, and so that the password never expires.
Do not disable the accounts. They must be enabled to connect to the node
where the accounts were created.
Create the Service Owner account at the network level, so that the same account
can be used on all UNIX application servers within the Siebel Enterprise.
This account does not require “superuser access”; it should be a normal user
account. Therefore, it should not belong to the same group as the previous
accounts.
NOTE: Never log into Dispatch Manager accounts directly as a user. The accounts
exist on each machine so that Dispatch Manager can validate the password you
enter when connecting to your Central Dispatch site before granting administration
or monitoring privileges.
If your site’s network requires static port assignments for correct configuration,
determine which ports you want to assign to the Synchronization Manager, Request
Manager, and each Application Object Manager component, and note these in
Appendix A, “Deployment Planning Worksheet,” for each Siebel Server in your
deployment.
NOTE: This step is optional; unless your network requires static ports, use dynamic
ports for simplified installation and configuration.
If you use Resonate Central Dispatch, the default port used by the scheduler is 2320.
If you want to reconfigure the scheduler onto another port, you must do so using
Siebel Server Manager after you install Siebel Enterprise Server components.
Ensure that Siebel supports the exact version of your chosen RDBMS, as specified
in Siebel System Requirements and Supported Platforms, and that the RDBMS has
been installed on the machine to be dedicated as the Siebel Database Server. This
server will hold the database tables containing your business data, such as sales
(personnel, territories, opportunities, and activities), marketing, and customer
service information.
Verify that the network names of the servers that will support the Siebel Database
Server and Siebel File System are properly recorded in Appendix A, “Deployment
Planning Worksheet.”
Finally, you will need to determine certain details about your RDBMS configuration.
Siebel will create the ODBC data source name during installation. The name will
be SiebSrvr_enterpriseservername. For example, if your Siebel Enterprise
Server name is the default, Siebel, the ODBC data source name will be
SiebSrvr_Siebel. Using this pattern, determine what your ODBC data source
name will be and fill in the Deployment Planning Worksheet.
Prior to installing the Siebel Database Server, refer to the configuration chapter
specific to your RDBM later in this guide for sizing and configuration
information.
Next Steps 2
Your environment is now ready for installation and configuration of the Siebel
Server entities. If you are installing Central Dispatch, see Chapter 3, “Installing
Central Dispatch Under Windows NT,” or Chapter 4, “Installing Central Dispatch
Under UNIX,” depending on your operating system.
If you are not installing Central Dispatch, see Chapter 5, “Installing the Siebel
Gateway Server Under Windows NT,” or Chapter 6, “Installing the Siebel Gateway
Server Under UNIX.”
This chapter describes installation of the Resonate Central Dispatch server for those
who will implement connection brokering under Windows NT.
Pre-Installation Tasks 3
If you plan to use Siebel’s connection-brokering feature, you must now install the
Resonate Central Dispatch software before proceeding with the installation of the
Siebel Gateway Server and Siebel Enterprise Server. If you choose not to use
connection brokering, page to Chapter 5, “Installing the Siebel Gateway Server
Under Windows NT.”
Caution: If you do not install Central Dispatch now, but later decide
to use connection brokering, you will be required to reinstall all
Siebel Enterprise Server entities after you have installed Central
Dispatch.
Before proceeding, be sure to review the Resonate Central Dispatch User Guide,
provided on the Bookshelf for Siebel eBusiness Applications CD-ROM.
Central Dispatch must be installed on all application servers that will support
Gateway or Siebel Servers.
NOTE: Before proceeding with the installation of Central Dispatch, review the
Resonate Central Dispatch and Resonate Commander Site Preparation Guide,
available in pdf format on the Siebel Bookshelf.
Verifying Accounts 3
Central Dispatch requires two accounts, which you created in “Creating Siebel
Accounts” on page 2-17. Before proceeding with the installation, verify that you
have the proper accounts, as follows:
A Siebel service owner account. This must be a domain account that is a member
of the Administrators group on all Windows NT application servers that will run
the Siebel Gateway Server, Siebel Servers, and Resonate Central Dispatch. It
must also have the “logon as a service” privilege.
A Siebel monitoring account. This account must be a member of the Users’ group
on application servers.
When you install Central Dispatch, connection-brokered Siebel clients are no longer
configured to connect directly to a specific Siebel Server. Instead, they connect to a
virtual IP (VIP), a logical address operated by the Resonate scheduler, which in turn
connects these clients to the most appropriate, and least loaded, Siebel Server
available.
In brokered mode, the Siebel Gateway Server requires a VIP, or logical IP address.
Siebel clients are then configured to connect to this VIP, rather than to Siebel Servers
directly, for access to brokered server components. This so-called Gateway VIP is
owned by the primary scheduler.
Siebel Servers are fully integrated with the Central Dispatch scheduler. The
configuration information that the Gateway Server uses to broker connections is
automatically updated as Siebel Servers are started or stopped or as their
configuration is modified.
The Gateway VIP must be on the same IP subnet as the addresses of all application
servers in the Siebel Enterprise. Select these addresses from the appropriate subnet
and record this information in a photocopy of Appendix A, “Deployment Planning
Worksheet.”
NOTE: Register the VIP with the appropriate name service, such as DNS or NIS, just
as you register any real host’s IP address. However, unlike standard IP addresses,
the VIP denotes the entire Siebel site, not just a particular application server.
List all the hostnames of the servers that make up your site and the resources
and content they provide. Decide which servers to group together based on that
information.
Under UNIX, make sure that the netmasks file or NIS/NIS+ database contains
every network number/network mask pair used in your network.
Make sure that the VIP is unique. Never use an IP address as a VIP if that IP
address is already assigned to a computer.
Make sure that the IP address of the scheduler nodes (primary and backup), the
Siebel Gateway, and Siebel Server nodes are on the same subnet as the VIP. This
means that each primary scheduler, the VIP assigned to it, and the backup
scheduler for that primary are all part of the same subnet. The network ID
portion of the scheduler IP address (as defined by the subnet mask) must be
identical to the network ID portion of the VIP.
If your site can be reached from the Internet, register with the appropriate DNS
server for your site.
If a group of servers is cut off from the rest of the network and visible only to
each other, resolve their names either by modifying the DNS database records or
by modifying the entries in the local host file:
%System Root%\system32\drivers\etc\hosts
You must also assign static IP addresses to each of your application servers. Select
these addresses from the appropriate subnet, and record this information in
Appendix A, “Deployment Planning Worksheet.”
Central Dispatch also requires that static IP addresses be assigned to each of the
machines with which it interacts. These IP addresses must all be on the same
subnet and use the same subnet mask. You will also need to know the default
Gateway address for this subnet.
3 On the IP Address tab of the Microsoft TCP/IP Properties dialog box, make sure
that the correct Adapter (the physical network interface card) is selected.
b Click OK.
5 Click Close to close the Network dialog box.
The driver will be installed, and you will see the TCP/IP Properties dialog box.
Use the ping utility to make sure that all application servers have TCP/IP
connectivity to one another, as well as to the servers that will support the Siebel
Database Server and the Siebel File System.
You also need to make sure that the routes between all application servers are
symmetric. Symmetric routes are routes that, step for step, traverse the same
computers and the same network nodes in exactly the opposite order with respect
to each other.
2 Use the tracert command to display the route from it to one of your application
servers, as follows:
C:\> tracert appserver
where:
3 In the same way, on that application server, open an MS-DOS command prompt,
and use the tracert command to display the route from it back to the machine
that will host the primary Central Dispatch scheduler.
4 Compare the results of each tracert and verify that the routes between these
servers are symmetric.
C:\>tracert windsor
Trace complete.
C:\>tracert demaine
Trace complete.
5 Repeat these steps from your primary Central Dispatch scheduler for each
application server machine you have.
6 From the secondary Central Dispatch scheduler, repeat this process with each
application server.
If you find asymmetric routes between any two servers, you need to adjust your
routing so that the routes are symmetric. You might have to delete static route tables
and redo the routes, or restart the router in order to get a symmetric route.
After you have verified network routes on all application servers, you are ready to
install Central Dispatch.
Installation Tasks 3
You must install Central Dispatch on each computer that will support a Siebel Server
or Siebel Gateway Server, and the Central Dispatch primary scheduler and backup
scheduler. Complete the following steps to install Central Dispatch.
where:
language = the three-letter code for the language of your Siebel eBusiness
Applications product; for example, enu for U.S. English.
2 Double-click setup.exe to start the Resonate installer, and when the Welcome
dialog box appears, click Next.
3 For installation steps specific to the Central Dispatch installer, see the Resonate
Central Dispatch and Resonate Commander Installation Guide, available on the
Siebel Bookshelf in pdf format.
4 Install only the following Resonate components from the Select Component
screen:
Management Tools
CDAction
Dispatch Manager
Post-Installation Tasks 3
After you have completed the installation of Central Dispatch on all application
servers, you need to configure it using the Resonate Dispatch Manager application.
During this configuration step, you will define a Central Dispatch site that includes
the static IP addresses used by the application servers and the Gateway VIP.
You will configure the Central Dispatch site only once, from any application server
within the Enterprise Server. Central Dispatch automatically shares and updates
configuration information across all Central Dispatch nodes in the site.
2 In the Dispatch Manager Welcome dialog box, leave the Connect to Node field
empty and click OK.
NOTE: The Connect to Node field is left blank only the first time that you start
Dispatch Manager. After you have configured the Central Dispatch site, you must
specify the IP address of one of the system nodes or the Gateway VIP to connect
to the site when starting Dispatch Manager.
NOTE: Type the static IP address, not the name of the machine to which it is
assigned, in the Node Name field. The use of hostnames can cause
inconsistencies in routing, depending on the operation of your DNS servers.
5 On the Virtual Hosts tab, add the Gateway VIP to the site:
a In the Virtual Host Name field, type the VIP address.
b In the Primary Scheduler list, select the static IP address of the application
server that will serve as the primary Scheduler node.
6 On the Licensing tab, type the license key in the New Key field.
The license key is stored in the license.txt file in the
\Thirdpty\language\resonate subdirectory of your Siebel Windows Server
CD-ROM.
Do not change the server weight to redistribute the Central Dispatch connection
weight by entering a value in the Server Weight field of Dispatch Manager, as
described in the Resonate Central Dispatch User Guide. Instead, use the Siebel
parameter MaxTasks for an asymmetric distribution of connections. For
information on the use of this parameter, see the Siebel Server Administration
Guide.
You do not need to mark a node that does not need Resonate software installed
as an affiliate node, as described in the Resonate Central Dispatch User Guide.
Siebel software does not support affiliated nodes.
For more information on Central Dispatch scheduling policy, see the Resonate
Central Dispatch User Guide.
When you select Central Dispatch resource-based scheduling, you must also select
a load-balancing policy. (Round-robin scheduling does not require load balancing.)
Select CPU Load and Connections (enhanced) as your load-balancing policy.
For more information on Central Dispatch load-balancing policy, see the Resonate
Central Dispatch User Guide.
After Central Dispatch has been installed and configured, its ongoing configuration
and operation are handled primarily by the Siebel Server software. You can use
Dispatch Manager to monitor the operation of your Central Dispatch server, as
described in the Resonate documentation, but you will not need to change the
configuration manually during normal operations.
The exception to this occurs if you need to add application servers to your
Enterprise Server or to remove them. In this case, follow the procedure below.
a Stop the Siebel Server, the Siebel Gateway, or both (in that order) in that node
before removing the IP address.
b Using Resonate Dispatch Manager, verify that none of the scheduling rules
contain the static IP address, or node, you want to remove. If it does, you
must manually remove the node. To do so, refer to the Resonate Central
Dispatch User Guide under “Changing and Deleting Scheduling Rules.” This
book is available in pdf format on your Siebel eBusiness Applications Server
Installation CD-ROM under Thirdpty\language\Resonate.
2 Remove the static IP addresses assigned to each server from the System Nodes
tab of the Site Setup dialog box in Dispatch Manager, as described in
“Configuring Central Dispatch” on page 3-10.
2 Verify that the correct static IP address is assigned to each server and that no
static IP address is used more than once.
You will need to reinstall Central Dispatch if you change your network or hardware
configuration.
3 Uninstall Central Dispatch. See the Resonate Central Dispatch Installation Guide,
available on the Siebel Bookshelf in pdf format.
5 Reinstall Central Dispatch on the node (or nodes) on which you formerly had it
installed, following the instructions provided earlier in this chapter.
NOTE: Use the same Resonate Administrator password that was used previously.
6 Verify that the installer has installed Resonate in the correct location.
7 Verify that the reconfigured node is part of the Central Dispatch site.
If it is not, refer to “Configuring Central Dispatch” on page 3-10.
9 Reinstall any Siebel components that you had previously uninstalled. (Refer to
the other chapters in the guide for information on their installation.)
This chapter describes installation of the Resonate Central Dispatch server for those
who will implement connection brokering under UNIX.
Pre-Installation Tasks 4
If you plan to use Siebel’s connection-brokering feature, you must now install the
Resonate Central Dispatch software before proceeding with the installation of the
Siebel Gateway Server and Siebel Enterprise Server. If you choose not to use
connection brokering, page to Chapter 6, “Installing the Siebel Gateway
Server Under UNIX.”
Caution: If you do not install Central Dispatch now, but later decide
to use connection brokering, you will be required to reinstall all
Siebel Enterprise Server entities after you have installed Central
Dispatch.
Central Dispatch must be installed on all application servers that will support
Gateway or Siebel Servers.
Dispatch Manager can run on Central Dispatch nodes or on any UNIX Server.
NOTE: Before proceeding with the installation of Central Dispatch, review the
Resonate Central Dispatch and Resonate Commander Site Preparation Guide,
available in pdf format on the Siebel Bookshelf.
Verifying Accounts 4
Central Dispatch requires two accounts, which you created in “Creating Siebel
Accounts Under UNIX” on page 2-21. Before proceeding with the installation, verify
that you have the proper accounts, as follows:
A Siebel Service Owner account. This is the user account on your Siebel Servers
under which all Enterprise Server processes and components operate. This
account should be a regular user account with appropriate permissions set; it
will also be used to start and stop Enterprise Server processes.
A Siebel monitoring account. This account is required for the Resonate Central
Dispatch connection brokering server and is, therefore, needed only on systems
that have connection brokering installed. This account must have login
privileges on each application server, but requires no additional privileges.
Both of the accounts mentioned above must exist on every host where Central
Dispatch is installed. These are standard UNIX-based system user accounts.
When you install Central Dispatch, connection-brokered Siebel clients are no longer
configured to connect directly to a specific Siebel Server. Instead, they connect to a
virtual IP (VIP), a logical address operated by the Resonate scheduler, which
connects these clients to the most appropriate, and least loaded, Siebel Server
available.
In brokered mode, the Siebel Gateway Server requires a VIP, or logical IP address.
Siebel clients are then configured to connect to this VIP, rather than to Siebel Servers
directly, for access to brokered server components. This so-called Gateway VIP is
owned by the primary scheduler.
Siebel Servers are fully integrated with the Central Dispatch scheduler. The
configuration information that the Gateway Server uses to broker connections is
automatically updated as Siebel Servers are started, stopped, or as their
configuration is modified.
The Gateway VIP must be on the same IP subnet as the addresses of all application
servers in the Siebel Enterprise. Select these addresses from the appropriate subnet
and record this information in a photocopy of Appendix A, “Deployment Planning
Worksheet.”
NOTE: Register the VIP with the appropriate name service, such as DNS or NIS, just
as you register any real host’s IP address. However, unlike standard IP addresses,
the VIP denotes the entire Siebel site, not just a particular application server.
List all the hostnames of the servers that make up your site and the resources
and content they provide. Decide which servers to group together based on that
information.
Under UNIX, make sure that the netmasks file or NIS/NIS+ database contains
every network number/network mask pair used in your network.
Make sure that the IP address of the scheduler nodes (primary and backup) are
on the same subnet as the VIP. This means that each primary scheduler, the VIP
assigned to it, and the backup scheduler for that primary are all part of the same
subnet. The network ID portion of the scheduler IP address (as defined by the
subnet mask) must be identical to the network ID portion of the VIP.
If your site is reachable from the Internet, register with the authoritative DNS
server for your site.
If you use NIS or NIS+ inside a firewall, edit the NIS files or update the
database.
If a group of servers is cut off from the rest of the network and visible only to
each other through the /etc/hosts files, edit those files.
Make sure that all the nodes in your Central Dispatch site are registered with the
naming service you are using. For example, if you use /etc/hosts files, each
file must contain entries for all the nodes in the site.
You must also assign static IP addresses to each of your application servers. Select
these addresses from the appropriate subnet, and record this information in
Appendix A, “Deployment Planning Worksheet.”
Central Dispatch also requires that IP addresses be assigned to each of the machines
with which it interacts. These IP addresses must all be on the same subnet and use
the same subnet mask.
2 Double-check to verify that each static IP was assigned to the correct machine
and that no static IP was assigned to more than one computer.
3 Verify the Gateway VIP was not assigned to any network adapter card.
Use the ping utility to ensure that all application servers have TCP/IP connectivity
to one another, as well as to the servers that will support the Siebel Database Server
and the Siebel File System.
You also need to make sure that the routes between all application servers are
symmetric. Symmetric routes are routes that, step for step, traverse the same
computers and the same network nodes in exactly the opposite order with respect
to each other.
2 Use the traceroute command to display the route from that computer to one
of your application servers, as follows:
$ traceroute appserver
where:
3 From that application server, use the traceroute command to display the route
from it back to the machine that will host the primary Central Dispatch
scheduler.
4 Compare the results of each traceroute and verify that the routes between
these servers are symmetric.
$ traceroute windsor
$ traceroute demaine
5 Repeat these steps from your primary Central Dispatch scheduler for each
application server machine you have.
6 From the secondary Central Dispatch scheduler, repeat this process with each
application server.
If you find asymmetric routes between any two servers, you need to adjust your
routing so that the routes are symmetric. You might have to delete static route tables
and redo the routes or restart the router in order to get a symmetric route.
After you have verified network routes on all application servers, you are ready to
install Central Dispatch.
Installation Tasks 4
You must install Central Dispatch on each computer that will support a Siebel Server
or Siebel Gateway Server, and the Central Dispatch primary scheduler and backup
scheduler. Complete the following steps to install Central Dispatch.
NOTE: You must log on as root or superuser to install Central Dispatch; it cannot be
installed from a normal user account.
The Resonate installation script will prompt you to fill in the information it needs
to install Central Dispatch properly on your system.
If you have further questions, see the Resonate Central Dispatch Installation
Guide, available on the Siebel Bookshelf in pdf format.
5 Install only the following Resonate components when prompted by the Resonate
installation script:
Management Tools
CDAction
Dispatch Manager
NOTE: Do not try to enable Resonate’s “shadow scheduling” option; Siebel does
not use Central Dispatch’s persistent sessions feature.
Post-Installation Tasks 4
Do not proceed with this section until you have installed Central Dispatch on all
application servers in your deployment, using the instructions in “Installation
Tasks” on page 4-9.
After you have completed the installation of Central Dispatch on all application
servers, you need to configure it using the Resonate Dispatch Manager application.
During this configuration step, you will define a Central Dispatch site that includes
the static IP addresses used by the application servers and the Gateway VIP.
You will configure the Central Dispatch site only once, from any one Siebel Server
within the Enterprise Server. Central Dispatch automatically shares and updates
configuration information across all Central Dispatch nodes in the site.
The Dispatch Manager application is the same on the Windows NT and UNIX
platforms; this one set of instructions applies regardless of the platform on which
you are running Dispatch Manager.
2 In the Dispatch Manager Welcome dialog box, leave the Connect to Node field
empty and click OK.
NOTE: The Connect to Node field is left blank only the first time that you start
Dispatch Manager. After you have configured the Central Dispatch site, you must
specify the IP address of one of the system nodes or one of the VIPs in order to
connect to the site when starting Dispatch Manager.
NOTE: Enter the static IP address, not the name of the machine to which it is
assigned, in the Node Name field. The use of hostnames can cause
inconsistencies in routing, depending on the operation of your DNS servers.
5 On the Virtual Hosts tab, add the Gateway VIP to the site:
a In the Virtual Host Name field, enter the VIP address.
b From the Primary Scheduler list, select the static IP address of the application
server that will serve as the primary Scheduler node.
Do not change the server weight to redistribute the Central Dispatch connection
weight by entering a value in the Server Weight field of Dispatch Manager, as
described in the Resonate Central Dispatch User Guide. Instead, use the Siebel
parameter MaxTasks for an asymmetric distribution of connections. For
information on the use of this parameter, see the Siebel Server Administration
Guide.
You do not need to mark a node that does not need Resonate software installed
as an affiliate node, as described in the Resonate Central Dispatch User Guide.
Siebel software does not support affiliated nodes.
All Siebel components that can take advantage of load balancing are enabled by
default to make use of connection brokering.
If, for any reason, you need to disable connection brokering on a particular
component, follow the instructions below after you complete installation of the
Siebel Enterprise Server and Siebel Server. To do this, set the Load Balanced
parameter for the component to FALSE.
2 In the Server Components list, select the component you want to modify.
3 In the Component Parameters list, choose Load Balancing and change its value
to FALSE.
4 To save your changes, step off the row by selecting a different record. This will
force the server to implement your changes.
For more information on Central Dispatch scheduling policy, see the Resonate
Central Dispatch User Guide.
When you select Central Dispatch resource-based scheduling, you must also select
a load-balancing policy. (Round-robin scheduling does not require load balancing.)
Select CPU Load and Connections (enhanced) as your load-balancing policy.
For more information on Central Dispatch load-balancing policy, see the Resonate
Central Dispatch User Guide.
After Central Dispatch has been installed and configured, its ongoing configuration
and operation are handled primarily by the Siebel Server software. You can use
Dispatch Manager to monitor the operation of your Central Dispatch server, as
described in the Resonate documentation, but you will not need to change the
configuration manually during normal operations.
The exception to this occurs if you need to add application servers to your
Enterprise Server or to remove them. In this case, follow the procedure below.
a Stop the Siebel Server, the Siebel Gateway, or both (in that order) in that node
before removing the IP address.
b Using Resonate Dispatch Manager, verify that none of the scheduling rules
contain the static IP address, or node, you want to remove. If it does, you
must manually remove the node. To do so, refer to the Resonate Central
Dispatch User Guide under “Changing and Deleting Scheduling Rules.” This
book is available in pdf format on your Siebel eBusiness Applications Server
Installation CD-ROM under Thirdpty\language\Resonate.
2 Remove the static IP addresses assigned to each server from the System Nodes
tab of the Site Setup dialog box in Dispatch Manager, as described in
“Configuring Central Dispatch” on page 4-10.
2 Verify that the correct static IP address is assigned to each server and that no
static IP address is used more than once.
You will need to reinstall Central Dispatch if you change your network or hardware
configuration.
3 Uninstall Central Dispatch. See the Resonate Central Dispatch Installation Guide,
available on the Siebel Bookshelf in pdf format.
5 Reinstall Central Dispatch on the node (or nodes) on which you formerly had it
installed, following the instructions provided earlier in this chapter.
NOTE: Use the same Resonate Administrator password that was used previously.
6 Verify that the installer has installed Resonate in the correct location.
7 Verify that the reconfigured node is part of the Central Dispatch site.
If it is not, refer to “Configuring Central Dispatch” on page 4-10.
9 Reinstall any Siebel components that you had previously uninstalled. (Refer to
the other chapters in the guide for information on their installation.)
This chapter explains how to set up a Siebel File System and install the Siebel
Gateway Server on the Windows NT server platform.
You must create a separate File System for each Siebel database tableowner. For
example, if you have development and test databases, you must have two separate
File Systems. When you configure the Siebel client to point to these different
databases, be certain that it points to the correct File System for each database.
This chapter assumes you are familiar with the Siebel File System and Siebel
Gateway Server and their functions. See Chapter 1, “Overview,” for introductory
information if you are unfamiliar with these components and their functions within
the Siebel product.
NOTE: Siebel Systems does not support running different versions of Siebel
eBusiness Applications concurrently through the same Gateway Server.
Pre-Installation Tasks 5
Perform the following tasks before running the Gateway Server installation
program:
The Gateway Server maintains the configuration information for all Siebel Servers
in all the Enterprise Servers it manages. Loss of the Gateway Server due to a disk
crash could bring your Siebel software to a halt while the system is restored.
Similarly, the Siebel Server temporarily stores transaction files synchronized to and
from Siebel Remote mobile users. The loss of these files will result in the need to
re-extract the database for all affected mobile users.
Siebel Systems strongly recommends that you install a redundant disk array (RAID)
or some other type of redundant disk configuration on your Siebel Gateway Server
and on those Siebel Servers that will support the Siebel Remote product. (Siebel
Remote supports synchronization of data between Siebel Mobile Clients and the
Siebel Database Server through a dial-up connection.) A redundant disk
configuration substantially reduces the risk of data loss and minimizes the difficulty
of error recovery for both types of server. Refer to your hardware vendor’s
documentation and your operating system documentation for instructions on how
to install and configure a redundant disk array.
Verify that the network names of the servers that will support the Siebel Gateway
Server and all Siebel Servers are recorded in Appendix A, “Deployment Planning
Worksheet.” You will require this information later when installing the Siebel
Servers and Siebel clients.
You must create a separate File System for each Siebel database tableowner, also
known as the database owner. For example, if you have development and test
databases, you must have two separate File Systems. When you configure a Siebel
Dedicated Client to point to one of these databases, you must also configure it to
point to the correct File System for the database it uses.
NOTE: You must install and start only one Gateway Server for each Siebel Enterprise
Server and Database Server that you are implementing.
You can name this directory anything you like, except that the name must contain
neither special characters nor spaces. Siebel Systems recommends that you use an
UNC (Universal Naming Convention) sharename.
\\SiebelFS\siebel6xx
where:
SiebelFS is the host name of the machine (assuming that a dedicated machine is
used for the Siebel File System)
and
You will need to specify the UNC sharename when installing the Siebel Server and
Siebel Dedicated Clients.
NOTE: When installing a new file system, do not change the default setting for
Maximum Allowed.
5 To grant UNC access to every Siebel Server and Client, click Permissions and
choose the appropriate group name.
You must be certain that you will not use connection brokering before you proceed
with the Gateway Server installation without Central Dispatch installed. If Central
Dispatch is not installed prior to installing the Gateway Server and you later elect
to use connection brokering, you will have to remove and reinstall the Gateway
Server and all Siebel Servers after installing Central Dispatch.
Verify that the application server computer that will host the Gateway Server meets
hardware and operating system requirements for your chosen platform, as detailed
in Siebel System Requirements and Supported Platforms. If the application server
will also support a Siebel Server, it must also have all the required third-party
products installed, as listed in Siebel System Requirements and Supported Platforms.
Each application server that will support a Siebel Server must have TCP/IP network
connectivity to the machine on which the Gateway Server will be installed. Verify
network connectivity between all application servers, using the ping utility.
If you are using connection brokering, make sure that Resonate Central Dispatch is
installed on the application server that will support the Gateway Server, as well as
on all application servers that will support Siebel Servers.
Installation Tasks 5
This section provides instructions for installing and starting the Gateway Server on
the Windows NT platform.
Caution: Install the Gateway Server only once for each Siebel
installation using a common database owner. Only one Gateway
Server may be installed on a physical application server.
3 Read the Welcome screen and click Next to continue with the setup program.
If you do not yet have Resonate Central Dispatch installed, the installer prompts
you as to whether you would like to continue installation without it.
NOTE: Siebel Systems strongly recommends that you install Resonate Central
Dispatch to take advantage of the higher availability and scalability its
connection brokering features offer enterprise deployments.
4 Indicate whether or not you want to continue with the installation without
Resonate Central Dispatch being installed:
c Click Next.
The Gateway Server NT Account Information screen appears.
6 Accept the default NT Account Administrator name and domain account or type
new ones, based on the information you recorded in Appendix A, “Deployment
Planning Worksheet,” using the format DOMAIN\username.
7 On the Gateway Server NT Services screen, click the Start Automatically check
box if you want the Gateway Server NT service to start automatically whenever
the Windows NT operating system starts up. To continue, click Next.
8 Use the Back button to review the settings you have selected. Click Next when
you are satisfied.
When all required files have been installed, the Event Log screen appears.
9 Review the installation information to make sure everything is right, and click
Next to begin installing.
When the Gateway Server installation has completed installing and configuring
files, the Setup Complete screen appears.
NOTE: As of version 6.0, the Siebel Gateway Server no longer appears in your
Windows NT Start menu under Programs.
The installer prompts you about whether or not you want to restart your
machine now or later.
11 Restart your machine before attempting to start the Siebel Gateway Server.
12 After restarting your machine, start the Siebel Gateway Server by navigating to
the Windows NT Start menu and choosing Settings Control Panel Services.
Select the Siebel Gateway Server and click Start.
This chapter describes how to set up a Siebel File System and install the Siebel
Gateway Server on a supported UNIX platform.
You must create a separate File System for each Siebel database tableowner. For
example, if you have development and test databases, you must have two separate
File Systems. When you configure the Siebel client to point to these different
databases, be certain that it points to the correct File System for each database.
This chapter assumes you are familiar with the Siebel File System and Gateway
Server and their functions. See Chapter 1, “Overview,” for introductory information
if you are not.
Siebel Systems does not support running different versions of Siebel concurrently
through the same Gateway Server. You must install and start one, and only one,
Gateway Server for each Siebel Enterprise Server and Database Server that you are
implementing.
NOTE: Siebel Systems does not support running different versions of Siebel
concurrently through the same Gateway Server.
Pre-Installation Tasks 6
Perform the following tasks before running the Gateway Server installation
program:
The Gateway Server maintains the configuration information for all Siebel Servers
in all the Enterprise Servers it manages. Loss of the Gateway Server due to a disk
crash could bring your Siebel software to a halt while the system is restored.
Similarly, the Siebel Server temporarily stores transaction files synchronized to and
from Siebel Remote mobile users. The loss of these files will result in the need to
re-extract the database for all affected mobile users.
Siebel strongly recommends that you install a redundant disk array (RAID) or some
other type of redundant disk configuration on your Siebel Gateway Server and on
those Siebel Servers that will support the Siebel Remote product. (Siebel Remote
supports synchronization of data between Siebel Mobile Clients and the Siebel
Database Server through a dial-up connection.) A redundant disk configuration
substantially reduces the risk of data loss and minimizes the difficulty of error
recovery for both types of server. Refer to your hardware vendor’s documentation
and your operating system documentation for instructions on how to install and
configure a redundant disk array.
Verify that the network names of the servers that will support the Siebel Gateway
Server and all Siebel Servers are recorded in Appendix A, “Deployment Planning
Worksheet.” You will require this information later when installing the Siebel
Servers and Siebel clients.
You must create a separate File System for each Siebel database tableowner. For
example, if you have development and test databases, you must have two separate
File Systems. When you configure the Siebel client to point to these different
databases, be certain that it points to the correct File System for each database.
Although you are installing the Siebel Enterprise Server on UNIX, the Siebel
Dedicated Client and Siebel Tools workstations will run under Windows 95,
Windows 98, or Windows NT, and must be able to access the file system, so it must
use Windows NT-compatible file names.
You can name this directory anything you like. However, the name must contain
neither special characters nor spaces. Siebel Systems recommends that you use an
UNC (Universal Naming Convention) sharename.
\\SiebelFS\siebel6xx
where:
SiebelFS is the host name of the machine (assuming that a dedicated machine is
used for the Siebel File System)
and
You will need to specify the UNC sharename when installing the Siebel Server and
Siebel Dedicated Clients.
For more information on installing Siebel Dedicated Clients, see Siebel Client
Installation and Administration Guide.
2 Use the appropriate administrative tools for your UNIX platform to set the
appropriate individual and group access parameters for the directories.
Before proceeding with the Gateway Server installation without installing Central
Dispatch, you must be certain that you will not use connection brokering. If Central
Dispatch is not installed prior to installing the Gateway Server and you later elect
to use connection brokering, you will have to remove and reinstall the Gateway
Server and all Siebel Servers after installing Central Dispatch.
Verify that the application server computer that will host the Gateway Server meets
hardware and operating system requirements for your chosen platform, as detailed
in Siebel System Requirements and Supported Platforms. If the application server
will also support a Siebel Server, it must also have all the required third-party
products listed in Siebel System Requirements and Supported Platforms installed.
Each application server that will support a Siebel Server must have TCP/IP network
connectivity to the machine on which the Gateway Server will be installed. Verify
network connectivity between all application servers using the ping utility.
If you are using connection brokering, make sure that Central Dispatch is installed
on the application server that will support the Gateway Server, as well as on all
application servers that will support Siebel Servers.
Installation Tasks 6
This section provides instructions for installing and starting the Gateway Server on
supported UNIX platforms. The installation procedure is complex, especially if you
are using Resonate Central Dispatch, so follow it carefully.
Caution: The Gateway Server must be installed only once for each
Siebel installation that uses a common database and tableowner.
Only one Gateway Server can be installed on a physical application
server.
2 Log onto the server using the Siebel service owner account, and enter ksh to run
a Korn shell. Mount the CD-ROM, if required, to make it accessible.
The user ID and password should have been recorded in the copy you made
earlier of Appendix A, “Deployment Planning Worksheet.”
where:
NOTE: The volume label for the CD-ROM is seaunix6xx; it may not be required,
depending on how you access the CD-ROM.
5 To start the Gateway Server installation script, use either of the following
commands:
The installation script has now been started. To complete the installation, you must
understand how to respond to the different types of prompts you will observe in the
installation script.
The first prompt type. This type of prompt asks you to type the desired value for
a given parameter; the default value is shown in square brackets [ ].
Please specify the directory into which Siebel should be
installed [/siebel]
To change the default value, type the desired value, and then press ENTER.
The second prompt type. This type of prompt displays a list of one or more
parameter values and asks you whether you want to modify any of them:
You will see a series of prompts that allow you to change the value. For
example,
The third prompt type. This type of prompt provides a numbered list of options;
the default choice is shown in square brackets [ ].
If the specified directory does not already exist, you will be prompted to confirm
that it should be created.
2 At the next prompt, indicate whether Resonate Central Dispatch has been
installed on this application server.
If it has, enter Y.
If you indicated that Resonate Central Dispatch was installed, the installation
script will prompt you for the Resonate installation directory. If you did not
install Resonate Central Dispatch, proceed to Step 6 on page 6-10.
3 Fill in the value you recorded for the Gateway VIP in the copy you made of
Appendix A, “Deployment Planning Worksheet.”
The installation script prompts you for the Siebel service owner account
password.
The installation script next prompts you for the Gateway Server VIP.
5 Enter the Gateway Server VIP recorded in the copy you made of Appendix A,
“Deployment Planning Worksheet.”
The script prompts you to accept the default software packages you want to
install.
If you enter N, you need to indicate that you accept (Y) or reject (N) each
package on the list; each package will be presented to you for your response.
The Siebel Gateway Server installation script then copies all the required files to
the application server, displaying a series of messages to indicate its progress.
The installation script prompts you to configure the Gateway Server for
automatic startup.
7 If you would like to configure the Gateway Server to start automatically, enter Y,
and then Y again to enable autostart.
NOTE: This setting only enables the Gateway Server to accept additional
configuration instructions to start automatically each time the host machine
restarts. For automatic startup to actually execute, you must complete the
configuration steps described in “Configuring the Gateway Server for Automatic
Start” on page 6-12 after the Gateway Server installation is complete.
The installation script displays the message that the appropriate shell scripts
were created in your root directory, which enables setup of the environment
variables needed by Siebel eBusiness Applications. The installation script then
displays the message that Gateway Server installation is complete.
Post-Installation Tasks 6
Perform the following tasks after running the Gateway Server installation program:
The Gateway Server installation will automatically start the Gateway Server. The
Gateway Server must be started and available for you to continue with the Siebel
installation process. Complete the following steps to verify that the Gateway Server
has been properly installed and started.
NOTE: Be sure there is a space between the first period and ./siebenv.sh.
This sets the Siebel environment variables and path information required to use
Siebel utilities.
NOTE: You may wish to set the Siebel environment script to be automatically
executed when a Siebel administrator logs on. To do this, specify the Korn shell
as the default shell for administrator accounts and add this command to the
startup file for the administrator’s account.
If, during installation, you elected automatic restart of the Gateway Server every
time your system starts, follow the procedure below to implement this under UNIX.
to:
/etc/init.d/siebel_server
ln /etc/init.d/siebel_server /etc/rc3.d/S72siebel
to:
/etc/init.d/siebel_server
ln /etc/init.d/siebel_server /etc/rc0.d/K32siebel
NOTE: You must use the actual path for SIEBEL_ROOT when copying the file and
creating the links.
You have now enabled the Siebel Gateway Server to start automatically when you
restart your system, and to stop automatically when you shut down.
NOTE: Remember that the host where the Siebel Gateway Server is installed must be
the first to start up and the last to be shut down.
You are now ready to proceed with the Siebel Server installation.
This chapter describes the tasks involved in installing the Siebel Server software on
a Windows NT server and configuring the Enterprise Server for this platform.
Pre-Installation Tasks 7
Perform the following tasks before running the Siebel Server installation programs:
Be sure that all application servers onto which the Siebel Server will be installed
meet the hardware and software requirements detailed in Siebel System
Requirements and Supported Platforms.
The Siebel Server installation process must be completed on each application server
that will operate a Siebel Server.
Every Siebel Server that supports a given Database Server must belong to the same
Enterprise Server. When you install the first Siebel Server within an Enterprise
Server, you will be prompted to configure the Enterprise Server. Additional Siebel
Servers installed into that Enterprise Server automatically inherit the Enterprise
Server parameters.
The Windows NT Server installation process must be run once for each Siebel
Server. The Enterprise Server, if it does not already exist, and the Siebel Servers are
configured automatically during this installation process.
Microsoft SQL Server. No configuration is required after the Microsoft SQL Server
ODBC driver specified in Siebel System Requirements and Supported Platforms has
been installed on each application server. Siebel automatically creates an ODBC
data source using connectivity parameters that you will specify during installation
of the Siebel Server.
Oracle. Verify that the Oracle SQL*Net database connectivity software is installed on
each application server, according to the Oracle documentation. See Siebel System
Requirements and Supported Platforms for database connectivity software
requirements.
Prior to installing the Siebel Server and Siebel Enterprise Server, you must use the
Oracle SQL*Net Easy Configuration utility to define a database alias with the proper
connection information for your Siebel Database Server, if you have not already
done so. Record the connect string in Appendix A, “Deployment Planning
Worksheet.” You will specify this connect string when installing the Siebel Server.
DB2 UDB. Define a database alias with the proper connection information for your
database. This alias will be the connect string used when installing the Siebel
Server. Record the connect string in Appendix A, “Deployment Planning
Worksheet.” You will specify this connect string when installing the Siebel Server.
Use either the DB2 Client Configuration Assistant or the Command Line Processor
to define your database alias. For more information, see the IBM DB2 Universal
Database Quick Beginnings manual for NT or the IBM DB2 Universal Database
Command Reference.
DB2 UDB for OS/390. To install the Siebel database server on DB2 UDB for
OS/390, you must execute scripts for this purpose on a client application server and
transfer the sql file output to the mainframe. To accomplish this, you may use one
of the two following methods from your Siebel installation at mid-tier to transfer the
files to DB2 UDB for OS/390:
Install DB2 Connect and configure ODBC to transfer files to the mainframe, and
use an ODBC utility, such as odbcsql.exe, or a version control tool for file
execution.
Install TCP/IP and use ftp to transfer files to the mainframe. Use an IBM utility
such as SPUFI for file execution.
DB2 Connect. Two configuration methods exist for using DB2 Connect to connect
to DB2 UDB for OS/390 from the mid-tier. The configuration method you choose
will depend on whether you are connecting from an application server or from
a Siebel dedicated client.
A Siebel dedicated client can use either the DB2 Connect Personal or Enterprise
Edition, while the application server will always use the DB2 Connect Personal
Edition.
You can use a two-tiered connection by installing DB2 Connect Personal Edition
on the DB2 client machine to connect directly to the mainframe host.
For high-volume network traffic, you can, instead, use a three-tiered connection
by installing DB2 Connect Enterprise Edition on a gateway and DB2 runtime
clients on the Siebel clients. For more information about DB2 Connect, refer to
the “DB2 Connect: Planning and Installation” chapter in IBM’s Quick Beginnings
for DB2 Connect.
If you have previously installed a runtime client, the DB2 Connect installer
upgrade adds only that functionality required for the existing client. (This is also
the case if you have a DB2 server or SDK installed on your workstation.)
3 Catalog your DB2 UDB for OS/390 databases, using the DB2 Command Line
Processor or the Client Configuration Assistant.
You can also add DB2 Connect to an existing server with DB2 already installed.
If you have previously installed a runtime client, the DB2 Connect installer
upgrade adds only that functionality required for the existing client. (This is also
the case if you have a DB2 server or SDK installed on your workstation.)
3 Catalog your DB2 UDB for OS/390 databases on the gateway machine, if desired,
using the DB2 Command Line Processor or the Client Configuration Assistant.
(After installation, you can use your standard DB2 UDB client to access the
gateway.)
NOTE: This gateway can coexist in the same instance as a DB2 UDB server.
4 On the client, catalog the DB2 UDB for OS/390 database you cataloged in Step 3,
using either the DB2 Command Line Processor or the Client Configuration
Assistant, against the gateway machine.
Defining a database alias. Define a database alias with the proper connection
information for your database. This alias will be the connect string used when
installing the Siebel Server. Record the connect string in the copy you made of
Appendix A, “Deployment Planning Worksheet.” You will specify this connect
string when installing the Siebel Server.
Use either the DB2 Client Configuration Assistant or the Command Line
Processor to define your database alias. For more information, see the DB2
Universal Database for OS/390 Administration Guide.
Enabling ODBC. If you are connecting to the mainframe, using DB2 Connect, you
must enable ODBC to point to DB2 UDB for OS/390.
TCP/IP and ftp. For instructions on installing TCP/IP, refer to IBM’s DB2 for
OS/390 Installation Guide.
You must verify that your servers are properly connected to the network and,
through the network, to each other.
To verify network connectivity between Siebel Servers and the Gateway Server,
Database Server, and File System
1 Verify network connectivity to the Gateway and Database Servers from the
application servers, using the test utility for your network type. For TCP/IP
networks, use the ping utility to verify network connectivity to the Database
and Gateway Servers.
Oracle. Use the tnsping utility and SQL*Net database alias from a Command
Prompt window to make sure that you can connect to the database, using the
network connect string that you defined in the previous step.
DB2 UDB for UNIX, Windows NT, and OS/390. Use a DB2 Command Window to
ensure that you can connect to your database.
where:
If your connection is valid, you should see a message that looks like the
following:
NOTE: You can also use the DB2 Command Center GUI tool to do this.
The Siebel Server installation will create its own ODBC data source.
3 The Siebel Server must also have a network connection to the File System. Use
one of the following methods to configure network connectivity:
A drive letter (for example, K:\) on the application server that is mapped to
the Siebel File System directory.
Regardless of the method used to connect to the File System, verify that the File
System directory is visible and that the Siebel service owner account can copy
files to and from it.
Network connectivity to the Gateway Server, Database Server, and File System
is now verified.
If you will be using connection brokering, make sure that Central Dispatch has been
installed and configured on each application server that will support a Siebel Server.
You will be unable to complete the Siebel Server installation if the Gateway Server
is not running. Make sure that the Gateway Server has been started by checking the
Services dialog box, reached through the Windows NT Control Panel.
Run the Siebel Server installation program for each Siebel Server that will be
installed on a Windows NT application server.
NOTE: The term Enterprise Server is used by Siebel to refer to a group of Siebel
Servers that can be administered and configured as a unit rather than individually.
It does not refer to a separate computer or separate program.
Therefore, when you install the first Siebel Server in your deployment, you
automatically configure the Siebel Enterprise Server. All subsequent Siebel Servers
installed that connect to the same database must be installed under this Enterprise
Server.
5 Read the Welcome screen and click Next to continue with the setup program.
If you do not yet have Resonate Central Dispatch installed, the installer prompts
you as to whether you would like to continue installation without it.
NOTE: Siebel Systems strongly recommends that you install Resonate Central
Dispatch to take advantage of the higher availability and scalability its
connection-brokering features offer enterprise deployments.
6 Indicate whether or not you want to install Resonate’s Central Dispatch at this
time:
7 The installer prompts you to verify that the Siebel Gateway Server is running.
The Siebel Gateway Server must be running to continue with the Siebel Server
installation.
If it is not, start it, return to this prompt, and click Next to continue.
8 Choose the type of Siebel Server installation to execute from the following
options, and then click Next to continue:
Typical. This setup option will install all Siebel Server components except
those for Siebel Marketing and the configuration files for Siebel Data Quality.
See the Siebel Marketing Guide for more information on Siebel Marketing
components.
Compact. This setup option will install a minimal subset of only those
components necessary to run the Siebel Server, but no additional
components or help.
Custom. This setup option lets you customize your installation by choosing
the specific components you want to install.
NOTE: If you want to install Siebel Marketing, you must first choose Custom
Setup and then choose it from the list of options.
If you specified the location of an existing Siebel Server installation, the installer
prompts you to remove the previous installation.
9 To remove the previous installation, from the Windows Start menu, select
Settings Control Panel Add/Remove Programs.
10 On the Gateway Server Address screen, type the host name or the static IP
address of the application server on which the Gateway Server was installed and
is running.
If this is a new Enterprise Server, Setup prompts you that the specified Enterprise
Server was not found.
NOTE: If you receive an error message that the Gateway Server could not be
found, it has probably not been started. Start the Gateway Server from the
Windows Services dialog box, by navigating to Start Settings
Control Panel Services. Then, continue with installation.
14 Choose the database server you will be using, and then click Next.
The Database Identification screen appears.
Database Alias. Type the SQL*Net connect string for your Siebel database
server.
Tableowner. Type the name of the database account that owns the Siebel
tables.
Microsoft SQL Server:
Server Name. Type the network name or IP address of the database server
on which you are installing the Siebel database.
Database Name. Type the name of the SQL Server database where the
Siebel tables and indexes will reside.
DB2 UDB:
Database Alias. Type the database alias cataloged for your DB2 database.
Tableowner. Type the name of the database account that owns your Siebel
tables and indexes.
DB2 UDB for OS/390:
Database Alias. Type the database alias cataloged for your DB2 UDB for OS/
390 database.
Tableowner. Type the name of the database account that owns your Siebel
tables and indexes.
SQL ID. Type the SQL ID that defines your RACF (or other security control
product) group. This grants ordinary user privileges for most users. The
default is SSEROLE.
16 In the Server Database Account Information screen, type the administrator name
and password for the Siebel database account.
The default administrator name is SADMIN. If you want to change this, you must
create a new Siebel database account, using the grantusr.sql script, as
described in Part 3, “Configuring and Installing the Siebel Database Server.”
The information gathered from this screen is used to verify version numbers and
to start Siebel Server components automatically.
17 Specify a unique name and description for the Siebel Server you are installing.
This name must not contain special characters or spaces and must be unique
within the Siebel Enterprise Server.
18 Specify whether you want service to start automatically. You may do one of two
things:
20 Indicate whether you have bought Siebel eBriefings alone, Siebel eBriefings
together with Siebel eContent Services, or neither.
If you purchased a license for these options, the License Agreement screen
appears.
If you did not, after selecting “Neither,” continue to Step 24 on page 7-15.
If you selected both eBriefings and eContent Services, the eBriefings Content
Host Username and Password screen appears.
23 Type the user name and password for the Siebel eBriefings content hosts. A user
name and password are issued to your company by Siebel Systems with your
purchase of Siebel eBriefings.
24 If you are deploying the Java Thin Client, type the URL of the Java Thin Client
Online Help that your client will access.
This should be accessible to all Java Thin Client machines, for example:
http://www.siebel.com/JavaClient/help/start.html
If you do not have Java Thin Client installed on your system, leave this blank.
26 On the Start Copying Files screen, review the settings you previously selected
from the list.
When you are satisfied with the settings, click Next to continue. Installation
starts.
The Setup Status screen appears, showing you the progress of installation.
When the installer finishes installing the required files, the Event Log appears.
27 Review the results of the installation in the Event Log screen, and then click
Next.
NOTE: As of version 6.0, the Siebel Enterprise Server no longer appears in your
Windows NT Start menu under Programs.
Proceed to “Starting the Siebel Server NT Service” on page 7-17 to verify successful
installation of the Siebel Server.
After you have completed the installation of the Siebel Server, you must start the
Siebel Server NT service.
where:
siebel server = the name of the Siebel Server you have just installed.
Caution: If the Siebel Server NT service does not start, look in the NT
System, Application Event, and installation logs for error messages.
The installation log is called SVRsetup.log and is located in the
Siebel Server root directory.
To administer the Enterprise Server and all its Siebel Servers, you must install the
Server Manager administrator’s client software on the client PCs used by your Siebel
administrator. See the Siebel Client Installation and Administration Guide for
instructions on installing the Siebel Dedicated Client with the Server Manager
option.
Post-Installation Tasks 7
Perform the following tasks after running the Siebel Server installation program:
The Siebel Server installation program automatically creates an ODBC system data
source name (DSN) that it uses to connect to the Siebel Database Server.
You will need this information when you are installing the Siebel Database
Server.
NOTE: Siebel Systems does not recommend changing the default settings created
automatically with the ODBC data source.
Siebel Mobile Client users must be able to connect to the Siebel Remote Server,
using TCP/IP to synchronize with the master database. Make sure that you have the
correct network software and hardware installed to support this connectivity, and
that your remote users are able to establish a TCP/IP connection to the server using
the ping utility.
Before you can operate Siebel component groups, you must enable them. Please
refer to the chapter “Using the Server Manager UI” under Component Group and
Server Component Administration in the Siebel Server Administration Guide for
instructions.
You are now ready to proceed with the installation of the Siebel Database Server.
If a Siebel Enterprise Server component does not start and you receive a Central
Dispatch command timeout error in the log file for that component, you can
increase your Central Dispatch timeout value, using the Siebel parameter
SCBtimeout.
where:
Siebel Server name = the alias of the Siebel Server in which the components
failed to start
If the default value has never been changed, the command will fail with the
following error:
where:
new value= the new timeout value that you want to apply in seconds, for
example, 360.
If, after trying this procedure, the component still does not start, contact Siebel
Technical Support.
This chapter explains how to install the Siebel Server software on supported UNIX
platforms and how to configure the Enterprise Server.
The Siebel Server installation process must be completed on each UNIX application
server that will operate a Siebel Server. “Planning Your Siebel Deployment” on
page 2-5 provides guidance on determining the number and configuration of Siebel
Servers.
Every Siebel Server that supports a given Database Server must belong to the same
Enterprise Server, regardless of the platform on which the Siebel Servers are
operating. When you install the first Siebel Server within an Enterprise Server, you
will be automatically prompted to configure the Enterprise Server. Additional Siebel
Servers installed in that Enterprise Server automatically inherit its parameters.
On UNIX platforms, the Siebel Server software is installed only once on each
application server. As many Siebel Servers as desired are then configured to operate
from that single software installation. The Siebel Server and Enterprise Server can
be configured independently of software installation on UNIX platforms.
Pre-Installation Tasks 8
Perform the following tasks before running the Siebel Server installation programs:
Be sure that all application servers onto which the Siebel Server will be installed
meet the hardware and software requirements detailed in the Siebel System
Requirements and Supported Platforms.
The Siebel Server installation process must be completed on each application server
that will operate a Siebel Server.
Every Siebel Server that supports a given Database Server must belong to the same
Enterprise Server.
Oracle. Verify that the Oracle SQL*Net database connectivity software is installed on
each application server, according to the Oracle documentation. See the Siebel
System Requirements and Supported Platforms for database connectivity software
requirements.
Prior to installing the Siebel Server and the Siebel Enterprise Server, you must use
the Oracle SQL*Net Easy Configuration utility to define a database alias with the
proper connection information for your Siebel Database Server, if you have not done
so already. Record the connect string in the copy you have made of Appendix A,
“Deployment Planning Worksheet.” You will specify this connect string when
installing the Siebel Server.
DB2 UDB. Define a database alias with the proper connection information for your
database. This alias will be the connect string used when installing the Siebel
Server. Record the connect string the Appendix A, “Deployment Planning
Worksheet.” You will specify this connect string when installing the Siebel Server.
Use the DB2 Command Line Processor (CLP) to define your database alias. For more
information, see the IBM DB2 Universal Database Command Reference.
DB2 UDB for OS/390. To install the Siebel database server on DB2 UDB for
OS/390, you must execute scripts for this purpose on a client application server and
transfer the sql file output to the mainframe. To accomplish this, you may use one
of the two following methods from your Siebel installation at mid-tier to transfer the
files to DB2 UDB for OS/390:
Install DB2 Connect and configure ODBC to transfer files to the mainframe, and
use an ODBC utility, such as odbcsql.exe, or a version control tool for file
execution.
Install TCP/IP and use ftp to transfer files to the mainframe, and use an IBM
utility such as SPUFI for file execution.
Installing DB2 Connect. Two configuration methods exist for using DB2 Connect
to connect to DB2 UDB for OS/390 from the mid-tier. The configuration method
you choose will depend on whether you are connecting from an application
server or from a Siebel dedicated client.
A Siebel dedicated client can use either the DB2 Connect Personal or Enterprise
Edition, while the application server will always use the DB2 Connect Personal
Edition.
You can use a two-tiered connection by installing DB2 Connect Personal Edition
on the DB2 client machine to connect directly to the mainframe host.
Alternatively, you can use a three-tiered connection by installing DB2 Connect
Enterprise Edition on a gateway for high-volume network traffic.
If you have previously installed a runtime client, the DB2 Connect installer
upgrade adds only that functionality required for the existing client. (This is also
the case if you have a DB2 server or SDK installed on your workstation.)
3 Catalog your DB2 UDB for OS/390 databases, using the DB2 Command Line
Processor.
You can also add DB2 Connect to an existing server with DB2 already installed.
If you have previously installed a runtime client, the DB2 Connect installer
upgrade adds only that functionality required for the existing client. (This is also
the case if you have a DB2 server or SDK installed on your workstation.)
3 Catalog your DB2 UDB for OS/390 databases on the gateway machine, if desired,
using either the DB2 Command Line Processor or the Client Configuration
Assistant. (After installation, you can use your standard DB2 UDB client to
access the gateway.)
NOTE: This gateway can coexist in the same instance as a DB2 UDB server.
4 On the client, catalog the DB2 UDB for OS/390 database you cataloged in Step 3
on page 8-5, using either the DB2 Command Line Processor or the Client
Configuration Assistant, against the gateway machine.
Defining a database alias. Define a database alias with the proper connection
information for your database. This alias will be the connect string used when
installing the Siebel Server. Record the connect string in Appendix A,
“Deployment Planning Worksheet.” You will specify this connect string when
installing the Siebel Server.
Use either the DB2 Client Configuration Assistant or the Command Line
Processor to define your database alias. For more information, see the DB2
Universal Database for OS/390 Administration Guide.
Enabling ODBC. If you are connecting to the mainframe, using DB2 Connect, you
must enable ODBC to point to DB2 UDB for OS/390.
TCP/IP and ftp. For instructions on installing TCP/IP, refer to IBM’s DB2 for
OS/390 Installation Guide.
You must verify that your servers are properly connected to the network and,
through the network, to each other.
To verify network connectivity between Siebel Servers and the Gateway Server,
Database Server, and File System
1 Verify network connectivity to the Gateway and Database Servers from the
application servers, using the ping utility.
DB2 UDB for UNIX, Windows NT, and OS/390. Use the CLP to ensure that you
can connect to your database. Open a UNIX shell and enter:
DB2 connect to database alias user user_ID using password
where:
If your connection is valid, you should see a message that looks like the
following:
3 Verify that the File System is visible and that the Siebel service owner account
can copy files to and from it.
Network connectivity to the Gateway Server, Database Server, and File System
is now verified.
If you will be using connection brokering, make sure that Central Dispatch has been
installed and configured on each application server that will support a Siebel Server.
You will be unable to complete the Siebel Server installation if the Gateway Server
is not running. Make sure that the Gateway Server has been started, using the
procedure described in “Starting the Gateway Server” on page 6-11.
This section provides instructions for executing the Siebel Server installation.
NOTE: The term Enterprise Server is used by Siebel to refer to a group of Siebel
Servers that can be administered and configured as a unit rather than individually.
It does not refer to a separate computer or separate program.
Therefore, when you install the first Siebel Server in your deployment, you will also
automatically create your first Siebel Enterprise Server—your first group of Siebel
Servers. When you install subsequent servers, you can include them in this
Enterprise Server or create a new one.
This process will install the Siebel Server installation script and the Siebel software
on the Siebel Server computer. Next, the process will use the software to configure
the Enterprise Server, if it does not already exist, and the first Siebel Server.
1 Installing the Siebel Server software. The Siebel Server software is installed by
executing the install_server script from the Siebel CD-ROM. This must be
run once for each application server on which you are installing the Siebel
Server software.
2 Selecting a Siebel Enterprise for the server. The script prompts you to provide the
name of the new Siebel Enterprise Server.
3 Configuring Siebel Servers. The config_server script is also executed from the
Siebel Server software installation on the application server. The
config_server script is used to edit the definition of an existing Siebel Server
or to add an additional Siebel Server to an existing Enterprise Server using the
existing software installation.
2 Log onto the server, using the Siebel service owner account that you recorded in
the copy you made earlier of Appendix A, “Deployment Planning Worksheet,”
then enter ksh to run a Korn shell. Mount the CD-ROM, if required, to make it
accessible.
If the variable definitions were already defined, but not correct, you must
redefine them.
NOTE: If these variables were not already defined, you will be prompted later by
the installation script for their definitions.
where:
NOTE: The volume label for the CD-ROM is seaunix6x; it may not be required,
depending on how you access the CD-ROM.
./install_server -d /usr/temp/server.log
The installation script has now been started. To complete the installation, you must
understand how to respond to the different types of prompts you will observe in the
installation script.
The first prompt type. This type of prompt asks you to enter the desired value for
a given parameter; the default value is shown in square brackets [ ].
Please specify the directory into which Siebel should be
installed [/siebel]
The second prompt type. This type of prompt displays a list of one or more
parameter values and asks you whether you want to modify any of them:
You will see a series of prompts that allow you to change the value. For
example,
The third prompt type. This type of prompt provides a numbered list of options;
the default choice is shown in square brackets [ ].
If the specified directory does not already exist, you will be prompted to confirm
that it should be created.
The installation script prompts you for the host name or IP address for the
Gateway Server.
If Central Dispatch is not installed and you do not plan to install it, enter N.
If Central Dispatch is not installed and you want to install it, press CTRL+C to
terminate the Siebel Server installation and go to Chapter 4, “Installing Central
Dispatch Under UNIX,” to install Central Dispatch. You will also need to reinstall
the Gateway Server.
NOTE: All Siebel Servers in an Enterprise Server must have the same Central
Dispatch configuration: Central Dispatch must be installed on all of them or
none of them.
If you are installing with Central Dispatch, the next prompt asks for the Resonate
installation directory.
If you are not installing with Central Dispatch, proceed to Step 6 on page 8-13.
4 Enter the full path for the directory in which you installed Central Dispatch.
The installer prompts you to indicate whether or not you want to configure this
section.
If you need only the default packages, enter Y and continue with the
installation.
If you enter N, you need to indicate that you accept (Y) or reject (N) each
package on the list; each package will be presented to you for your response.
After you have confirmed the packages to install, the Siebel Server installation script
installs the files on the hard disk. It then brings up a series of prompts, as described
below, to allow you to configure the Enterprise Server and Siebel Server.
2 The script prompts you to confirm whether or not you want to enter new
configuration values:
3 Enter the appropriate connect string or database alias, as appropriate for your
RDBMS.
DB2 UDB. Enter the database alias for your Siebel database server.
DB2 UDB for OS/390. Enter the database alias cataloged for your DB2 UDB for
OS/390 database server.
Oracle. Enter the SQL*Net connect string for your Siebel Server Database.
(This connect string must be defined in the Oracle tnsnames.ora file.)
DB2 UDB for OS/390. Enter the name of the database account that owns your
Siebel tables and indexes.
Oracle. Enter the name of the database account that owns the Siebel tables.
Proceed to Step 6.
5 Enter the SQL ID that defines your RACF group. This grants ordinary user
privileges for most users. The default is SSEROLE.
6 Enter the Siebel database username to be used by Siebel Server for version
checking, auto-starting server components, and operation of the
Synchronization Manager.
The Siebel Server uses this password to connect to the Database Server.
The installer displays the parameters and current values for the File System
directory and the JTC Help files.
8 Confirm whether or not you want to configure this section of the script:
To accept the configuration values as shown, press ENTER.
9 Enter the full path for the Siebel File System, or accept the default.
10 If your clients will be accessing Java Thin Client Online Help, enter the URL of
the main HTML help file (start.html).
11 If you are not using Central Dispatch, specify which type of listening port should
be used by the Siebel Server components to accept client requests:
Static ports are useful if your network devices, such as firewalls, must be
configured using this port information.
However, if your system does not require static ports, use dynamic ports; they
are easier to maintain.
The installer script displays the parameters you selected, and prompts you to
review and approve them.
The installer script displays information regarding the parameters being set. It
then displays the message that your Enterprise Server configuration is complete.
2 Enter a description or alias for the new Siebel Server. Use the server name you
recorded in the photocopy you made of Appendix A, “Deployment Planning
Worksheet.”
This alias must be unique to the Gateway Server that connects to this Siebel
Server. A Siebel Server name must be 30 characters or less in length. It must
contain only alphanumeric characters and it may not contain spaces or
punctuation.
3 Select the appropriate licensing option for Siebel eBriefing and eContent
Services.
The script displays the current value for the static port configuration.
4 Indicate whether you accept the value displayed or want to reconfigure it.
The script prompts you to set the Autostart parameter.
5 Indicate whether or not you want to configure the Siebel Server to start
automatically when the application server is restarted:
If you want to start the Siebel Server manually each time the machine
restarts, enter N.
NOTE: This setting only enables the Siebel Server to accept additional
configuration instructions to start automatically each time the host machine
restarts. For automatic startup to actually execute, you must complete the
configuration steps described in“Configuring the Siebel Server for Automatic
Start” on page 8-23 after Siebel Server installation is complete.
The installer prompts you to review the parameters for the Siebel Server before
applying them.
The installer finishes installing the Siebel Server software and then terminates,
returning you to the UNIX shell command line.
7 Indicate whether or not you want to start the Siebel Server you just created now:
To start the Siebel Server, press ENTER.
This completes the installation of the Siebel Server software on this application
server.
If your enterprise will operate multiple Siebel Servers from one Enterprise Server
installation, proceed to “Creating Additional Servers Within an Existing Enterprise
Server” to configure those servers.
NOTE: Typically, you will create multiple Siebel Servers on an application server only
for test or development purposes. Siebel Systems strongly recommends that you
create only one Siebel Server per application server in your production
environment.
2 In the shell window, enter env and verify that the environment variables
SIEBEL_GATEWAY and SIEBEL_ROOT are correctly set, as detailed below.
SIEBEL_ROOT must be set to the directory in which the Siebel Server software
is installed.
NOTE: The config_server script uses the values for these environment
variables unless they are overridden by command-line arguments.
3 If the Siebel environment variables are not set or are set incorrectly, navigate to
the SIEBEL_ROOT directory and enter . ./siebenv.sh to set them.
NOTE: Make sure there is a space between the period and ./siebenv.sh.
5 If you did not specify a Siebel Server with a command line flag, you must choose
an existing server in order to edit it or select the option to create a new server:
NOTE: You can install your second Siebel Server in the same root directory as
your Gateway and first Siebel Server, if these are installed in the same directory.
6 Repeat the steps described under “To configure the Siebel Server” on page 8-17.
For more information on these prompts and parameters, refer to “Understanding
the Prompts” on page 8-11.
The config_server script will exit after it has completed the chosen task.
Post-Installation Tasks 8
Perform the following tasks after you have completed the Siebel Server installation
program and configured all the Enterprise Servers and Siebel Servers that will be
supported from this installation.
The Siebel Server installation program automatically creates an ODBC system data
source name (DSN) that it uses to connect to the Siebel Database Server.
2 Verify that the following two values are present in the section: dbaalias =
aliasname (the database alias cataloged for your DB2 UDB for OS/390 database
server) and txnisolation = 1.
NOTE: Siebel Systems does not recommend changing the default settings created
automatically with the ODBC data source.
During the Siebel Server installation process, the script files siebenv.csh (for the
C shell and its variants) and siebenv.sh (for the Bourne and Korn shells and their
variants) are automatically created in the SIEBEL_ROOT directory. When executed,
these shell scripts set the environment variables. You may wish to add a call to the
appropriate script of the logon files of all Siebel administrator UNIX accounts, so
that these variables are set automatically whenever a Siebel administrator logs on.
If, during installation, you elected automatic restart of the Siebel Server every time
your system starts, follow the procedure below to implement this under UNIX.
ln /etc/init.d/siebel_server /etc/rc3.d/S72siebel
to:
/etc/init.d/siebel_server
ln /etc/init.d/siebel_server /etc/rc0.d/K32siebel
NOTE: You must use the actual path for SIEBEL_ROOT when copying the file and
creating the links.
If you have multiple SIEBEL_ROOT directories on the application server for which
you want to enable automatic startup, you must edit
/etc/init.d/siebel_server by adding the new SIEBEL_ROOT to the
SIEBEL_SERVER_ROOT variable. (Use spaces to separate the directories.) For
example, suppose that the first Siebel Server in the directory /usr/local/siebel
has the following variable values for the SIEBEL_SERVER_ROOT:
SIEBEL_SERVER_ROOT="/usr/local/siebel"
If, after following the steps described above, you later decide that you want to install
a new server in the directory /vol1/siebel and enable it for autostart, you must
modify the SIEBEL_SERVER_ROOT variable as follows:
SIEBEL_SERVER_ROOT="/usr/local/siebel /vol1/siebel"
NOTE: Remember that the host where the Siebel Gateway Server is installed must be
the first to start up and the last to be shut down.
Siebel Mobile Client users must be able to connect to the Siebel Remote Server,
using TCP/IP to synchronize with the master database. Make sure that you have the
correct network software and hardware installed to support this connectivity, and
that your remote users are able to establish a TCP/IP connection to the server using
the ping utility.
Before you can operate Siebel component groups, you must enable them. Please
refer to the chapter “Using the Server Manager UI” under Component Group and
Server Component Administration in the Siebel Server Administration Guide for
instructions.
You are now ready to proceed with the installation of the Siebel Database Server.
If a Siebel Enterprise Server component does not start and you receive a Central
Dispatch command timeout error in the log file for that component, you can
increase your Central Dispatch timeout value, using the Siebel parameter
SCBtimeout.
where:
Siebel Server name = the alias of the Siebel Server in which the components
failed to start
If the default value has never been changed, the command will fail with the
following error:
where:
new value= the new timeout value that you want to apply in seconds, for
example, 360.
2 Increase the value of the timeout parameter by 60 seconds for each failed
component.
If, after trying this procedure, the component still does not start, contact Siebel
Technical Support.
Chapter 10. Installing the Siebel Database Server with DB2 UDB for UNIX and Windows NT
Chapter 11. Configuring the DB2 UDB for OS/390 Database Server
Chapter 12. Installing the Siebel Database Server with DB2 UDB for OS/390
This chapter is written for database administrators who will set up the DB2
Universal Database. It provides an overview of Siebel database configuration and
sizing recommendations for the DB2 database server. The parameter settings
offered in this chapter are intended as starting points. You may need to increase
these, depending on your enterprise requirements.
One of the most important factors to determine about your database is its overall
size. In your planning, you will need to allocate space for system storage, rollback
or temporary storage space, log files, and other system files required by DB2, as well
as space for Siebel data and indexes. If you allocate too little space for your system,
performance will be affected and, in extreme cases, the system itself may be halted.
If you allocate too much, you waste space.
The space needed by DB2 will vary primarily based on the total number and types
of users supported. Siebel Systems recommends that you consult the IBM DB2
technical documentation for more information on these requirements.
The space required for Siebel data and indexes will vary depending on what Siebel
functionality you will implement and the amount and nature of data supporting it.
At a minimum, Siebel version 6.x requires that you size your DB2 database at from
500 to 700 MB.
The process for making accurate database size calculations is a complex one
involving many variables. The following guidelines will assist you in the process:
Determine the total number, and types, of users of Siebel eBusiness Applications
(for example, 500 sales representatives and 75 sales managers).
Determine the Siebel functionality that you will implement and the entities
required to support them. Typically, the largest entities are as follows:
Accounts
Activities
Contacts
Forecasts
Opportunities
Service Requests
Estimate the average number of entities per user (for example, 100 accounts per
sales representative) and calculate an estimated total number of records per
entity for your total user base.
Using standard sizing procedures for your specific database, and the Siebel Data
Model Reference, calculate the average record size per entity and multiply by the
total number of records. Typically, these entities span multiple physical tables,
all of which must be included in the row size calculation. This will determine
the estimated data sizes for the largest entities.
You must add additional space for the storage of other Siebel data. A rough
guideline for this additional amount would be one-half the storage required for
these key entities.
Regardless of the RDBMS you implement and your chosen disk arrangement, be
sure that you properly distribute the following types of database objects:
S_ACCNT_POSTN S_OPTY
S_ADDR_ORG S_OPTY_POSTN
S_CONTACT S_POSTN_CON
S_DOCK_TXN_LOG S_POSTN_RPT_REL
S_EMPLOYEE S_SRV_REQ
S_EVT_ACT S_OPTY
S_ORG_EXT
If you will make extensive use of the Enterprise Integration Manager (EIM), you
may want to put the interface tables (names beginning with EIM_ or ending in _IF)
on different devices from the Siebel base tables, because both are accessed
simultaneously during EIM operations.
This section contains guidelines for obtaining optimum performance from a DB2
Universal Database, version 6.1. The guidelines described here provide suggestions
that will be useful to a broad segment of customers. However, you should choose
values for the parameters described in this guide that reflect conditions in your
particular environment. Refer to your IBM DB2 technical documentation for
additional information.
The database configuration parameters can be set using the update database
manager configuration command of the DB2 Command Line Processor or using
the DB2 Control Center.
NOTE: See the IBM DB2 technical documentation for more information on modifying
the database configuration parameters.
Table 9-1 lists DB2 database manager configuration parameters that differ from the
default settings. Set these parameters for each DB2 instance.
Use the configuration information below for the listed parameters. For parameters
not listed in this table, accept the default settings.
Use the db2set command of the DB2 Command Line Processor to set the
parameters (for example, db2set DB2_RR_TO_RS = YES) referenced in Table 9-2.
DB2_MMAP_READ Recommended setting only; you should evaluate this setting OFF
for your particular configuration and environment.
DB2_CORRELATED_PREDICATES When set to YES, the optimizer is able to determine whether YES
predicates in a query are related, which permits DB2 to
calculate the filter factor more accurately.
1. The tools check-out process requires an isolation level of “repeatable read.” Turning this parameter on
disables all repeatable reads, causing an application to use “read stability.” This status is unacceptable for
tools check-out and, therefore, development environments.
The database configuration parameters can be set using the update database
configuration command of the DB2 Command Line Processor or using the DB2
Control Center.
NOTE: See the IBM DB2 technical documentation for more information on modifying
the database configuration parameters.
Table 9-3 lists DB2 database configuration parameters that differ from the default
settings. However, these are guidelines only.
Set these parameters for each database on which you run your Siebel application.
Use the configuration information below. For other parameters, accept the default
settings.
LOGBUFSZ Log buffer size (4 KB) 512 (for AIX, set this to 128)
LOCKLIST Maximum storage for lock list (4 KB) 5000 (The setting should never be
smaller than this, but may be
increased.)
STMTHEAP SQL statement heap (4 KB) 8192 (This value represents the
minimum setting; if you will use
EIM to import a large amount of
data, set the parameter to 10000
as a starting point.)
MAXAPPLS Maximum number of active applications Based on the number of users plus
at least 20 for Application Server
connections
The scripts you will run during your Database Server installation specify the
tablespaces in which to store your Siebel tables and indexes. A Siebel DB2 database
consists of four tablespaces using database managed space (DMS). A detailed
description of the tablespaces is provided in the table under Step 4 on page 9-14.
Each tablespace may have one or more tablespace containers to store the data.
For a test (small, non-production) installation, store the Siebel objects in a single
container per tablespace.
After installing the Database Server installation scripts on the Siebel Server
machine, modify the database table and index creation scripts to specify the
tablespace names you created for Siebel tables and objects.
When you are using a UNIX database server, all containers should reside on raw
UNIX disk partitions, except the containers used for LONG VARCHAR data.
Containers for LONG VARCHAR data should reside on the UNIX file system to take
advantage of the operating system’s buffering capabilities. To ensure that your
database will perform well, create one container for each available logical or
physical disk device.
Data and log devices should reside on different disk spindles to reduce contention
between random and serial I/O. Ideally, all DB2 devices should reside on different
disk spindles to minimize I/O contention. When this approach is not possible,
spread devices that contain database objects that are often used together across
different spindles. These objects include tables, their indexes, and commonly joined
tables.
You can use tablespaces to place objects on logical containers, creating tablespaces
to span one or more containers. Tablespaces can be used to place objects on
multiple physical containers to promote parallel I/O. Spreading the data and index
information across several containers (physical devices) can improve the
performance of queries.
Mirroring 9
You must create database transaction logs large enough to support various large
transactions used by the Siebel software. On DB2, three parameters affect the
amount of log space reserved:
LOGSECOND. Extra log files that are allocated only if they are needed for a large
transaction.
If LOGRETAIN is set to NO, you can only do backup/restore recovery and cannot do
roll-forward recovery. This may have implications for your disaster recovery process
related to your production Siebel Database Servers.
Siebel Systems recommends that your DBA review the setting for this parameter.
Using Bufferpools 9
A bufferpool is an area of main system memory that is used for holding pages of
data that have been fetched from the tablespace. In DB2, each tablespace is
associated with a bufferpool. Adding more space to a bufferpool will enhance the
performance of the database.
You must create at least four bufferpools for the Siebel tablespaces. You can use the
default bufferpool (called IBMDEFAULTTBP) to buffer data pages from all the Siebel
tablespaces except for the SIEBEL_16K tablespace and the temporary tablespaces.
You must also create additional bufferpools with 4-KB, 16-KB, and 32-KB page sizes
for sorting and other SQL processing. A sample configuration is shown in Table 9-4.
BUF4KTEMP 100-200 MB 4 KB
BUF32KTEMP 32 MB 32 KB
Temporary Tablespaces 9
You must create 4-KB, 16-KB, and 32-KB temporary tablespaces for sorting and
other SQL processing.
Siebel Systems recommends that you use system managed space (SMS) for all
temporary tablespaces, and that each temporary tablespace be expandable to 2GB
for storage purposes.
Several database administration tasks are required before you install the Siebel
Database Server. These tasks will help ensure that you obtain optimum
performance from your DB2 database working with your Siebel application.
NOTE: You do not need to be logged into this administrator account; you just
need to make sure that it exists.
2 Set the database manager and database configuration parameters. (See “DB2
Database Manager Configuration Parameters” on page 9-6 and “DB2 Database
Configuration Parameters” on page 9-8.)
Siebel Systems recommends that you use the default tablespace names
shown in the table.
Create the SIEBEL_16K tablespace with a page size of 16-KB. All of the other
tablespaces should have a page size of 4-KB.
b Create any additional tablespaces that may be used for storing individual
tables, such as S_DOCK_TXN_LOG.
5 Create 4-KB, 16-KB, and 32-KB temporary tablespaces to use for sorting and
other SQL processing, as shown in the following table.
TEMP4K BUF4KTEMP
TEMP16K BUF16K
TEMP32K BUF32KTEMP
Updating Statistics 9
On DB2, statistics are updated using the runstats database utility. Siebel provides
a Korn shell script, the updatestats.ksh script, to run this utility properly on the
Siebel Database.
The updatestats.ksh script scans the database tables and indexes to gather
information about each table, such as the number of rows in the table, and the
number of unique values in the index attributes. The Database Optimizer uses the
information gathered by the updatestats.ksh script to pick the best method for
solving queries.
You should update statistics on tables when there has been a change of 20% or
more in the row distribution. It is not usually necessary to update statistics on all
of the tables, but only on those that have changed. Siebel Systems recommends that
you edit a version of this script that updates the tables that change frequently in
your installation. See the Siebel Data Model Reference for information on how tables
relate to each other.
NOTE: As far as possible, run the updatestats.ksh script only for changed tables,
not for all tables, to save time and prevent locking problems.
Caution: Never use the runstats utility to update statistics for the
S_DOCK_INIT_ITEM or the S_ESCL_LOG tables.
The updatestats.ksh script should be run only when there is little activity on the
system, particularly activity by Siebel eBusiness Application clients, for instance, at
midnight or later. If you run this utility while users are accessing and updating the
Siebel Database, lock contention may occur. When this happens, an error message
like this will be generated:
This will not harm your database, but the updatestats.ksh script will have to be
run again for any table for which this type of error was generated, because statistics
were not updated for that table. You must also update statistics on any tables that
were missed.
A DBA can split the updatestats.ksh script into a series of smaller scripts to
update only those tables that have changed. For example, the table S_ZIPCODE
does not change very often, and therefore you will not need to update statistics on
this table except when you add new ZIP codes to it. After your DBA has created
separate scripts to update your tables separately, you should run these scripts
frequently on those tables that change frequently.
This chapter is written for system administrators who will install the Siebel
Database server.
To install the Siebel Database server, you will first install the Database Scripts on a
Windows NT or UNIX Siebel Server. Then you will run the Database Scripts to
create the following in your Siebel Database:
Pre-Installation Tasks 10
Before installing the Siebel Database server, you must complete the following tasks:
Obtain the services of a qualified database administrator who will assist you
during your installation.
Complete all the steps in the appropriate chapters of Part 1, “Installing Central
Dispatch and the Siebel Gateway Server,” and Part 2, “Installing the Siebel
Server,” to install at least one Siebel server.
If you have not already done so, copy the Deployment Planning Worksheet,
located in Appendix A, and fill out the appropriate page with the following:
DB2 Database Alias. This is the appropriate DB2 database alias that you
created when installing the DB2 software.
Siebel Data Tablespace. The name of the tablespace on the DB2 server where
the 4-KB Siebel data tables are stored.
Siebel Long Tablespace. The name of the tablespace on the DB2 server where
tables reside whose row length equals less than 4006 bytes.
Siebel 16-KB Tablespace. The name of the tablespace on the DB2 server where
tables reside whose row length equals greater than 4005 bytes.
Siebel Index Tablespace. The name of the tablespace on the DB2 server where
the Siebel indexes are stored.
In addition, perform the following tasks, discussed in this section before executing
the Database Server installation scripts:
Complete the steps below to complete the Database server installation scripts on
one Windows NT application server. You must have a Siebel Server already installed
on this application server.
2 Read the Welcome screen and click Next to continue with the setup program.
The Setup Type screen appears.
Compact. This setup option will install a minimum subset of all components.
Custom. This setup option lets you customize your installation by choosing
the specific database platform scripts you want to install.
The Setup Status screen appears and shows the progress of database script
installation.
When the installer finishes installing the required files, the Event Log appears.
4 Review the results of the installation in the Event Log screen, and then click
Next.
2 Log onto the application server using the Siebel service owner account recorded
in Appendix A, “Deployment Planning Worksheet.”
. ./siebenv.sh
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
Also verify that the appropriate RDBMS environment variables have been set.
For information on what these are, consult your RDBMS vendor’s
documentation.
where:
NOTE: The volume label for the CD-ROM is seaunix6xx, and may not be
required, depending on how you access the CD-ROM.
If you need to make changes to the package selection, enter N at the prompt and
make the necessary changes; otherwise, enter Y at the prompt to proceed with
the installation.
The Database server software installer will copy the necessary files to disk and
exit when it has completed the installation.
Review the directory structure created by the Database Server installation. The
directory structure is located under the directory specified during the installation.
bin
files
db2udb
enu
siebproc
aix
hpux
solaris
winnt
ctiproc
aix
hpux
solaris
winnt
files. Contains sample file attachments. These should be copied to the File System.
See “Post-Installation Task” on page 10-28.
db2udb. Contains the scripts for the DB2 Universal Database server.
aix. CTI source code, makefiles, and stored procedures for DB2 AIX systems.
hpux. CTI source code, makefiles, and stored procedures for HP-UX systems.
solaris. CTI source code, makefiles, and stored procedures for DB2 Solaris
systems.
winnt. CTI source code, makefiles, and stored procedures for Windows NT
systems.
NOTE: For DB2, db2udb includes the source code and compiled libraries for each
supported database platform of the CTI stored procedures for both the Genesys and
Aspect CTI middleware products. Please see Siebel Release Notes for more
information about modifying and using these stored procedures.
On DB2, you must manually create the tableowner account (default: SIEBEL), the
Siebel Administrator account (default: SADMIN), and the sse_role group. You must
then add the two accounts to the sse_role group. In addition, the stored
procedures fence ID (default: db2fenc1) requires read access on the Siebel tables.
This ID should be a member of the sse_role group.
Then you must execute the grantusr.sql script against your database server to
grant the appropriate privileges to these users. The grantusr.sql script must be
run before you install the Siebel Database server.
This script is located in the appropriate subdirectory for your database platform.
Your database administrator should review and run this script, which performs the
following functions:
Grants the appropriate permissions to the Siebel tableowner account that will
“own” all the database objects for your Siebel deployment
NOTE: Do not change the name of the Siebel Administrator Account, SADMIN. This
account must be created for you to log onto Siebel as the Siebel Administrator.
If you are installing under Windows NT, use the following commands:
db2 connect to [DB2database Alias] user
[Instance Owner Username] using [password]
NOTE: You must specify the full path to the dbsrvr directory.
The script prompts you for the default tablespace in which your Siebel objects
are to be created.
2 Enter the tablespace name you recorded in the copy you made of Appendix A,
“Deployment Planning Worksheet.”
To install the stored procedures and user-defined functions on your Database Server,
you must first transfer them to the Database Server and then run the installation
script.
The UDFs and stored procedures must be transferred to and installed on the Siebel
Database Server to support the Siebel product. You may do this by copying the files,
if your Database Server’s hard disk is NFS-mounted to the computer from which
you are installing the Siebel Database Server, or by using the ftp command if the
Database Server’s hard disk is not NFS-mounted to that computer.
Under Windows NT servers, you would normally log on to the source installation
machine and copy the files from it to the NFS-mounted Database Server hard disk.
Under UNIX, you would normally ftp the files from the source installation
computer to the Database Server. You may choose to use ftp with Windows NT
servers, though, or copy between NFS-mounted hard disks with UNIX servers. Any
method that transfers the necessary files to the correct location on the Database
Server is acceptable.
The default account name and password are both SADMIN, and you can safely use
this default if you wish. This account will be created while you are installing the
Siebel Database Server; you cannot create it now.
By default, DB2 for Windows NT runs under the System user ID, which would
mean that the UDF would also need to run under the System user ID. However, the
System user ID is not allowed to connect to the database, so the user ID for DB2
must not be System. To run DB2 on Windows NT, you must create a user account
under Windows NT called db2admin that has at least the following Advanced User
Rights:
Increase quotas
Log on as a service
Replace a process-level token
If you already have a db2admin account, continue to the procedure called “To
configure DB2 to use the DB2ADMIN account under Windows NT” on page 10-12.
Username: db2admin
Full Name: DB2 Administrative Account
Description: Administrative account for DB2 Universal
Database Server
Password: db2admin
Confirm Password: db2admin
User must change Unchecked
password at next login:
User cannot change Unchecked
password:
Password never expires: Checked
Account disabled: Unchecked
NOTE: All DB2 batch files (.bat), .ksh files, and SQL scripts (.sql) use
uppercase passwords, so you must assign only uppercase passwords to any
accounts or logons used by these files.
4 Click Groups, and assign the db2admin account to the Administrators group, or
whichever group at your site holds administrative privileges.
5 To quit the Groups and New User screens, click OK, and then close the User
Manager.
After you have created this account, you must set the DB2 User ID to db2admin by
using the Services icon in the Windows NT Control Panel.
A dialog box with a list of available DB2 services appears. Each service will have
a name similar to:
DB2-instance_name
where instance_name = the name of the DB2 instance to which this service
connects.
NOTE: The service that requires change to the user ID is the database manager,
usually called DB2 - DB2. This change is not necessary for the administration
server, usually called DB2 - DB2DAS00, because the administration server
already uses the user ID db2admin.
2 Copy all files in this directory to a temporary directory, such as c:\temp, on the
target install machine.
4 In the DB2 Command Window, navigate to the temporary directory to which you
transferred the installation script and files, and enter installsiebel.
2 Invoke the ftp client on the source install computer and connect to the Database
Server.
If you are using a standard command-line ftp client, enter ftp -i database
server machine name .
NOTE: There are a number of GUI client implementations of ftp that do the same
thing as standard command-line ftp clients. The instructions provided are for
the command-line ftp clients, but you may use a GUI client to perform the
following steps provided you know how to do so.
If you are using a standard command-line ftp client, issue the following
commands:
8 Verify that the siebel.tar file is in the home directory, and enter tar -xf
siebel.tar to uncompress the TAR archive.
The TAR archive will create a subdirectory called siebel that will contain the
necessary scripts and other files.
12 When the script has finished and returned you to a shell prompt, log out from
the database server.
If you would like to override the default storage parameters, such as the tablespaces
in which specific tables are created, edit the ddl.ctl file located in the
dbsrvr\db2udb directory.
For each Siebel table, you can specify a tablespace by using the Space parameter.
In the following example, the tablespace for the table S_APP_VIEW is set to DATA1.
As provided by Siebel, the .ctl file does not set storage parameters for the objects
it creates, so they will default to the parameters of the tablespaces in which they are
created.
As shown in the example below, you can use the Space parameter to set storage
parameters for specific tables.
[Object 219]
Type = Table
Name = S_APP_VIEW
Column 1 = ROW_IDVARCHAR(15)NOTNULL
Column 2 = CREATEDTIMESTAMPNOTNULL DEFAULT %NOW%
Column 3 = CREATED_BYVARCHAR(15)NOTNULL
Column 4 = LAST UPDTIMESTAMP NOTNULL DEFAULT %NOW%
Column 5 = LAST_UPD_BYVARCHAR(15)NOTNULL
Column 6 = DCKING_NUMNUMERIC(22,7)DEFAULT 0
Column 7 = MODIFICATION_NUMNUMERIC(10,0)NOTNULL DEFAULT 0
Column 8 = CONFLICT_IDVARCHAR(15)NOTNULL DEFAULT ‘0’
Column 9 = NAMEVARCHAR(50)NOTNULL
Column10 = DESC_TEXTVARCHAR(255)
Column11 = LOCAL_ACCESS_FLGCHAR(1)
Space = data1
The Siebel Server installation program installs a utility called ODBCSQL.exe in the
\siebsrvr\bin directory. Siebel Systems recommends that you use this utility to
test your ODBC data source after database server installation. This utility is also
particularly useful in troubleshooting post-installation connectivity problems that
may stem from the ODBC layer of your installation.
where:
SIEBEL_DATASOURCE_NAME = the data source name for which you would like
to test connectivity, for example:
siebel_srvr_enterprise_name
2 Type:
login SADMIN/password;
3 Type:
select APP_VER, COMMENTS from TABLE_OWNER.S_APP_VER;
The foregoing commands should result in the display of the application version and
any comments. The display should also indicate whether or not connectivity
through the ODBC layer was set up correctly. Error messages at this point indicate
that problems exist downstream from the ODBC layer to the database or problems
in the user/password combination or SSE_ROLE privileges for that user.
You must complete two steps to install the Siebel Database server:
The Database Server installation script is called install.ksh and is located in the
DB2 subdirectory. It does the following:
Note the following guidelines when editing all Siebel Database Server scripts:
To comment out a line, use the number sign (#), not REM.
The forward slash (/), rather than the backslash, is used as a separator in
directory paths for both Windows NT and UNIX. For example:
C:/sea6xx/dbsrvr
Follow the syntax examples and instructions in the .ksh files closely. They
indicate, for example, where quotes must be included around values and the
proper case for parameter values.
Version 6.3.1 Siebel Server Installation Guide 1 0 - 1 7
Installing the Siebel Database Server with DB2 UDB for UNIX and Windows NT
Installing the Database Server
Make sure you update items that default to CHANGE_ME or unspecified. These
default entries will not work if left unchanged.
SRC_TBLO=SIEBEL The Siebel Database tableowner. This is the account that will own
the Siebel objects.
ODBC=CHANGE_ME ODBC data source to access the database. The data source is created
automatically by the Siebel Server installation, using the format
SiebSrvr_EnterpriseServerName. The default is CHANGE_ME
and must be modified or your installation will fail.
To find out the ODBC data source name for the Siebel Server, do the
following:
Under Windows NT, navigate to the Control Panel and choose
ODBC Data Sources System DSN.
Under UNIX, navigate to SIEBEL_ROOT/sys and open the file
.odbc.ini.
Look for a DSN with the naming convention
SiebSrvr_EnterpriseServerName.
DB_LANG=Unspecified Names the language used by the database, such as enu for U.S.
English. See the install.ksh file for other valid entries.
2 In the Korn shell window, type ./install.ksh and press ENTER to start the
install script.
The install.ksh script first prompts you to review the parameter settings.
If any are incorrect, enter N to terminate the script and modify the variables.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
The install.ksh script will prompt you to review the parameter settings.
The log files may include certain errors that are expected and benign. Compare any
error messages found in the log files to the sample error messages in the
errors.rtf file, which is located in the same directory. (If a log file is not listed in
the errors.rtf file, then there are no acceptable error messages for that log file.)
No further action is required if the log files contain errors listed in the errors.rtf
file.
NOTE: Only one of each type of error occurring in a particular log file appears in the
errors.rtf file.
If you find errors that are not listed in the errors.rtf file, correct the condition
that caused the errors, and then rerun install.ksh to complete the installation.
Do not review error numbers alone, since these may have changed following
installation of a new driver version. Instead, compare the actual error descriptions
to find out which are acceptable errors for this platform.
Finally, you must execute the imprep.ksh script to load the Siebel repository into
the Siebel database. This utility loads a new Siebel repository containing the version
6.x Siebel applications objects into the repository tables in the Database Server.
Regardless of how many Siebel eBusiness Applications you are using (for example,
Siebel Sales, Siebel Service, Siebel Marketing), you will run the imprep.ksh script
only once.
SRC_USR=SADMIN User name of the Siebel administrator. Change as appropriate for your
installation.
SRC_TBLO=CHANGE_ME The Siebel Database tableowner. This is the account that will own the
Siebel objects.
ODBC=CHANGE_ME ODBC data source to access the database. The data source is created
automatically by the Siebel Server installation, using the format
SiebSrvr_EnterpriseServerName. The default is CHANGE_ME
and must be modified or your installation will fail.
To find out the ODBC data source name for the Siebel Server, do the
following:
Under Windows NT, navigate to the Control Panel and choose ODBC
Data Sources System DSN.
Under UNIX, navigate to SIEBEL_ROOT/sys and open the file
.odbc.ini.
Look for a DSN with the naming convention
SiebSrvr_EnterpriseServerName.
REPOS_NAME= Name to be given to the Siebel repository after import. This should not
“Siebel Repository” be changed.
DB_LANG=Unspecified Names the language used by the database, such as enu for U.S. English.
Use all lowercase letters. See your database server installation for other
valid entries.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
The imprep.ksh script will prompt you to review the parameter settings.
NOTE: You may need to do this twice to close the shell window.
The log files may include certain errors that are expected and benign. Compare any
error messages found in the log files to the sample error messages in the
errors.rtf file, which is located in the same directory. (If a log file is not listed in
the errors.rtf file, then there are no acceptable error messages for that log file.)
No further action is required if the log files contain errors listed in the errors.rtf
file.
NOTE: Only one of each type of error occurring in a particular log file appears in the
errors.rtf file.
If you find errors that are not listed in the errors.rtf file, correct the condition
that caused the errors, and then rerun imprep.ksh to complete the installation.
Do not review error numbers alone, since these may have changed following
installation of a new driver version. Instead, compare the actual error descriptions
to find out which are acceptable errors for this platform.
Post-Installation Task 10
Perform the following tasks after you complete your installation of the Siebel
Database Server:
Specific files needed to run the Siebel File System, such as correspondence
templates and Siebel Marketing files, are provided with the Siebel Database Server
software. A subdirectory called files is created automatically when you install the
Siebel Database Server.
You must populate the File System directory with these file attachments after
installing the Database Server, and before running the Siebel client.
This chapter is written for database administrators who will set up the DB2 UDB for
OS/390 database. It provides an overview of Siebel Database configuration and
sizing recommendations for the DB2 UDB for OS/390 database server. The
parameter settings offered in this chapter are intended as starting points. You may
need to increase these settings, depending on your enterprise requirements.
The space needed by DB2 will vary primarily based on the total number and types
of users supported. Siebel Systems recommends that you consult the IBM DB2 UDB
for OS/390 technical documentation for more information on these requirements.
The space required for Siebel data and indexes will vary depending on what Siebel
functionality you implement and the amount and nature of data supporting it. The
process for making accurate database size calculations is a complex one involving
many variables. The following guidelines will assist you in the process:
Determine the total number, and types, of users of Siebel eBusiness Applications
(for example, 500 sales representatives and 75 sales managers).
Determine the Siebel functionality that you will implement and the entities
required to support them. Typically, the largest entities are:
Accounts
Activities
Contacts
Forecasts
Opportunities
Service Requests
Estimate the average number of entities per user (for example, 100 accounts per
sales representative) and calculate an estimated total number of records per
entity for your total user base.
Using standard sizing procedures for your specific database, and the Siebel Data
Model Reference, calculate the average record size per entity and multiply by the
total number of records. Typically, these entities span multiple physical tables,
all of which must be included in the row size calculation. This will determine
the estimated data sizes for the largest entities.
You must add extra space for the storage of other Siebel data. A rough guideline
for this amount would be one-half the storage required for these key entities.
Database Layout 11
Regardless of the RDBMS you implement and the disk arrangement you choose, be
sure that you properly distribute the following types of database objects:
S_ACCNT_POSTN S_ORG_EXT
S_ADDR_ORG S_OPTY
S_CONTACT S_OPTY_POSTN
S_DOCK_TXN_LOG S_POSTN_CON
S_EMPLOYEE S_POSTN_RPT_REL
S_EVT_ACT S_SRV_REQ
If you will make extensive use of Siebel Enterprise Integration Manager (EIM), you
may want to put the interface tables (names beginning with EIM_ or ending in _IF)
on different devices from the Siebel base tables, since both are accessed
simultaneously during EIM operations.
On a DB2 UDB for OS/390 database server, data and log datasets should reside on
different DASD volumes to reduce contention between random and serial I/O.
Ideally, all DB2 devices should reside on different disks to minimize I/O contention.
When this approach is not possible, DB2 tablespaces and index spaces should be
spread across all available DASD volumes to reduce I/O contention. These objects
include tables, their indexes, and commonly joined tables.
You can use DB2 UDB for OS/390 storage groups (STOGROUPs) to place tablespaces
and index spaces of different volumes. To do this, you assign multiple STOGROUPs
to the set of Siebel tablespaces, with each STOGROUP containing unique sets of
DASD volumes. You can also use multiple STOGROUPs for the set of Siebel index
spaces, with each STOGROUP containing unique sets of DASD volumes.
You can also use Data Facility Storage Management Subsystem (SMS) to randomly
distribute tablespace and index space data sets across multiple DASD volumes.
DB2 Structure 11
D B 2 /3 9 0 D a t a b a s e S e r v e r
D a t a b a s e
S t o r a g e G r o u p
In d e x e s T a b le s p a c e L o g s
T a b le s T a b le s
At each of these levels, physical and logical layout may differ; the OS/390 operating
system provides enhanced data security and performance through a complex file
system and other services.
Storage Groups
A DB2 storage group is a set of volumes on direct access storage devices (DASD).
These volumes hold the data sets in which tables and indexes are actually stored.
Tablespaces in DB2
A tablespace is one or more data sets in which one or more tables are stored. A
tablespace can consist of a number of VSAM data sets. Tablespaces are divided into
equal-sized units, called pages, which are written to or read from DASD in one
operation. You can specify page sizes for the data; the default page size is 4 KB.
Siebel uses 4-KB, 16-KB, and 32-KB tablespaces.
When you create a tablespace, you can specify the database to which the tablespace
belongs and the storage group it uses. You can also determine what kind of
tablespace is created: simple, segmented, or partitioned.
Simple tablespaces. A simple tablespace can contain more than one table, but, unlike
segmented tablespaces, the rows of different tables are not kept separate.
Users may create the DB2 UDB for OS/390 database with either an ASCII or an
EBCDIC code page. For users using ASCII-based clients (the majority of users), it is
best to create the database using the ASCII code page. That will significantly reduce
the amount of code page conversion processing required on both the server and
client machines.
NOTE: On DB2 UDB for OS/390, the code page is also known as the CCSID.
You must now allocate sufficient space to hold your data. The scripts you will run
later, during your database server installation, will use this space to create the
tablespaces in which to store your Siebel tables and indexes (Table 11-1).
For information regarding how to size your database for small, medium, large, and
extra-large installations, refer to the DB2 Universal Database for OS/390 Installation
Guide. Table 11-1 lists the number of database objects created during the Siebel
installation and can be used as a sizing guideline.
Tables 1500
Indexes 7500
Packages 100
DB2 UDB for OS/390 requires that indexes be no longer than 255 bytes. This means
that the total indexed fields within a table must be no longer than 255 bytes. This
is handled automatically in standard Siebel installations, but customers who have
customized indexes must ensure their total key length does not exceed 255 bytes.
To calculate the length of a table’s index entry, add the total index value for each
indexed field in the table. Use the following guidelines to determine the index value
for each field:
VARCHAR columns require one byte per character plus two bytes overhead
The size of logs you will need depends on how frequently your Siebel Database will
be updated, and how frequently you can accept some background server activity
while logs are archived. DB2 archives its active logs when the log datasets fill, and
will not reuse an active log until it has been archived. If log size is extremely
inadequate, the server may not be able to free log space fast enough, and processing
will stop until an active log has been archived and the space becomes available.
Small log files will also result in excessive system check pointing.
If this happens, or if archiving occurs too frequently and is impacting your database
server’s performance, the active logs need to be increased in size to reduce
archiving frequency to an acceptable level. See the DB2 Universal Database for
OS/390 Installation Guide, DASD requirements for active log data sets, to get sizing
information.
If you will be installing the Siebel Database on an existing DB2 UDB for OS/390
database server, the DB2 logs are probably already sized to handle the additional
load. If excessive archiving results after installing Siebel eBusiness Applications, the
active logs may need to be increased in size.
A bufferpool is an area of main system memory that is used for holding pages of
data that have been read from DASD. In DB2 UDB for OS/390, each tablespace is
associated with a bufferpool. Adding more space to a bufferpool can reduce I/O
requests, but will reduce the total storage available for other usage.
You will create at least three bufferpools for the Siebel tablespaces, with 4-KB, 16-
KB, and 32-KB page sizes for sorting and other SQL processing. A sample
configuration is shown in Table 11-2.
PPPPP16K 32 MB 16 KB
Temporary Tablespaces 11
You must also create 4-KB, 16-KB, and 32-KB temporary tablespaces in the system
database DSNDB07 for sorting and other SQL processing.
Partitioning Tables 11
A-L Partition
ROW_ID Last Name First Name Mr/Ms Phone Number
Ñ Azarov Vitaly Mr. (212) 856-0933
Ñ Bell Charles Mr. (818) 793-0016
Ñ Carter Remy Ms. (831) 226-7510
Ñ Coriolo Antonio Mr. (972) 652-7282
Partitioning Index
Data
and Partitioning Key
M-Z Partition
ROW_ID Last Name First Name Mr/Ms Phone Number
Ñ Martinez Eduardo Mr. (915) 584-6790
Ñ Neuss Guenther Mr. (405) 216-6743
Ñ Richards Mathilda Ms. (914) 725-8436
Ñ Trabant Violet Ms. (202) 387-4452
You may choose to partition EIM tables in order to run them in parallel rather than
serially, to speed data transfers into your database. To do this, you must divide your
EIM tables through their primary indexes, and set the partition key by batch
number. Each partition will then function as its own tablespace, and can run in
parallel with the others.
For more information, see “Creating the Database Objects” on page 12-13.
NOTE: Siebel does not currently support partitioning using clustered indexes.
However, partitioned tablespaces are supported with the result that base tables can
grow to 16 terabytes.
Several database administration tasks are required before you install the Siebel
Database Server. These tasks will help ensure that you obtain optimum
performance from your DB2 database working with your Siebel application.
The following tasks should be performed after you have installed your DB2 UDB for
OS/390 database software on your OS/390 server according to the instructions in
the IBM DB2 UDB for OS/390 documentation.
2 Make sure that a user who has administrative privileges has been created on
your computer in your local network domain.
3 From your local computer, log onto the DB2 UDB for OS/390 database server.
4 Create the ID and password for the Siebel (SSEROLE) and EIM (SSEEIM) user
groups, respectively, and assign them the necessary permissions.
SSEROLE is the default Siebel user group name, and should contain all Siebel
users. It must be assigned the appropriate permissions for Siebel users.
SSEEIM is the default EIM user group name, and should contain any users who
will use EIM. It must be assigned appropriate permissions for EIM.
5 For security and access control of your Siebel database server, Siebel Systems
recommends that you assign a security group, using RACF (Resource Access
Control Facility) or another security control system, to create the Siebel
administrative user (the default is SADMIN), and assign this user to the Siebel
users’ group.
6 In the installation CLIST, or through the installation job stream $TIJUZ, set the
database manager and database configuration parameters. (For information on
these, see Table 11-3 on page 11-15.)
7 Size the logs, as described in “Allocating Log Space for Siebel Transactions” on
page 11-9.
Updating Statistics 11
You should update statistics on tables when there has been a change of 20% or
more in the row distribution. It is not usually necessary to update statistics on all
of the tables, but only on those that have changed. Siebel Systems recommends that
you edit the rstats390.exe script, located within the bin subdirectory of your
siebsrvr directory, that updates the tables that change frequently in your
installation. See the Siebel Data Model Reference for information on how tables
relate to each other.
NOTE: As far as possible, you should update statistics only for changed tables, not
for all tables, to save time and prevent locking problems.
Caution: Never use the runstats job to update statistics for the
S_DOCK_INIT_ITEM or the S_ESCL_LOG tables.
You should update statistics only when there is little activity on the system,
particularly activity by Siebel eBusiness Application clients, for instance, at
midnight or later. If you run this utility while users are accessing and updating the
Siebel Database, lock contention may occur. When this happens, an error message
like this will be generated:
This will not harm your database, but the RUNSTATS job will have to be run again
for any table for which this type of error was generated, because statistics were not
updated for that table.
You can execute RUNSTATS on an active system if you specify SHRLEVEL CHANGE
as an option on the RUNSTATS job. This allows concurrent access while the
RUNSTATS utility executes.
Configurable Parameters 11
Reconfigure the parameters listed in Table 11-3 within DSNZPARM for optimum
operation of Siebel eBusiness Applications.
.
Table 11-3. DB2 /390 Database Manager Configuration Parameters (DSNZPARM)
To install the Siebel Database Server, you install the database scripts on a Windows
NT or UNIX application server on which a Siebel Server has already been installed.
This application server acts as a client for the DB2 UDB for OS/390 database.
You edit and execute Siebel scripts on the client to create sql files to be executed
against the DB2 UDB for OS/390 database. Siebel also supplies other sql files as a
part of installation that you can execute, if desired.
You can transfer sql files from the client machines to the mainframe, using ftp or
similar file transfer programs. These sql files can be executed either from the client
machines using Siebel-provided odbcsql command; from OS/390 using an IBM
utility like SPUFI; or processed through any version control software in use by your
site, to create the following objects in your Siebel Database:
Installation of the Siebel database server consists of several tasks, some of which
the Siebel system administrator performs, other tasks being performed by the
DB2 UDB for OS/390 database administrator. Table 12-1 illustrates the sequence of
tasks.
Siebel administrator 1 Installs a Siebel Gateway Server, Siebel Server, and Siebel Database
scripts on one or more machines. One machine can be assigned to the
database administrator to run Siebel dba-specific scripts, as required. An
application server must be installed as a prerequisite to running the
database server installation scripts, although it is unnecessary to use this
application server for executing the installation scripts.
2 Installs the Siebel 6.x client on the machine where the Siebel Server
resides.
DB2 UDB for 3 Allocates space for and creates the database objects, including
OS/390 database bufferpools, storage groups, databases, and tablespaces.
administrator (dba)
4 Edits the tbspaces.sql and tbspaces.ctl templates provided by
Siebel Systems to reflect the local database.
install_siebel.ksh
validate_objects.ksh
imprep.ksh
6 Does one of the following:
8 Executes generate_ddl.ksh.
11 Reviews error log for any errors, fixes any found, reruns, and reverifies.
DB2 UDB for OS/390 dba 12 If parameters were not set up in install_siebel.ksh to
automatically create database objects on DB2 UDB for OS/390, copies
generated sql file to the MVS system, and executes it, using a version
control tool, if appropriate, or by other site-specific tools, such as SPUFI.
Siebel system administrator 13 Executes the validate_objects.ksh script, which validates the
existence of the created objects on the target database and produces a
report.
14 Reviews the resulting report for any errors, fixes any found, and
reverifies.
15 Executes imprep.ksh, which imports the repository.
16 Reviews the resulting error log for any errors. If the script fails, uses
Siebel Tools to delete the created repository, fixes the error, and reruns
imprep.ksh.
Pre-Installation Tasks 12
Before installing the Siebel Database server, you must complete the following tasks:
Obtain the services of a qualified database administrator who will assist you
during your installation.
Complete all the steps in the appropriate chapters of Part 1, “Installing Central
Dispatch and the Siebel Gateway Server,” and Part 2, “Installing the Siebel
Server,” to install at least one Siebel Server.
Install DB2 Connect to enable connection with DB2 UDB for OS/390 from the
Windows NT or UNIX client. The installation of DB2 Connect is described in
Part 2, “Installing the Siebel Server.”
Alternatively, if you want to transfer the sql files created by the Siebel
installation scripts to the mainframe to execute them there, using ftp rather
than ODBC, make sure that your system has TCP/IP installed.
Make sure that DB2 UDB for OS/390 is properly configured, as documented in
Chapter 11, “Configuring the DB2 UDB for OS/390 Database Server.”
Make sure that you have installed and enabled IBM’s Workload Manager (WLM)
on S/390. WLM supports the use of stored procedures and improves system
performance.
Allocate and configure disk space and storage groups appropriate to your
installation requirements and DB2 UDB for OS/390, described in this chapter.
If you have not already done so, make a photocopy of the Deployment Planning
Worksheet, located in Appendix A, and fill out the appropriate page with the
following:
DB2 UDB for OS/390 Database Alias. This is the DB2 UDB for OS/390 database
alias that you created when installing the DB2 Connect software.
System Administrator User Name and Password. DB2 UDB for OS/390 requires
that you assign a user name and password to the system administrator for
security.
Group for SSE and for SSEEIM Users. For security and access control of your
Siebel database server, Siebel Systems recommends that you assign a security
group, using RACF (Resource Access Control Facility) or another security
control system, for all Siebel users, and an additional security group for EIM
users.
Make a photocopy of the DB2 UDB for OS/390 Installation Worksheet, located
in Appendix B, “DB2 UDB for OS/390 Tablespace and
Table Group Configuration Worksheet.” Fill out the values in the right-most
column as appropriate to your site before editing one of the sample tables group
configuration files provided by Siebel as a template for mirroring your local
database; the edited file will also be used later as a parameter of a sql file.
In addition, perform the following tasks, discussed in this section of Chapter 12,
before executing the Database Server installation scripts:
Complete the steps described earlier in Chapter 7, “Installing the Siebel Server
Under Windows NT” or in Chapter 8, “Installing the Siebel Server Under UNIX,”
with the following exceptions. You must have a Siebel Server already installed on
this application server.
2 Read the Welcome screen and click Next to continue with the setup program.
The Setup Type screen appears.
Compact. This setup option will install a minimum subset of all components.
Custom. This setup option lets you customize your installation by choosing
the specific database platform scripts you want to install.
The Setup Status screen appears and shows the progress of database script
installation.
When the installer finishes installing the required files, the Event Log appears.
4 Review the results of the installation in the Event Log screen, and then click
Next.
2 Log onto the application server using the Siebel service owner account recorded
in the photocopy you made of Appendix A, “Deployment Planning Worksheet.”
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
Also verify that the appropriate RDBMS environment variables have been set.
For information on what these are, consult your RDBMS vendor’s
documentation.
where:
NOTE: The volume label for the CD-ROM is seaunix6xx, and may not be
required, depending on how you access the CD-ROM.
If you need to make changes to the package selection, enter N at the prompt and
make the necessary changes; otherwise, enter Y at the prompt to proceed with
the installation.
The Database Server software installer will copy the necessary files to disk and
exit when it has completed the installation.
Review the directory structure created by the Database Server installation. The
directory structure is located under the directory specified during the installation.
bin
files
db2390
enu
ctiproc
files. Contains sample file attachments. These should be copied to the File System.
See “Post-Installation Task” on page 12-36.
db2390. Contains the scripts, a rich-text file containing a list of acceptable errors for
review against error logs generated when running the scripts, sql commands, and
sample sql files for the DB2 UDB for OS/390 server.
ctiproc. Contains sample source code and JCL (Job Control Language) for
building the CTI (Computer Telephony Integration) stored procedures for
inbound call routing.
Before installing Siebel on DB2 UDB for OS/390, the Security Administrator must
create security privileges for database administration, installation, and end-use. For
instructions on setting up Siebel security privileges, and Siebel tableowner and
administrator accounts, see the Siebel Applications Administration Guide.
The Siebel Server installation program installs a utility called ODBCSQL.exe in the
\SiebSrvr_Home directory. Siebel Systems recommends that you use this utility to
test your ODBC data source after database server installation. This utility is also
particularly useful in troubleshooting post-installation connectivity problems that
may stem from the ODBC layer of your installation.
where SIEBEL_DATASOURCE_NAME is the data source name for which you would like
to test connectivity, for example:
siebel_srvr_enterprise_name
2 Type:
login SADMIN/password;
3 Type:
select APP_VER, COMMENTS from TABLE_OWNER .S_APP_VER;
The foregoing commands should result in the display of the application version and
any comments. The display should also indicate whether or not connectivity
through the ODBC layer was set up correctly. Error messages at this point indicate
that problems exist downstream from the ODBC layer to the database or problems
in the user/password combination or SSEROLE privileges for that user.
Installation Tasks 12
To install the Siebel Database server, installation activities may be shared between
the Siebel Administrator and the DB2 UDB for OS/390 database administrator.
Complete these steps in sequence:
Before the Siebel System Administrator can edit and execute the database creation
scripts, the DB2/390 database administrator, as defined in the “Creating Security
Privileges” on page 12-10, must activate or create the following database objects:
Bufferpools
Storage groups
Databases
Tablespaces (Siebel supplies a script to automate this.)
To accomplish this, database administrators must first create the appropriate logins
and passwords (as explained in “Creating Tableowner and Administrator Accounts”
on page 12-10), which will, in turn, allow them to create storage groups,
bufferpools, and databases, and to grant privileges for each of these.
Activating Bufferpools
The database administrator (or system programmer) must generate ddl to create
space for a minimum of one bufferpool to be activated for each individual page size
in the database.
To create bufferpools
1 Activate a minimum of three bufferpools for the Siebel objects. (See default
bufferpool names in Table 12-3 on page 12-14.)
2 Select and rename the activated bufferpools (whose default names appear in
Table 12-3 on page 12-14) as required for your enterprise.
3 If you changed the default bufferpool names in Step 2 on page 12-13, modify the
Siebel-supplied tbspaces.sql or smalltbs.sql files, as appropriate. (These
files are described later under “Creating Tablespaces” on page 12-15.)
NOTE: You will also need to rename the bufferpools in the subsequently used
table group configuration files (tbspaces.ctl or smalltbs.ctl)
correspondingly.
Bufferpool Name
The database administrator creates storage groups using the utilities customary at
the site.
Creating Databases
The sample installation configuration files provided by Siebel require 10 databases
for Siebel tables and indexes. Each database in the sample files contains about 200
tables. You may optionally create an eleventh for temporary tables.
The database names in the sample tablespace (.sql) and table group configuration
(.ctl) files are XXXXX001-XXXXX010.
Creating Tablespaces
Two sample sql files exist in the /db2390 installation subdirectory for the purpose
of creating tablespaces:
To create tablespaces
1 Change the bufferpool names(BP1, BP16K1, BP32K1) and tablespace storage
group names and parameters (UUUUUUUU) in the appropriate tablespace .ctl
and .sql files to match your installation.
For more information on how to substitute these values, see Appendix B, “DB2
UDB for OS/390 Tablespace and Table Group Configuration Worksheet,” since it
also contains examples of the values in the tbspaces.sql and smalltbs.sql
files.
Point ODBC to the DB2 UDB for OS/390 host and enter the following
odbcsql commands:
Some groups use the same tablespace definition for the 4-KB tablespace and 16-KB
tablespace to force all tables in the group into one 16-KB tablespace.
Several groups also only have one tablespace. With these exceptions and a couple
of groups with one table each, every other group shares the same 16-KB tablespace,
since very few tables exist that require it.
After you have allocated sufficient space for Siebel in the target environment, and
created storage groups, databases, and tablespaces, you may use one of the sample
table group configuration files as a template to define storage parameters for
database objects you require in your target database.
You will find and edit these Siebel files, using Windows Notepad, vi, or another
text editor, in the /db2390 installation subdirectory:
smalltbs.ctl. For small test and development systems; uses 10 databases and only
20 distinct tablespaces.
The sample table group configuration files contain dummy database, tablespace,
and bufferpool names, and index storage parameters to make it easy to perform
string replacements and configure the files for a real environment.
These tables are divided into groups in the Siebel repository. Tables that may
become very large will, for example, have their own group, with their own
tablespace.
NOTE: For every group name in your local database repository, there should be a
matching section in the table group configuration file.
When you have edited the template file, save it to the same /db2390 directory
where generate_ddl.ksh file resides.
The sample files contain a section for each table group, as described above, and
follow the format illustrated in Appendix B, “DB2 UDB for OS/390 Tablespace and
Table Group Configuration Worksheet.”
Note that no bufferpools have been assigned to indexes in the sample files. (Their
definitions, as well as the definitions for tables are contained in the file ddl.ctl.)
To specify a bufferpool in which to place indexes, add the following to the index
stogroup argument in tbspaces.ctl:
where: bufferpool name = whatever name you want to give your bufferpool.
index stogroup = using stogroup SSSSSSSS priqty 720 secqty 720 define
yes close no pctfree 30 bufferpool BUFFERPOOLNAME.
NOTE: When you specify a bufferpool for an index stogroup name, that bufferpool
will apply only to indexes of the tables that fall in that particular table group.
After the storage groups, databases, bufferpools, and tablespaces have been
created, the database administrator executes the file generate_ddl.ksh.This file
generates the ddl (sieb_schema.sql) that creates the Siebel tables and indexes.
The definitions for tables and indexes are contained a file (ddl.ctl).
The objects in the file are compared with the physical schema of the empty target
database, and a list of statements is generated that the database administrator uses
later when installing Siebel for the first time to create the target database.
Note the following guidelines when editing all Siebel database server files:
To comment out a line, use the pound sign (#), rather than REM.
Use the forward slash (/), rather than the backslash, as a separator in the
directory paths for both Windows NT and UNIX. For example:
C:/sea6xx/dbsrvr for NT
Follow the syntax examples and instructions in the .ksh script files closely. They
indicate, for example, where quotes must be included around values and the
proper case for parameter values.
If the enterprise requires ddl files to be processed through a version control tool,
the administrator should set the DO_DDL flag to N.
The file fetches the storage parameters defined earlier in the file tbspaces.ctl (or
smalltbs.ctl), and creates a file called sieb_schema.sql.
The editable parameters are defined at the top of the file, and are described in
Table 12-4.
SRC_TBLO=CHANGE_ME The Siebel Database tableowner. This is the account that will own the
Siebel objects.
MERGE_FLG=CHANGE_ME Database merge flag. When set, Siebel compares the definitions of
tables and indexes from the definition file to those in the physical
database, and updates the physical tables and indexes appropriately.
Setting the Merge Flag to Match the Mode
Fresh installations:
N=Do not compare table schemas. This setting would most commonly
be used for fresh installations.
Note that if the MODE parameter above equals Install, the
MERGE_FLG must equal N.
Migrating EAI repository customizations from development to
production:
Y=Merge EAI development repository customizations with the
production EAI repository.
Migrating customizations from development to production:
Y=Compare table schemas, creating a list of deltas. This setting would
most commonly be used for migrations from development to
production or for upgrades when only the delta information is required.
Caution: If your environment requires generation of ddl for all
tables and indexes, set the MERGE_FLG parameter to N.
Note: If the MODE parameter above equals Non-Install,
MERGE_FLG must equal Y.
TBSPACE_FILE=tbspaces.ctl Name of the file from which tablespace storage parameters are
retrieved.
Change the name of this file, if necessary, to match the name you saved
it with when you used either of the Siebel templates tbspaces.ctl
or smalltbs.ctl.
If the DO_DDL flag is set to N, the generate_ddl.ksh script runs for approximately
one minute. The script creates the file sieb_schema.sql in the
/db2390 installation subdirectory.
If the DO_DDL flag is set to Y, the script runs about 120 minutes, depending on the
load on the database server, and creates the Siebel tables and indexes in the target
database. In this case, the file sieb_schema.sql is not generated.
The database administrator can also use odbcsql on the client machine to execute
the sieb_schema.sql file against the DB2 for OS/390 database to create tables and
indexes.
Because execution of sieb_schema.sql. takes about two hours, you may prefer to
break up segments of information in the file at strategic points into separate files
that you can execute, verify, correct, and rerun in less time.
Make sure that each file contains ddl statements for a manageable number of
tables and their associated indexes.
2 Using a text editor, insert a commit statement at the end of each file segment in
the following form:
CR/LF
COMMIT;
CR/LF
The log files may include certain errors that are expected and benign. Compare any
error messages you find to the sample error messages in the errors.rtf file, which
is located in the same directory. (If a log file is not listed in the errors.rtf file,
then there are no acceptable error messages for that log file.) No further action is
required if the log files contain errors listed in the errors.rtf file.
NOTE: Possible errors include setting the DO_DDL flag, MERGE_FLG flag, or other file
parameters incorrectly, entering incorrect values earlier into the tbspaces.ctl file,
and insufficient disk space.
If you find errors that are not listed in the errors.rtf file, correct the condition
that caused the errors, and then re-run generate_ddl.ksh.
Do not review error numbers alone, since these may have changed following
installation of a new driver version. Instead, compare the actual error descriptions
to find out which are acceptable errors for this platform.
The Siebel system administrator now executes the database server installation script
install_siebel.ksh to perform the following tasks on DB2 UDB for OS/390:
When Siebel system administrators edit install_siebel.ksh, they can set the
DO_DDL flag (Table 12-5 on page 12-25) to Y to automatically execute the ddl
against DB2 UDB for OS/390 and to create views there.
If the enterprise requires files to be processed through a version control tool, the
administrator should set the flag to N.
ODBC=CHANGE_ME ODBC data source to access the database. The data source
is created automatically by the Siebel Server installation,
using the format SiebSrvr_EnterpriseServerName.
The default is CHANGE_ME and must be modified or your
installation will fail.
To find out the ODBC data source name for the Siebel
Server, do the following:
Under Windows NT, navigate to the Control Panel and
choose ODBC Data Sources System DSN.
Under UNIX, navigate to SIEBEL_ROOT/sys and
open the file .odbc.ini.
Look for a DSN with the naming convention
SiebSrvr_EnterpriseServerName.
DB_LANG=Unspecified Names the language used by the database, such as enu for
U.S. English. Use all lowercase letters. See your database
server installation for other valid entries.
If any are incorrect, enter N to terminate the script and modify the variables.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
If the DO_DDL flag was set to N to enable processing through version control, the
Siebel administrator transfers the ddl to the DB2 UDB for OS/390 database
administrator, who creates these database objects locally.
When executed, this script generates the 390_objects.txt file, which lists all the
views and procedures by NAME and CREATOR.
Review this report to make sure that the created objects illustrated in Table 12-7
exist.
If any are incorrect, enter N to terminate the script and modify the variables.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
Finally, the Siebel system administrator must execute the imprep.ksh script to load
the Siebel repository into the Siebel database. This utility loads a new Siebel
repository containing the version 6.x Siebel application objects into the repository
tables in the Database Server.
Regardless of how many Siebel eBusiness Applications you are using (for example,
Siebel Sales, Siebel Service, Siebel Marketing), you will run the imprep.ksh script
only once.
SRC_TBLO=CHANGE_ME The Siebel Database tableowner. This is the account that will
own the Siebel objects.
ODBC=CHANGE_ME ODBC data source to access the database. The data source is
created automatically by the Siebel Server installation, using
the format SiebSrvr_EnterpriseServerName. The
default is CHANGE_ME and must be modified or your
installation will fail.
To find out the ODBC data source name for the Siebel Server:
Under Windows NT, navigate to the Control Panel and
choose ODBC Data Sources System DSN.
Under UNIX, navigate to SIEBEL_ROOT/sys and open
the file .odbc.ini.
Look for a DSN with the naming convention
SiebSrvr_EnterpriseServerName.
REPOS_NAME=“Siebel Repository” Name to be given to the Siebel repository after import. This
should not be changed.
DB_LANG=Unspecified Names the language used by the database, such as enu for
U.S. English. Use all lowercase letters. See your database
server installation for other valid entries.
2 To start the install script, enter ./imprep.ksh in the Korn shell window.
The imprep.ksh script first prompts you to review the parameter settings.
If any are incorrect, enter N to terminate the script and modify the variables.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
The imprep.ksh script will prompt you to review the parameter settings.
Caution: If imprep.ksh fails, you may use Siebel Tools to delete the
repository; then rerun the script.
Post-Installation Task 12
Perform the following task after you complete your installation of the Siebel
Database Server:
Specific files needed to run the Siebel File System, such as correspondence
templates and Siebel Marketing files, are provided with the Siebel Database Server
software. A subdirectory called files is created automatically when you install the
Siebel Database Server.
You must populate the File System directory with these file attachments after
installing the Database Server, and before running the Siebel client.
This chapter assumes that you perform your development on DB2 UDB at mid-tier
on a machine running the Windows NT, AIX, HP-UX, or Solaris operating systems.
Siebel developer 1 Customizes Siebel for business requirements in the site development
environment.
DB2 UDB for 5 Updates the tbspaces.ctl parameter file, edited earlier for installation, to
OS/390 database reflect the storage for any new object created, such as tables or indexes.
administrator (DBA)
Siebel system 6 Changes repository name in target database from the default (Siebel
administrator Repository).
7 Modifies parameters in the dev2prod.ksh script.
13 Checks the log file generated for any errors, fixes them, and reruns, if needed.
16 Checks the log file generated for any errors, fixes them, and reruns, if needed.
17 Creates or copies records in the production database required for the newly
developed application, such as the List of Values, created in the development
environment.
Pre-Migration Tasks 13
You should have already read Chapter 9, “Configuring the DB2 UDB for UNIX and
Windows NT,” and Chapter 10, “Installing the Siebel Database Server with DB2
UDB for UNIX and Windows NT.”
Complete the following task before migrating your development data to your user
acceptance testing area on DB2 UDB for OS/390:
The migration of Siebel to the OS/390 environment begins with your customization
of Siebel within your development environment. This customization includes:
Changing the Siebel eBusiness views, business objects, applets, and tables
Adding new columns to existing tables
Migration Tasks 13
“Validating the Target Database Against the Source Repository” on page 13-18
A Siebel system administrator must verify that no database objects created in the
development environment violate the size limitations imposed by the OS/390
production environment.
Table name
Column name
Index name and size
After reviewing the report, fix any objects that exceed the maximum length for
DB2 UDB for OS/390—18 characters for table names, index names, and column
names.
Note the following guidelines when editing all Siebel database server files:
To comment out a line, use the pound sign (#) rather than REM.
Use the forward slash (/), rather than the backslash, as a separator in the
directory paths for both Windows NT and UNIX. For example:
C:/sea6xx/dbsrvr for NT
Follow the syntax examples and instructions in the .ksh script files closely. They
indicate, for example, where quotes must be included around values and the
proper case for parameter values.
These parameters are defined at the top of the file, and are described in Table 13-2.
If any are incorrect, enter N to terminate the script and modify the variables.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
Correct any object size violations you find and rerun the
validate_obj_names.ksh script to verify that all objects now meet the target
system requirements.
The report may include some Siebel tables, columns, and indexes. Disregard Siebel-
created or Siebel-provided objects in this report. Any customized objects appearing
in the report should be within the DB2 size limitations.
The Siebel System Administrator now migrates the new Siebel tables, indexes, and
repository changes created in the development environment to the target DB2
database by editing and executing the dev2prod.ksh script, producing the
following results:
These parameters are defined at the top of the file, and are described in Table 13-3.
TGT_ODBC=CHANGE_ME Target database: ODBC data source name for DB2 for OS/390
database.
Note: You must create a new ODBC data source name for the
target database.
The script dev2prod.ksh runs for approximately 45 minutes. Before executing the
script, make sure that you have edited its parameters according to the instructions
described earlier under “Editing the Migration Script” on page 13-10.
3 To start the install script, enter ./dev2prod.ksh in the Korn shell window.
The dev2prod.ksh script first prompts you to review the parameter settings.
If any are incorrect, enter N to terminate the script and modify the variables.
2 Make sure that you have set the parameters in the dev2prod.ksh file properly
for your system.
3 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
The dev2prod.ksh script will prompt you to review the parameter settings.
After the storage groups, databases, bufferpools, and tablespaces have been
created, the database administrator executes the file generate_ddl.ksh against
the production database. This file generates the ddl (sieb_schema.sql) that
creates the Siebel tables and indexes.
If the enterprise requires files to be processed through a version control tool, the
administrator should set the DO_DDL flag to N.
The file fetches the storage parameters as modified for migration by the DBA in the
file tbspaces.ctl (or smalltbs.ctl).
The script also fetches the schema definitions from the schema.ddl file produced
by dev2prod.ksh in the previous task.
This script produces the file sieb_schema.sql, containing the ddl statements for
Siebel tables and columns, if the DO_DDL flag is set to N.If DO_DDL is set to Y,
sieb_schema.sql is not produced and tables and indexes are created in the target
database.
The editable parameters are defined at the top of the file, and are described in
Table 13-4.
SRC_TBLO=CHANGE_ME The Siebel Database tableowner. This is the account that will own the
Siebel objects.
MERGE_FLG=CHANGE_ME Database merge flag. When set, Siebel compares the definitions of
tables and indexes from the definition file to those in the physical
database, and updates the physical tables and indexes appropriately.
Setting the Merge Flag to Match the Mode
Fresh installations:
N=Do not compare table schemas. This setting would most commonly
be used for fresh installations.
Note that if the MODE parameter above equals Install, the
MERGE_FLG must equal N.
Migrating EAI repository customizations from development to
production:
Y=Merge EAI development repository customizations with the
production EAI repository.
Migrating customizations from development to production:
Y=Compare table schemas, creating a list of deltas. This setting would
most commonly be used for migrations from development to
production or for upgrades when only the delta information is required.
Caution: If your environment requires generation of ddl for all
tables and indexes, set the MERGE_FLG parameter to N.
Note: If the MODE parameter above equals Non-Install,
MERGE_FLG must equal Y.
TBSPACE_FILE=tbspaces.ctl Name of the file from which tablespace storage parameters are
retrieved.
Change the name of this file, if necessary, to match the name you saved
it with when you used either of the Siebel templates tbspaces.ctl
or smalltbs.ctl.
If the DO_DDL flag is set to N, the generate_ddl.ksh script runs for about one
minute. The script creates the file sieb_schema.sql in the /db2390 installation
subdirectory.
If the DO_DDL flag is set to Y, the runtime of the script depends on the number of
objects being created or modified. In this case, the file sieb_schema.sql is not
generated.
The Siebel system administrator must validate the target DB2 database against the
DB2 source repository that was imported into the target database. The Siebel
administrator accomplishes this by editing and executing the script
dev2prod_validate_rep.ksh against the target database. This script checks for
discrepancies between the repository and the physical database, creating a log of
any discrepancies found. It then updates the version number on the repository of
the target database.
If any are incorrect, enter N to terminate the script and modify the variables.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt, enter ksh to
invoke a Korn shell.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
The report may include some Siebel tables, columns, and indexes. Disregard Siebel
created/provided objects in this report. Any customized objects appearing in this
report should be reviewed.
Post-Migration Task 13
After you have successfully migrated your source database to your target
environment, you must create or copy records for any new applications you created
in your development environment. Such records might include:
Messages. Any message table entries you created for your applications.
This chapter is written for database administrators who will set up the Oracle
database.
“Database Administration” on page 14-10 details tasks involved before and after
installing the Siebel database server scripts on an Oracle database.
One of the most important factors to determine about your database is its overall
size. In your planning, you will need to allocate space for system storage, rollback
or temporary storage space, log files, and other system files required by Oracle, as
well as space for Siebel data and indexes. If you allocate too little space for your
system, performance will be affected and, in extreme cases, the system itself may
be halted. If you allocate too much, you will waste space.
The space needed by Oracle will vary primarily based on the total number and types
of users supported. Siebel Systems recommends that you consult the
documentation provided by Oracle for more information on these requirements.
The space required for Siebel data and indexes will vary depending on what Siebel
functionality you will implement and the amount and nature of data supporting that
functionality. At a minimum, Siebel version 6.x requires that you size your Oracle
database at from 400 to 600 MB. This range will vary, based on the default storage
space your database administrator sets up for tablespaces.
The process for making accurate database size calculations is a complex one
involving many variables. The following guidelines will assist you in the process:
Determine the total number and types of users of Siebel eBusiness (for example,
500 sales representatives and 75 sales managers).
Determine the Siebel functionality that you will implement and the entities
required to support them. Typically, the largest entities are:
Accounts
Activities
Contacts
Forecasts
Opportunities
Service Requests
Estimate the average number of entities per user (for example, 100 accounts per
sales representative) and calculate an estimated total number of records per
entity for your total user base.
Using standard sizing procedures for your specific database, and the Siebel Data
Model Reference, calculate the average record size per entity and multiply by the
total number of records. Typically, these entities span multiple physical tables,
all of which must be included in the row size calculation. This will determine
the estimated data size for the largest entities.
You must add extra space for the storage of other Siebel data. A rough guideline
for this additional amount would be one-half the storage required for these key
entities.
Regardless of the RDBMS you implement and your chosen disk arrangement, be
certain that you properly distribute the following types of database objects:
S_ACCNT_POSTN S_OPTY
S_ADDR_ORG S_OPTY_POSTN
S_CONTACT S_POSTN_CON
S_DOCK_TXN_LOG S_POSTN_RPT_REL
S_EMPLOYEE S_SRV_REQ
S_EVT_ACT S_OPTY
S_ORG_EXT
Even if space is at a premium, you must separate the indexes whose names end with
_P1 from the tables on which they are created, because they are heavily used in
outer join operations.
If you will make extensive use of the Enterprise Integration Manager (EIM), you
may want to put the interface tables (names ending in _IF) on different devices
from the Siebel base tables, as both are accessed simultaneously during EIM
operations.
This section contains guidelines for obtaining optimum performance from an Oracle
database. Refer to your Oracle technical documentation for additional information.
The init.ora file contains parameters that control the operation of the Oracle
database. The settings of these parameters have a major impact on the performance
of Siebel applications.
NOTE: Use the following settings only as guidelines for your initial configuration.
Your final settings will vary based on the server hardware configuration, the
number of users, and the type of workload.
In the init.ora file, Oracle provides default parameter values for small, medium,
and large database configurations. Unless the configuration parameters are
specified in the following settings, set them to the large database values. Refer to
Oracle documentation for detailed descriptions of each of the parameters and their
effects on database performance and system resource utilization.
OPTIMIZER_MODE. Your Siebel application provides better response time using the
rule-based optimizer rather than the cost-based optimizer. The cost-based optimizer
often does not have enough information to make correct decisions regarding search
plans, which can result in less efficient queries and updates. The cost-based
optimizer also requires frequent updates to the database statistics.
USE_ISM. This value may be set to FALSE by the Oracle installer. On some platforms,
Oracle recommends that you set the USE_ISM value to FALSE to avoid software
anomalies. If the version of Oracle you are using does not have these anomalies, the
recommended setting for your Siebel application is TRUE. Refer to Oracle World
Wide Support for specific information regarding this parameter on your database
platform.
SESSIONS. Certain Siebel operations require multiple connections. If you change this
parameter, make sure it is set to a number greater than 1.
To improve performance on your production system, you can create at least two
tablespaces: one for indexes and one for data. In order to distribute objects that you
anticipate to be large or points of contention, you can create additional separate
tablespaces (preferably on separate disk devices). You can also override the default
tablespace storage parameters to reflect the actual amount of data in your tables. Be
sure that the Siebel tableowner account is granted the privilege to create tables and
indexes in the tablespaces you create.
Database Administration 14
Several database administration tasks are required both before and after installing
your Siebel software.
Before you install Siebel database scripts for the Oracle RDBMS, review the
following database administration steps.
The Oracle default of 10 KB extents has an adverse effect on the response time
of queries with sorts. The INITIAL and NEXT EXTENT parameters for your
temporary tablespace should be set to a multiple of the init.ora parameter
SORT_AREA_SIZE, plus the size of one database block for header information.
This setting will guarantee that operations that use space in the temporary table
are able to efficiently allocate space.
2 Estimate the best distribution of tables and indexes across disks to optimize I/O.
Try to put indexes for a given table on a different disk from the table data.
Set the initial extent to a very small size (the minimum is one database block)
so that unused tables and indexes do not consume large amounts of space.
Set the default next extent for your data and index tablespaces to a minimum
of 100 KB.
NOTE: The Siebel software will automatically alter the storage parameters for
certain objects.
Create a single, much larger rollback segment for Siebel Server components,
such as Enterprise Integration Manager (EIM).
The Siebel Server components can point directly to this rollback segment
when performing long-running queries.
Rollback segments typically support high I/O rates, so this configuration will
improve system performance measurably.
After your Siebel installation is up and running, monitor the following areas on a
regular basis:
Insertion rates on tables. You will probably want to set the INI_TRANS value for
tables with high insertion rates to a value higher than 1; a typical setting is 4.
This parameter determines how many simultaneous inserts can occur on the
database blocks that store data for those tables and, therefore, can affect
performance in an intensive data-entry environment.
SGA cache hits. Determine whether SGA parameters need to be adjusted for your
system.
The extents used by each object. A large number of extents on a table or index
creates response time degradation for transactions that access the table or index.
Siebel tables that are subject to frequent INSERT and DELETE operations. This
transaction mixture can cause some databases to become fragmented over time.
You should monitor the space utilization and fragmentation of these tables and
perform regular database maintenance procedures as recommended by your
database vendor. The following list contains the names of the tables you should
monitor.
S_DOCK_TXN_LOG
S_DOCK_TXN_LOGT
S_DOCK_TXN_SET
S_DOCK_TXN_SETT
S_DOCK_INST
S_DOCK_INIT_ITEM
Rollback segments. This will guarantee that enough segments are available and
that they are the optimum size for common operations.
You have now configured your database properly, and can proceed to installing the
Siebel Database Server.
This chapter is written for system administrators who will install the Siebel
Database Server.
To install the Siebel Database Server, you will first install the database scripts on a
Windows NT or UNIX Siebel Server. Then you will run the database scripts to create
the following in your Siebel Database Server:
Pre-Installation Tasks 15
Before installing the Siebel Database Server, you must complete the following tasks:
The Oracle SQL*Net Connect String. You will need this to connect to your
Oracle database.
The Tableowner Account User Name and Password. Oracle requires that you
assign a user name and password to any database tables you create. Prior to
installing the Database Server, you will edit the grantusr.sql script and
enter this information. SIEBEL is the default Tableowner Account user name
and password for Siebel applications.
The Siebel Data Tablespace. The name of the tablespace on the Oracle server
where the Siebel data tables are stored.
The Siebel Index Tablespace. The name of the tablespace on the Oracle server
where the Siebel indexes are stored.
Complete all the steps in the appropriate chapters of Part 1, “Installing Central
Dispatch and the Siebel Gateway Server,” and Part 2, “Installing the Siebel
Server,” to install at least one Siebel Server.
NOTE: When starting the Siebel Database Server installation or upgrade scripts, be
sure to enter Y after reviewing the parameters at the beginning of the script.
Pressing ENTER alone causes the script to quit with a syntax error. If this occurs,
restart the script.
Complete the steps below to complete the Database Server installation scripts on
one computer. You must have a Siebel Server already installed on this computer.
2 Read the Welcome screen and click Next to continue with the setup program.
The Setup Type screen appears.
Compact. This setup option will install a minimum subset of all components.
Custom. This setup option lets you customize your installation by choosing
the specific database platform scripts you want to install.
The Setup Status screen appears and shows the progress of database script
installation.
When the installer finishes installing the required files, the Event Log appears.
4 Review the results of the installation in the Event Log screen, and then click
Next.
2 Log onto the application server using the Siebel service owner account recorded
in your photocopy of Appendix A, “Deployment Planning Worksheet.”
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
Also verify that the appropriate RDBMS environment variables have been set.
For information on what these are, consult your RDBMS vendor’s
documentation.
where:
NOTE: The volume label for the CD-ROM is seaunix6xx; it may not be required,
depending on how you access the CD-ROM.
If you need to make changes to the package selection, enter N at the prompt and
make the necessary changes; otherwise, enter Y at the prompt to proceed with
the installation.
The Database Server software installer will copy the necessary files to disk and
exit when it has completed the installation.
Review the directory structure created by the Database Server installation. The
directory structure is located under the directory specified during the installation.
bin
files
oracle
enu
files. Contains sample file attachments. These should be copied to the File System.
See “Populating the Siebel File System” on page 15-21.
The Database Server installation script creates the Siebel program folder.
You must execute the grantusr.sql script against your database server to create
the Siebel tableowner and Siebel administrator database accounts.
The grantusr.sql script must be run before installing the Siebel Database Server.
This script is located in the appropriate subdirectory for your database platform.
Your database administrator should review and run this script, which performs the
following functions:
Creates a Siebel tableowner account that “owns” all the database objects for
your Siebel application.
Creates a role (sse_role) with create session privileges.
The default user name and password for the logon are listed in the grantusr.sql
script. If you want another logon, edit the grantusr.sql script and change all the
references to your preferred name.
NOTE: If the user SADMIN already exists on your system, this script will modify its
password.
NOTE: You must specify the full path to the dbsrvr directory.
The script prompts you for the default tablespace in which your Siebel objects
are to be created.
If you would like to override the default storage parameters, such as the tablespaces
in which specific tables or indexes are created, edit the ddl.ctl file located in the
dbsrvr\oracle directory.
For each Siebel table, you can specify a tablespace by using the Space parameter.
In the following example, the tablespace for the table S_APP_VIEW is set to DATA1.
As provided by Siebel, the .ctl file does not set storage parameters for the objects
it creates, so they will default to the parameters of the tablespaces in which they are
created.
As shown in the example below, you can use the Space parameter to set storage
parameters for specific tables.
[Object 219]
Type = Table
Name = S_APP_VIEW
Column 1 = ROW_IDVARCHAR(15)NOTNULL
Column 2 = CREATEDTIMESTAMPNOTNULL DEFAULT %NOW%
Column 3 = CREATED_BYVARCHAR(15)NOTNULL
Column 4 = LAST UPDTIMESTAMP NOTNULL DEFAULT %NOW%
Column 5 = LAST_UPD_BYVARCHAR(15)NOTNULL
Column 6 = DCKING_NUMNUMERIC(22,7)DEFAULT 0
Column 7 = MODIFICATION_NUMNUMERIC(10,0)NOTNULL DEFAULT 0
Column 8 = CONFLICT_IDVARCHAR(15)NOTNULL DEFAULT ‘0’
Column 9 = NAMEVARCHAR(50)NOTNULL
Column10 = DESC_TEXTVARCHAR(255)
Column11 = LOCAL_ACCESS_FLGCHAR(1)
Space = data1
The Siebel Server installation program installs a utility called ODBCSQL.exe in the
\siebsrvr\bin directory. Siebel Systems recommends that you use this utility to
test your ODBC data source after database server installation. This utility is also
particularly useful in troubleshooting post-installation connectivity problems that
may stem from the ODBC layer of your installation.
where:
SIEBEL_DATASOURCE_NAME = the data source name for which you would like
to test connectivity, for example:
siebel_srvr_enterprise_name
2 Type:
login SADMIN/password;
3 Type:
select APP_VER, COMMENTS from TABLE_OWNER .S_APP_VER;
The previous commands should result in the display of the application version and
any comments. The display should also indicate whether or not connectivity
through the ODBC layer was set up correctly. Error messages at this point indicate
that problems exist downstream from the ODBC layer to the database, or that
problems exist in the user/password combination or SSE_ROLE privileges for that
user.
You must complete two steps to install the Siebel Database Server:
The Siebel Database Server installation script is called install.ksh, and is located
in the Oracle subdirectory. It performs the following tasks:
Note the following guidelines when editing all Siebel Database Server scripts:
To comment out a line, use the pound sign (#), not REM.
The forward slash (/), rather than the backslash, is used as a separator in
directory paths for both Windows NT and UNIX. For example:
C:/sea6xx/dbsrvr
Follow the syntax examples and instructions in the .ksh files closely. They
indicate, for example, where quotes must be included around values and the
proper case for parameter values.
Edit the install.ksh script, using Windows Notepad or another text editor, to set
the correct parameters for your installation before running the script. These
parameters are defined at the top of the install.ksh file, and are described in
Table 15-1.
Make sure you update items that default to CHANGE_ME or unspecified. These
default entries will not work if left unchanged.
ODBC=CHANGE_ME ODBC data source to access the database. The data source is
created automatically by the Siebel Server installation, using
the format SiebSrvr_EnterpriseServerName. The
default is CHANGE_ME and must be modified or your
installation will fail.
To find out the ODBC data source name for the Siebel Server,
do the following:
Under Windows NT, navigate to the Control Panel and
choose ODBC Data Sources System DSN.
Under UNIX, navigate to SIEBEL_ROOT/sys and open
the file .odbc.ini.
Look for a DSN with the naming convention
SiebSrvr_EnterpriseServerName.
DATABASE_PLATFORM=CHANGE_ME Oracle.
DB_LANG=CHANGE_ME Names the language used by the database, such as enu for
U.S. English. See the install.ksh file for other valid
entries.
SIEBEL_HOME= c:\change_me\siebrvr Full path of the Siebel Server installation directory. This is
set to the SIEBEL_ROOT directory.
This script will run for approximately 45 minutes. Before running the script, make
certain that you have edited the parameters in the install.ksh file according to
the instructions in the previous section, “Editing the Database Installation Script”
on page 15-11.
2 In the Korn shell window, type install.ksh and press ENTER to start the
install script.
The install.ksh script first prompts you to review the parameter settings.
If any are incorrect, type N and press ENTER to terminate the script and
modify the variables.
NOTE: When starting the Siebel Database Server installation or upgrade scripts,
be sure to type Y, and then press ENTER, once you have reviewed the parameters
at the beginning of the script. Pressing ENTER alone will cause the script to exit
with a syntax error. If this occurs, restart the script.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt type ksh and
press ENTER to invoke a Korn shell.
3 Enter . ./siebenv.sh.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
4 Navigate to the siebsrvr home directory, and enter install.ksh to start the
install script.
The install.ksh script will prompt you to review the parameter settings.
NOTE: When starting the Siebel Database Server installation or upgrade scripts,
be sure to enter Y after you have reviewed the parameters at the beginning of the
script. Pressing ENTER alone will cause the script to exit with a syntax error. If
this occurs, restart the script.
The Database installation script creates several log files in the Oracle directory. The
log files may include certain errors that are expected and benign. Compare any error
messages found in the log files to the sample error messages in the errors.rtf file,
which is located in the same directory. (If a log file is not listed in the errors.rtf
file, there are no acceptable error messages for that log file.) No further action is
required if the log files contain errors listed in the errors.rtf file.
NOTE: Only one of each type of error occurring in a particular log file appears in the
errors.rtf file.
If you find errors that are not listed in the errors.rtf file, correct the condition that
caused the errors, and then re-run install.ksh to complete the installation.
Do not review error numbers alone since these may have changed following
installation of a new driver version. Instead, compare the actual error descriptions
to find out which are acceptable errors for this platform.
Finally, you must next execute the imprep.ksh script to load the Siebel repository
into the Siebel database. This utility loads a new Siebel repository containing the
version 6.x Siebel applications objects into the repository tables in the Database
Server.
Regardless of how many Siebel eBusiness Applications you are using (for example,
Siebel Sales, Siebel Service, Siebel Marketing), you will run the imprep.ksh script
only once.
To avoid certain types of errors after executing the imprep.ksh script, make sure
either to provide only one large rollback segment online in your Oracle database, or
to set the SIEBEL_ROLLBACK_SEG parameter in the siebenv.bat file.
ODBC=CHANGE_ME ODBC data source to access the database. The data source is created
automatically by the Siebel Server installation, using the format
SiebSrvr_EnterpriseServerName. The default is CHANGE_ME and
must be modified or your installation will fail.
To find out the ODBC data source name for the Siebel Server, do the
following:
Under Windows NT, navigate to the Control Panel and choose ODBC
Data Sources System DSN.
Under UNIX, navigate to SIEBEL_ROOT/sys and open the file
.odbc.ini.
Look for a DSN with the naming convention
SiebSrvr_EnterpriseServerName.
DBSRVR_ROOT= Root directory of the Database Server installation. (Under UNIX, this will be
C:/CHANGE_ME/DBSRVR the same as the SIEBEL_ROOT directory.)
DATABASE_PLATFORM= Oracle.
CHANGE_ME
DB_LANG=CHANGE_ME Names the language used by the database, such as enu for U.S. English. See
the install.ksh file for other valid entries.
SIEBEL_HOME=CHANGE_ME Full path of the Siebel Server installation directory. This is set to the
SIEBEL_ROOT directory.
3 In the Korn shell window, enter . ./siebenv.sh to start the install script.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
NOTE: When starting the Siebel Database Server installation or upgrade scripts,
be sure to enter Y after you have reviewed the parameters at the beginning of the
script. Pressing ENTER alone will cause the script to exit with a syntax error. If
this occurs, restart the script.
2 Navigate to the siebsrvr home directory, and at the UNIX prompt enter ksh to
invoke a Korn shell.
3 Enter . ./siebenv.sh.
NOTE: Make sure there is a space between the first period and ./siebenv.sh.
The imprep.ksh script will prompt you to review the parameter settings.
NOTE: You may need to do this twice to close the shell window.
NOTE: Only one of each type of error occurring in a particular log file appears in the
errors.rtf file.
If you find errors that are not listed in the errors.rtf file, correct the condition
that caused the errors, and then re-run imprep.ksh to complete the installation.
Do not review error numbers alone since these may have changed following
installation of a new driver version. Instead, compare the actual error descriptions
to find out which are acceptable errors for this platform.
Post-Installation Task 15
Perform the following task after you complete your installation of the Siebel
Database Server:
Specific files needed to run the Siebel File System, such as correspondence
templates and Siebel Marketing files, are provided with the Siebel Database Server
software. A subdirectory called files is created automatically when you install the
Siebel Database Server.
You must populate the File System directory with these file attachments after
installing the Database Server, and before running the Siebel client.
This chapter describes the steps involved in installing and configuring the Siebel
CORBA Object Manager under Windows NT.
The Siebel CORBA Object Manager is an alternative object manager; it allows you
to access the Siebel BusObjects, through a supported CORBA ORB. The standard
Application Manager is installed automatically when you install your Siebel Servers.
The CORBA Object Manager is not installed as part of the standard Siebel Server
installation. If you plan to use the CORBA interfaces, you must install the CORBA
Object Manager on each application server on which you plan to operate it.
The CORBA Object Manager does not require the creation of a Siebel Enterprise
Server, or installation of a Gateway Server or Siebel Server. Rather, the CORBA
Object Manager operates outside the Siebel Server infrastructure. Task instantiation
and management, load balancing, and other capabilities that are usually provided
by the Siebel Enterprise Server infrastructure are instead provided by the CORBA
object request broker (ORB).
Pre-Installation Tasks 16
Perform the following tasks before running the Siebel CORBA Object Manager
installation programs:
Be sure that all application servers onto which the Siebel CORBA Object
Manager will be installed meet the hardware and software requirements
described in Siebel System Requirements and Supported Platforms.
The CORBA Object Manager may be installed on an application server that also
supports the Siebel Enterprise Server components, although for best
performance and scalability you must install the CORBA Object Manager onto a
dedicated application server.
You must configure your database connectivity software to connect to the Siebel
CORBA Object Manager:
Microsoft SQL Server. No configuration is required once the Microsoft SQL Server
ODBC driver specified in Siebel System Requirements and Supported Platforms
has been installed on each application server. Siebel automatically creates an
ODBC data source using connectivity parameters that you will specify during
installation of the Siebel Server.
Oracle. Verify that the Oracle SQL*Net database connectivity software is installed
onto each application server, according to the Oracle documentation. See Siebel
System Requirements and Supported Platforms for database connectivity
software requirements.
Prior to installing the Siebel Server and Siebel Enterprise Server, you must use
the Oracle SQL*Net Easy Configuration utility to define a database alias with the
proper connection information for your Siebel Database Server, if you have not
done so already. Record the connect string in Appendix A, “Deployment
Planning Worksheet.” You will specify this connect string when installing the
Siebel Server.
DB2 UDB for Windows NT, UNIX, and DB2 UDB for OS/390. Define a database alias
with the proper connection information for your database. This alias will be the
connect string used when installing the Siebel Server.
Use either the DB2 Client Configuration Assistant or the Command Line
Processor to define your database alias. For more information, see the IBM DB2
Universal Database Quick Beginnings manual for NT or IBM DB2 Universal
Database Command Reference.
You must verify network connectivity between the application server and the Siebel
Database Server.
Oracle. Use the tnsping utility and SQL*Net database alias from a Command
Prompt window to make sure that you can connect to the database, using the
network connect string that you defined in the previous step.
DB2 UDB on Windows NT, UNIX, and OS/390. Use a DB2 Command Window to
make sure that you can connect to your database.
where:
If your connection is valid, you should see a message that looks like the
following:
NOTE: You can also use the DB2 Command Center GUI tool to do this.
The Siebel Server installation will create its own ODBC data source.
Complete the following steps to install the CORBA Object Manager on each
Windows NT application server.
3 Select the setup type you want from the options in the Setup Type screen.
The options are:
Typical. This setup option will install all the CORBA Object Manager
components: these components are Siebel executable files, sample clients
and IDL, help files, and object configuration templates (the siebel.srf file).
This option is recommended for most installations.
Compact. This option is identical to the Typical Setup option for the CORBA
Object Manager installation.
4 Choose the database server you will be using, and then click Next.
The Database Identification screen appears.
Database Alias. Type the database alias catalogued for your DB2 database.
Tableowner. Type the name of the database account that owns your Siebel
tables and indexes.
DB2 UDB for OS/390:
Database Alias. Type the database alias cataloged for your DB2 UDB for
OS/390 database.
Tableowner. Type the name of the database account that owns your Siebel
tables and indexes.
SQL ID. Type the SQL ID that defines your RACF (or other security control
product) group. This grants ordinary user privileges for most users. The
default is SSEROLE.
Oracle Enterprise Server:
Database Alias. Type the SQL*Net connect string for your Siebel Server
database.
Tableowner. Type the name of the database account that owns the Siebel
tables.
Microsoft SQL Server:
Server Name. Type the network name or IP address of the database server on
which you are installing the Siebel database.
Database Name. Type the name of the SQL Server database where the Siebel
tables and indexes will reside.
6 Type the name of the program folder that will contain your Siebel icons in the
Program Folder field, or choose from one of the displayed selections.
Post-Installation Tasks 16
Before starting the CORBA Object Manager, perform the following tasks:
Make sure that your customized Siebel repository file (the .srf file) has been
copied from the location where you modified it to the \objects subdirectory of
each CORBA Object Manager installation.
Make sure that the supported ORB software you will use with the CORBA Object
Manager has been installed on each application server.
Set up the ORB to broker requests between clients and the CORBA Object
Manager, following instructions under “Setting Up the Object Request Broker in
Persistent and Shared Server Modes” on page 16-10. For more information on
the ORB environment, refer to the documentation for the ORB product you are
using.
Follow the instructions under “Registering Multiple Object Managers for Better
Performance” on page 16-14 (optional).
You must set up the Object Request Broker (ORB) to broker requests between clients
and the CORBA Object Manager. How you do this depends on which ORB product
you are using and how you want the system to operate. Two scenarios are described
in this section: setting up an ORB in persistent mode and setting up an ORB in
shared-server mode.
Persistent Mode
In persistent mode, the CORBA Object Manager is always running and available for
the ORB. You must set up either the Visibroker ORB or the Orbix ORB for persistent
mode, but not both. Choose the correct set of procedures for your deployment from
the following.
2 To start the CORBA Object Manager from the Windows Start menu, choose
Programs Siebel CORBA Object Manager 6.x Visibroker ORB.
If you cannot find the CORBA Object Manager in your Windows Start menu,
look for ssomvisi.exe in the bin subdirectory of the CORBA Object Manager
installation. You can open the My Computer window or Windows NT Explorer,
navigate to this directory, and double-click the program to run the CORBA Object
Manager.
Refer to the documentation provided with your Orbix software for more
information on the orbixd command.
2 Before starting the CORBA Object Manager for the first time on an application
server, register it with the Orbix daemon by executing the following command
from a Windows NT Command Prompt window:
putit SiebelCorbaServer -persistent
The putit program is located in the bin directory of your Orbix installation.
3 To start the CORBA Object Manager, from the Windows Start menu, choose
Programs Siebel CORBA Object Manager 6.x Orbix ORB.
2 Start an object activation daemon (OAD) on each application server that will be
running the CORBA Object Manager.
The term daemon is borrowed from UNIX and denotes here a program that runs
in the background without user intervention.
where:
SIEBEL_ROOT = the full path of your SIEBEL_ROOT (or Siebel CORBA Object
Manager) directory.
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomvisi.
datasource = the name of the Data Source defined in the .cfg file; the default
is Server. Make sure that the .cfg file includes a section that defines that data
source, and that it lists that data source in the [DataSources] section of the
.cfg.
language = the three-letter code for the language in which to operate: enu for
U.S. English.
The term daemon is borrowed from UNIX and denotes here a program that runs
in the background without user intervention. Refer to the documentation
provided with your Orbix software for more information on the orbixd.exe
command.
where:
SIEBEL_ROOT = the full path of your SIEBEL_ROOT (or Siebel CORBA Object
Manager) directory.
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomvisi.
datasource = the name of the Data Source defined in the .cfg file; the default
is Server.
language = the three-letter code for the language in which to operate: enu for
U.S. English.
The putit executable is located in the bin directory of your Orbix installation.
This completes configuration and installation of the Siebel CORBA Object Manager
under Windows NT.
Persistent Mode
Users should note that Visibroker does not use the Visibroker Activation Daemon
(OAD) in persistent mode.
2 Execute the following command for multiple instances of the CORBA Object
Manager:
SIEBEL_ROOT\bin\ssomvisi.exe /n SiebelObjectFactory
/c config_file /d datasource /l language
where:
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomvisi.
datasource = the name of the Data Source defined in the .cfg file; the default
is Server.
language = the three-letter code for the language in which to operate, such as
enu for U.S. English.
ssomorbx.exe /n SiebelCorbaServer
/c SIEBEL_ROOT\bin\config_file/d Server /l language
ssomorbx.exe /n SiebelCorbaServer2
/c SIEBEL_ROOT\bin\config_file /d Server /l language
where:
config_file =the full path and name of the Object Manager configuration file;
the default is siebel.cfg, located in the same directory as ssomorbx.exe.
language =the three-letter code for the language in which to operate, such as
enu for U.S. English.
2 Start an OAD on each application server that will run the CORBA Object
Manager.
where:
config_file =the full path and name of the Object Manager configuration file;
the default is siebel.cfg, located in the same directory as ssomorbx.exe.
datasource =the name of the Data Source defined in the .cfg file; the default
is Server.
language =the three-letter code for the language in which to operate, such as
enu for U.S. English.
where:
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomorbx.exe.
language = the three-letter code for the language in which to operate, such as
enu for U.S. English.
This chapter describes the steps involved in installing and configuring the Siebel
CORBA Object Manager under UNIX.
The Siebel CORBA Object Manager is an alternative object manager; it allows you
to access objects in your Siebel applications using the industry-standard CORBA
procedures. The standard Application Object Manager is installed automatically
when you install your Siebel Servers.
The CORBA Object Manager is not installed as part of the standard Siebel Server
installation. If you plan to access your Siebel Servers through CORBA, you must
install the CORBA Object Manager on each application server on which you plan to
operate it.
The CORBA Object Manager does not require that you create a Siebel Enterprise
Server, or install a Gateway Server or Siebel Server. The CORBA Object Manager
operates outside the Siebel Server infrastructure, with task instantiation and
management, load balancing, and other capabilities that are usually provided by the
Siebel Enterprise Server infrastructure instead being provided by the CORBA object
request broker (ORB).
Connectivity between the client and CORBA Object Manager is provided by third-
party ORB software. Refer to Siebel System Requirements and Supported Platforms
for information on the specific ORB products and versions supported by Siebel
eBusiness Applications. The CORBA Object Manager installation provides support
for all supported ORBs.
Pre-Installation Tasks 17
Perform the following tasks before running the Siebel CORBA Object Manager
installation programs:
Be sure that all application servers onto which the Siebel CORBA Object
Manager will be installed meet the hardware and software requirements detailed
in Siebel System Requirements and Supported Platforms.
The CORBA Object Manager may be installed on an application server that also
supports the Siebel Enterprise Server components, although for best
performance and scalability you must install the CORBA Object Manager onto a
dedicated application server.
The CORBA Object Manager installation program uses /siebel as the default
installation directory on supported UNIX platforms. Whether you are installing
CORBA Object Manager into a pre-existing installation directory or performing a
fresh installation, make sure that you do not install CORBA into the same
directory as the Siebel Server.
NOTE: Siebel Systems recommends that you use a directory naming convention
that identifies the component and version being installed.
To install the CORBA Object Manager in a separate directory, make sure that the
environment variable SIEBEL_ROOT either is not set or is set to the new
directory.
Oracle. Verify that the Oracle SQL*Net database connectivity software is installed
onto each application server, according to the Oracle documentation. See the Siebel
System Requirements and Supported Platforms for database connectivity software
requirements.
Prior to installing the Siebel Server and Siebel Enterprise Server, you must use the
Oracle SQL*Net Easy Configuration utility to define a database alias with the proper
connection information for your Siebel Database Server, if you have not done so
already. Record the connect string in Appendix A, “Deployment Planning
Worksheet.” You will specify this connect string when installing the Siebel Server.
DB2 UDB for Windows NT, UNIX, and DB2 UDB for OS/390. Define a database alias with
the proper connection information for your database. This alias will be the connect
string used when you are installing the Siebel Server.
Use the DB2 Command Line Processor (CLP) to define your database alias. For more
information, see the IBM DB2 Universal Database Command Reference.
You must verify network connectivity between the Siebel Server and the Siebel
Database Server.
For TCP/IP networks, use the ping utility to verify network connectivity to the
Database and Gateway servers.
DB2 UDB for Windows NT, UNIX, and DB2 UDB for OS/390. Use the Command
Line Processor (CLP) to make sure that you can connect to your database.
From the CLP, open a UNIX shell and enter:
DB2 connect to database alias user user ID using password
where:
If your connection is valid, you should see a message that looks like the
following:
NOTE: The Siebel Server installation will create its own data source.
First prompt type. This type of prompt asks you to type the desired value for a
given parameter; the default value is shown in square brackets [ ].
For example,
Second prompt type. This type of prompt displays a list of one or more parameter
values and asks you whether you want to modify any of them:
You will see a series of prompts that allow you to change the value. For
example:
Complete the following steps to install the CORBA Object Manager on each UNIX
application server, using the information you recorded in your copy of Appendix A,
“Deployment Planning Worksheet.”
2 Log in to the application server using the Siebel service owner account and enter
./ksh to run a Korn shell.
where:
NOTE: The volume label for the CD-ROM is seaunix6xx; it may not be required,
depending on how you access the CD-ROM.
The first prompt will ask for the directory in which the CORBA Object Manager
should be installed.
7 If you are creating a new installation directory, the next prompt will ask you to
confirm that this directory should be created:
If the directory is correct, press ENTER to accept the default value of Y and
continue with the installation.
The next prompt lists the packages available for selection, as shown below:
After you have confirmed the packages to install, the Siebel CORBA Object Manager
installation script will install the files on disk. It will then bring up a series of
prompts, as detailed below, to allow you to configure the CORBA Object Manager.
Answer the prompts, using the information you recorded in Appendix A,
“Deployment Planning Worksheet.”
2 Enter the appropriate connect string or database alias used to connect to your
RDBMS:
IBM DB2 UDB for UNIX or Windows. Enter the database alias for your Siebel
Server Database, for example, db2345.
DB2 UDB for OS/390. Enter the database alias cataloged for your DB2 UDB for
OS/390 database, for example, db2390.
Oracle. Enter the SQL*Net connect string for your Siebel Server Database.
If your database is DB2 for OS/390, proceed to Step 4. For all others, proceed to
Step 5.
4 Enter the SQL ID that defines your RACF (or other security control product)
group. This grants ordinary user privileges for most users. The default is
SSEROLE.
You will next be prompted to review all the parameters set in the previous steps.
If any are incorrect, enter N to return to the previous prompts so that you can
re-enter the information.
The CORBA Object Manager will exit after the installation has finished.
For convenience, when managing and configuring the Siebel CORBA Object
Manager, you may want to set the Siebel environment variable SIEBEL_ROOT and
add the SIEBEL_ROOT/bin directory to your search path.
During installation of the CORBA Object Manager, the script files siebenv.csh (for
C shells) and siebenv.sh (for Bourne and Korn shells) are automatically created
in the SIEBEL_ROOT directory. When executed, these shell scripts set the
environment variables.
You may also want to add a call to the appropriate script to the logon file of all Siebel
administrator UNIX accounts, so that these variables are set automatically
whenever a Siebel administrator logs on.
Post-Installation Tasks 17
Before starting the CORBA Object Manager, perform the following tasks:
Make sure that your customized Siebel repository file (the .srf file) has been
copied to the \objects subdirectory of each CORBA Object Manager
installation.
Make sure that the supported ORB software you will use with the Object
Manager has been installed on each application server.
Set up the ORB to broker requests between clients and the CORBA Object
Manager, following instructions under “Setting Up the Object Request Broker in
Persistent and Shared Server Modes” on page 17-11. For more information on
the ORB environment, refer to the documentation for the ORB product you are
using.
Follow the instructions under “Registering Multiple Object Managers for Better
Performance” on page 17-17 (optional).
You must set up the object request broker (ORB) to broker requests between clients
and the CORBA Object Manager. How you do this depends on which ORB product
you are using and how you want the system to operate.
Two scenarios are described in this section: setting up an ORB in persistent mode
and setting up an ORB in shared-server mode.
Persistent Mode
In persistent mode, the CORBA Object Manager is always running and available for
the ORB.
PATH=${PATH}:visibroker_installdir/bin
export PATH
3 Execute the ssomvisi program using the following arguments to start the
CORBA Object Manager:
ssomvisi /n SiebelObjectFactory /c config_file /d datasource /l language
where:
config_file is the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomvisi.
datasource = the name of the Data Source defined in the .cfg file; the
default is Server. Make sure that the .cfg file includes a section that defines
that data source, and that it lists that data source in the [DataSources]
section of the .cfg.
language =the three-letter code for the language in which to operate, for
example enu for U.S. English.
NOTE: The ssomvisi program is located in the bin subdirectory of your Siebel
CORBA Object Manager installation. You can invoke it by specifying the full path
(for example, SIEBEL_ROOT/bin/ssomvisi); however, setting the Siebel
environment variables automatically adds this directory to your search path so
that you do not need to specify the full path.
For example, the Visibroker ORB system requires that a C++ compiler on
its approved list be installed. If you have no C++ compiler, or an
unapproved C++ compiler, Visibroker will quit with an error message.
Are you using a certified version of the Visibroker ORB for Siebel eBusiness
Applications version 6.x?
2 Before starting the CORBA Object Manager for the first time on an application
server, execute the following command from a UNIX Korn shell to register the
CORBA Object Manager with the Orbix ORB:
putit SiebelCorbaServer -persistent
The putit executable is located in the bin directory of your Orbix installation.
3 Execute the ssomorbx program using the following arguments to start the
CORBA Object Manager:
ssomorbx /n SiebelCorbaServer /c config_file /d datasource /l language
where:
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomorbx.
datasource = the name of the data source defined in the .cfg file; the
default is Server.
language = the three-letter code for the language in which to operate: enu
for U.S. English.
NOTE: The ssomorbx program is located in the bin subdirectory of your Siebel
CORBA Object Manager installation. You can invoke it by specifying the full path
(for example, SIEBEL_ROOT/bin/ssomorbx); however, setting the Siebel
environment variables automatically adds the bin directory to your search path
so that you do not need to specify the full path.
Execute the following commands on each application server that will be running
the CORBA Object Manager to start an object activation daemon (OAD).
The Visibroker oad program is located in the bin directory of your Visibroker
installation.
No parameters are needed for running oad—just enter oad at the command
prompt and press ENTER. However, you need to define either the environment
variable VBROKER_ADM or the environment variable VBROKER_IMPL_PATH before
executing oad. VBROKER_ADM defines the path to the directory where the files in
the implementation repository are stored. The default is
visibroker_installation_dir/impl_dir. Use VBROKER_IMPL_PATH to
overwrite the default VBROKER_ADM path.
Refer to the documentation of the ORB product you are using for more
information on VBROKER_ADM and VBROKER_IMPL_PATH.
NOTE: Make sure the oad program is already started successfully before running
the oadutil utility. If it is not, the oadutil utility will quit with the following
error message:
3 Navigate to the bin subdirectory of your Visibroker installation and run the
osagent program.
NOTE: This process does not need to be running on only one application server.
However, it provides resiliency if started on more than one server.
4 To register an object, execute the Visibroker oadutil reg command from a shell
window on each application server, as follows:
oadutil reg -i SiebelAppFactory -o SiebelObjectFactory -cpp\
SIEBEL_ROOT/bin/ssomvisi -p shared -a /n -a SiebelObjectFactory\
-a /c -a SIEBEL_ROOT/bin/config_file -a /d -a datasource -a /l -a language
where:
SIEBEL_ROOT = the full path of your SIEBEL_ROOT (or Siebel CORBA Object
Manager) directory.
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomvisi.
datasource = the name of the data source defined in the .cfg file; the default
is Server.
language = the three-letter code for the language in which to operate: enu for
U.S. English.
5 To manually unregister an object that has been previously registered, execute the
oadutil unreg command from a shell window on each application server, as
follows:
oadutil unreg -i SiebelAppFactory -o SiebelObjectFactory
Refer to the documentation provided with your Orbix software for more
information on the orbixd command.
2 Execute the following command once on each application server to register the
CORBA Object Manager. The putit program is located in the bin directory of
your Orbix installation, and should be run from a Korn shell window.
putit SiebelCorbaServer -shared SIEBEL_ROOT/bin/ssomorbx “/n SiebelCorbaServer\
/c config_file /d datasource /l language”
where:
SIEBEL_ROOT = the full path of your SIEBEL_ROOT (or Siebel CORBA Object
Manager) directory.
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomvisi.
datasource = the name of the data source defined in the .cfg file; the default
is Server.
language = the three-letter code for the language in which to operate, such as
enu for U.S. English.
3 To manually unregister an object that has been registered previously, execute the
rmit command from a shell window on each application server as follows:
rmit SiebelCorbaServer
Persistent Mode
To register multiple object managers, using Visibroker ORB
1 Follow Step 1 through Step 2 on page 17-11.
2 Execute the ssomvisi program using the following arguments to start the
CORBA Object Manager, for example:
ssomvisi /n SiebelObjectFactory/c config_file /d datasource /l language
Optionally, you can also make the configuration files unique and point them to
distinct Siebel Repository files (.srf); for example:
ssomvisi /n SiebelObjectFactory/c config_file _2 /d datasource /l language
where:
config_file = the full path and name of the Object Manager configuration
file; the default is siebel.cfg, located in the same directory as ssomvisi.
datasource = the name of the data source defined in the .cfg file; the default
is Server.
language = the three-letter code for the language in which to operate, such as
enu for U.S. English.
2 Follow Step 3 on page 17-13, but again give the variable SiebelCorbaServer
the unique name you gave this instance in the previous step, for example,
SiebelCorbaServer2.
and
oadutil reg -i SiebelAppFactory -o SiebelObjectFactory -cpp\
SIEBEL_ROOT/bin/ssomvisi -p shared -a /n -a SiebelObjectFactory1\
-a /c -a SIEBEL_ROOT/bin/config_file -a /d -a datasource -a /l -a language
Optionally, you can also make the configuration files unique and point them to
distinct Siebel Repository files (.srf); for example:
-a /c -a SIEBEL_ROOT/bin/config_file _2 -a /d -a datasource -a /l -a language
Chapter 20. Installing and Configuring the .COM Applications Under Windows NT
Chapter 21. Installing and Configuring the .COM Applications Under UNIX
This chapter describes the network configuration requirements for deploying Siebel
Java Thin Client, Siebel Thin Client for Windows, and Siebel HTML Thin Client,
particularly when deploying these products across firewalls.
One of the key advantages of deploying Siebel Thin Client for Windows and Siebel
Java Thin Client is that it allows users to connect to Siebel eBusiness Applications
remotely. However, enabling thin clients to connect to Siebel Servers over the
Internet and through a firewall requires specific client/server, firewall, and network
configurations described in this section.
TCP/IP. If you are using TCP/IP, you must expose the TCP port (the default port
number is 2320) of the Gateway Server through the firewall.
HTTP. If you are using HTTP, you need only expose a generic HTTP port (the
default HTTP port number is 80).
Both HTTP and TCP/IP connections to the Application Object Manager support
firewalls that perform network address translation (NAT).
NOTE: Siebel eBusiness Applications supports NAT only if Central Dispatch has been
installed for load balancing.
NOTE: See the Siebel Client Installation and Administration Guide for information
about configuring Java Thin Client. The stand-alone Thin Client for Windows does
not require configuration.
The firewall requirements are slightly different if you do not use load balancing in
your Enterprise Server network. In this environment, the Application Object
Manager only supports connections over TCP/IP. Both the Gateway Server TCP port
(default is 2320) and the TCP port on which each Object Manager listens must be
exposed through the firewall. The Object Manager port is determined by the Object
Manager configuration and can be allocated dynamically or statically.
To minimize the number of ports you must open through the firewall, Siebel
Systems recommends that you use static port allocation, and create as small a
number of Object Manager-defined components as possible.
One of the key advantages of deploying Siebel HTML Thin Clients is that it allows
users to connect to Siebel eBusiness Applications remotely. However, enabling
Siebel HTML Thin Clients to connect to Siebel Servers over the Internet and through
a firewall requires specific client/server, firewall, and network configurations
described in this section.
Figure 18-1 shows one possible network configuration for deploying Siebel HTML
Thin Client. Your actual configuration will vary depending on the firewall hardware
or software and security standards of your organization; however, the requirements
outlined here apply across all configurations and should be used as the guidelines
for your environment.
Web browser
Web application
(generated HTML pages)
External firewall
HTTP port
Web server
Siebel Web
Server Extension
Internal firewall
TCP/IP port
A shaded box
denotes an
Database HTML Thin Client
component
The Web browser uses a standard HTTP or SSL connection to the Web server.
Typically, this connection requires only that the firewall be able to pass HTTP or SSL
traffic to a single port on the Web server. These requirements are determined
entirely by your browser and Web server configurations. For more information on
supported firewall configurations in these environments, refer to the documentation
provided by the vendors of the products your enterprise uses.
These connections can usually be supported over VPNs, through firewalls that
perform network address translation, and through multiplexing proxies.
NOTE: The use of SSL does impose some overhead that can degrade performance.
For that reason, Siebel Systems recommends its use only in those portions of your
application configuration where network security is critical, such as transfers
involving login information.
The Siebel Web Server Extension, operating on the Web server, connects to the
Application Object Manager component operating within the Siebel Server. This
connection uses Siebel's application protocol, which can be compressed and can
also be encrypted when both components are deployed on Windows NT.
The supported configurations for a firewall between the Web server and Siebel
Enterprise Server vary depending on whether you are using dynamic load balancing
in the Enterprise Server.
NOTE: Siebel Systems supports network address translation (NAT) with Resonate
Central Dispatch installed. If Resonate Central Dispatch is not installed, network
address translation (NAT) is not supported.
If you are using load balancing, both HTTP and TCP/IP connections to the
Application Object Manager support firewalls that perform network address
translation. However, neither can be used with a firewall that has a multiplexing
application proxy. While the use of HTTP does create some overhead and can
degrade response times, you may prefer it for firewall configurations requiring
packet filtering or other stringent security measures.
NOTE: See Chapter 20, “Installing and Configuring the .COM Applications
Under Windows NT” or Chapter 21, “Installing and Configuring the
.COM Applications Under UNIX” for information on how to modify the
configuration files for Siebel .COM Applications.
The firewall requirements are slightly different if you do not use load balancing in
your Enterprise Server. The Object Manager connection can only use TCP/IP in this
environment. In addition to the Gateway Server TCP port (the default is 2320), the
TCP port on which each Object Manager listens must also be exposed through the
firewall.
The Object Manager port is determined by the Object Manager configuration and
can be allocated dynamically or statically. To minimize the number of ports that
must be opened through the firewall, it is recommended that you use static port
allocation and create as small a number of Object Manager-defined components as
possible.
This chapter describes the steps involved in verifying and, if required by your
deployment, editing the Siebel Thin Client for Windows files installed with and
configured by the Siebel Server.
For instructions on installing the client-side components of Siebel Thin Client for
Windows, or other Siebel Thin Clients, see the Siebel Client Installation and
Administration Guide.
Siebel Thin Client for Windows consists of client-side software that runs in one of
two modes:
Browser Mode 19
When run in this mode, Siebel Thin Client for Windows uses a startup file typically
accessed from a file or Web server to control its operation. This startup file sets a
number of operational parameters, including default appearance, connectivity, and
authorization information.
This chapter provides instructions on editing the Siebel Thin Client for Windows
Startup file, should your environment require this.
Stand-Alone Mode 19
There are no configuration tasks for the stand-alone executable version of Thin
Client for Windows. If your clients will use the stand-alone version, this completes
the information for Siebel Thin Client for Windows.
Pre-Installation Tasks 19
Complete the following pre-installation tasks on the appropriate servers before you
install and perform any reconfiguration of Siebel Thin Client for Windows required
by your deployment. These tasks consist of the following:
Before installing the Thin Client software, you must have completed the installation
of the following:
An Enterprise Server containing the Gateway Server and at least one Siebel
Server, following the instructions provided in this guide
NOTE: Siebel Systems strongly recommends that you implement the connection-
brokering capabilities of Resonate’s Central Dispatch if you will support Thin
Clients from multiple Siebel Servers. These capabilities help to guarantee high
scalability and availability for your Thin Client users. Refer to Chapter 3, “Installing
Central Dispatch Under Windows NT,” for more information on connection
brokering.
This section describes how to edit the startup files that control Siebel Thin Client
for Windows operation.
These startup files are initially installed with the Siebel Enterprise Server. After you
have edited these files, you will make them available to Siebel Thin Client for
Windows users by one or more of the methods described in “Sharing Thin Client
Startup Files” on page 19-10.
Siebel Thin Client for Windows uses one of two startup files, also called tclient
files, depending on the Web browser in which Siebel Thin Client for Windows is
executed:
The tclient.htm file is used to start Thin Client for Windows in the Internet
Explorer Web browser.
The tclient.stc file is used to start Thin Client for Windows in the Netscape
Communicator Web browser.
The parameters in these files are not set automatically during installation with the
Siebel Server. You must complete the following steps to edit the appropriate file
before you can use Siebel Thin Client for Windows.
To make sure that the Thin Client for Windows files operate correctly in your
Microsoft Internet Explorer browser, follow the steps below.
where < > (angle brackets) indicate a required parameter, and [ ] (square
brackets) indicate an optional parameter.
Note that the default values in the actual file may be different from these strings,
but the location and meaning of the values remain the same.
NOTE: You must set the encryption value to match the value of the Siebel
Application Object Manager to which the Siebel Thin Client will connect.
If you are using Resonate Central Dispatch, the Gateway Server address is
the Gateway VIP that you assigned while installing the Siebel Server
components.
If you are not using Resonate Central Dispatch, enter either the network
name or IP address of the application server on which the Gateway Server
is installed.
Make sure to precede the parameter with double quotes, as shown in Step 2
on page 19-5. The quotes will be closed in Step 2e below.
NOTE: If you will have multiple groups of Siebel Thin Client for Windows
users who will access different Application Object Manager components, you
must create multiple copies of the startup file, each with a unique name.
SCCObjMgr
SSEObjMgr
SFSObjMgr
SSVObjMgr
NOTE: You can also define your own components. See the Siebel Server
Administration Guide for information about defining and assigning
Application Object Manager services.
Make sure that you precede the parameter you add with a double quote, as
shown in Step 2 on page 19-5.
f The lang parameter specifies the language used by the Application Object
Manager component, defined by objectmanager.
g Username and Password specify the user name and password used by the
thin client to log onto the Siebel Database Server. If desired, enter a valid user
name and password that will automatically be used by all thin client users.
Each value must be enclosed by single quotes, as shown in Step 2 on
page 19-5.
If you leave these values blank, each thin client user will be prompted to
enter a login name and password at startup. Enter two single quotation
marks for each value to indicate a null value for the user name and password,
as shown here:
SiebelApplicationControl1.Login('host =
“siebel.transport.encryption.compression://
gateway_address:gateway_port/ “siebelenterprise/
objectmanager/siebelserver” lang=”ENU”,'','')
h The cti parameter enables Siebel CTI (Computer Telephony Integration) for
the thin client.
Set cti to “TRUE” if you are using Siebel CTI and “FALSE” if you are not
using Siebel CTI. If you are not using CTI, you can also omit the cti
parameter.
The WIDTH and HEIGHT attributes specify the width and height of the screen
area in which Thin Client for Windows will be displayed.
In the example above, the width and height are specified as a percentage of the
Web browser display area, or 100% by 100%. A setting of 100% by 100% causes
the thin client to occupy the entire Web browser display area.
You can also specify this area in pixels, for example, 800 by 600 pixels, by
entering a number for each value.
To ensure that the Thin Client for Windows files operate correctly in your Netscape
browser, follow the steps below.
The structure of the tclient.stc file is shown here. Pay close attention to
single and double quotes. Improper placement of these quotes will cause your
application not to launch:
Login('host = “siebel[.transport][.encryption][.compression]://
<gatewayaddress>[:port]/<siebelenterprise>/<objectmanager>/
< siebelserver> [cti= “TRUE”] [lang = “ENU”]', '[username]', '[password]')
where < > (angle brackets) indicate a required parameter, and [ ] (square
brackets) indicate an optional parameter.
2 The values for the tclient.stc file are exactly as described for the Internet
Explorer startup file in the previous section; refer to that section, “To edit the
Internet Explorer client startup file” on page 19-5, for a description of the values.
NOTE: The default values in the actual file may be different from these strings,
but the locations and meanings of the values remain the same.
3 Make sure that each string of values is enclosed in double quotes, as shown in
the example in Step 1 for the parameters cti and lang.
After you have edited one or both of the Thin Client for Windows startup files, they
must be made available to the Thin Client users. For ease of maintenance, Siebel
Systems strongly recommends that you share the startup files from a network
shared drive or a Web server, or from both. This allows you to easily distribute
changes in the event that your Siebel Enterprise Server configuration is altered.
You may elect to use a combination of these two methods to serve different groups
of users. Whichever sharing mechanisms you elect to deploy, distribute the Thin
Client startup files now and make sure that the Thin Client machines have read
access to them.
The Siebel .COM Applications are a family of Web-based applications that you
access through a standard Web browser.
The .COM Applications use several server-side components to service these browser
clients:
The Application Object Manager, operating within the Siebel Enterprise Server.
This chapter provides instructions for installing and configuring the .COM
Application server components. For information on supported hardware, operating
system platforms, Web browsers, and Web servers, refer to Siebel System
Requirements and Supported Platforms.
Pre-Installation Tasks 20
Before installing the .COM Applications, you must have already installed the
following components:
Recommended Configuration
Each configuration involves trade-offs. However, Siebel Systems strongly
recommends a distributed node deployment for the following reasons:
Less resource contention. Distributing the Web server and the Siebel Server (with
Application Object Manager) on different machines eliminates contention for
CPU and other server resources. However, to take advantage of the performance
improvement, you must have a high-speed network connection between the two
machines.
Load balancing. A single Web server can distribute the load of multiple user
requests among multiple Application Object Manager instances, using the
connection-brokering capabilities of the Siebel Gateway Server.
Greater flexibility with firewalls. Putting the Web components of the HTML Thin
Client on a different machine from the Siebel Enterprise Server and Application
Object Manager lets you deploy your Web server outside the firewall while
keeping the Enterprise Server components behind the firewall.
You must have installed and configured the Siebel Gateway Server and an Enterprise
Server containing at least one Siebel Server before installing the Siebel .COM
Applications. Complete the steps in Chapter 7, “Installing the Siebel Server Under
Windows NT,” to install and configure the Enterprise Server entities, following the
configuration chosen in the previous step.
If you are installing the Application Object Manager and Web components of an
HTML Thin Client application on the same machine, use separate installation
directories to avoid file permission problems at installation time.
Make sure that the application server that will support the .COM applications meets
all the hardware and software platform requirements documented in Siebel System
Requirements and Supported Platforms.
Before installing the .COM Applications, install, configure, and start the supported
Web server on the machine where your .COM Applications will reside. Follow the
instructions from the vendor to complete these tasks.
NOTE: For the best performance and scalability, Siebel Systems recommends that the
Web server reside on a separate machine from the Siebel Enterprise Server.
The .COM Application files will be installed on the same application server as the
Web server. The installation program sets up the Siebel directory structures, copies
required files and components to the target disk, and configures the host
environment.
5 Specify the destination directory for the Web Engine and .COM Applications.
The default directory is C:\sea6xx\SWEApp.
6 Indicate whether or not you use the Central Dispatch load balancing feature.
If you use Central Dispatch, choose Yes.
NOTE: Siebel Systems strongly recommends the use of load balancing in your
enterprise network.
If you do not use Central Dispatch, type the network name or IP address
of the Gateway Server host.
Enterprise Server Alias. The name of the Siebel Enterprise Server on which the
Application Object Manager components are running.
If you are not using Central Dispatch, the Siebel Server Information screen
appears. Proceed to Step 8.
8 On the Siebel Server Information screen, type the logical name of your Siebel
Server (not the machine name).
9 On the Connection Protocol screen, choose the type of protocol Siebel should
use to connect to the Application Object Manager:
TCP IP
HTTP
None
MSCRYPTO
NOTE: The Application Object Managers must be configured with the same
encryption setting.
11 Choose the method of data compression you prefer when the .COM Applications
communicate to the Applications Object Managers:
None
ZLIB
PKWARE
This screen requires an employee login ID and password that any employee may
access through an electronic billboard or similar medium.
The login ID should be a valid client login for the application you are installing,
regardless of the authentication method your company uses.
The ID used should also have authorization to access the Public View.
This screen is for those who use a contact-type login ID and password.
The ID used should also have authorization to access the Public View.
14 On the Error Logging Level screen, specify the level of operational error logging
for the .COM Applications, and then click Next.
Errors only. The default setup option causes nonfatal and fatal operational
errors to be logged.
All (errors and warnings). This setup option causes all operational statistics,
information messages, warnings, and errors to be logged.
None. This setup option causes only fatal operational errors to be logged.
NOTE: For the best performance, choose Errors Only. Choose All only for
debugging.
The Setup Status bar appears. The installer now installs the Siebel .COM
Applications.
16 Click Finish.
This completes the installation of the Siebel .COM Application files.
For instructions on deploying HTML Thin Client applications, see the Siebel .COM
Applications Guide.
Post-Installation Tasks 20
Review the physical and virtual directories created during installation of the .COM
Applications on the Web server host to familiarize yourself with the locations of
files, such as the .COM Applications configuration file (eapps.cfg). The following
list shows physical directories that the installer puts in the /sea6xx directory:
/SWEApp/
bin/
language/
public/
demo
files
help
images
scripts
webtempl
Virtual directories are installed on the Web server for each .COM Application, for
example, eservice directory for the eService product.
The eappweb installer installs a single configuration file, eapps.cfg, for all the
.COM Applications by default into the \BIN subdirectory of the installation on your
Web server host.
The parameters of the configuration file are automatically set during installation
and do not normally require any manual configuration. However, should your
environment require making changes to any of the settings, just double-click the file
to launch your default text editor. You may edit it with any standard text editor such
as Windows Notepad.
If you do modify the configuration file, you must restart several Windows NT
services to make your changes take effect. See “Services You Must Restart” on
page 20-18.
For information about parameters that you may be required to set at the Application
Object Manager level on the Siebel Server, refer to the appropriate section of the
Siebel Server Administration Guide, Configuring Siebel .COM Applications, and
Siebel .COM Applications Guide. For example, if your enterprise uses eChannel,
eSales, or eService, you will need to configure LDAP for a secure connection.
You may also add selected optional parameters manually to affect the .COM
Applications as a whole. Alternatively, you may override these added parameters to
determine the performance of one or more applications by adding them to the
appropriate connect string in the applications section of the file and editing them
there.
This section of the file contains connect strings for each .COM application. Each
connect string is preceded by a bracketed heading as illustrated below:
[/xxx]
where xxx is the name of the .COM Application you want to edit.
Sample eapps.cfg
[swe]
Language = enu
Log = errors
LogDirectory = /SWEAppweb/log
SwcPort = 8197
[defaults]
AnonUserName = User1
AnonPassword = User1
AnonUserPool = 10
StatsPage = _stats.swe
[/ebriefings]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eBriefingsObjMgr/USER1
[/ebriefings_w]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eBriefingsDCObjMgr/
USER1
[/echannel]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eChannelObjMgr/USER1
[/partnerfinder]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/PartnerFinderObjMgr/
USER1
[/%HTMLSales_VIRTUALDIR%]
ConnectString = siebel.TCPIP.none.none://Shakt:2320/siebel/HTMLSalesObjMgr/Shakti
[/wpsales]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/WebphoneSalesObjMgr/
USER1
[/wpserv]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/WebphoneServiceObjMgr/
USER1
[/eai]
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eSalesObjMgr/USER1
EnableExtServiceOnly = TRUE
[/ecustomer]
AnonUserName = User1
AnonPassword = User1
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eCustomerObjMgr/USER1
[/emarketing]
AnonUserName = User1
AnonPassword = User1
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eMarketObjMgr/USER1
[/esales]
AnonUserName = User1
AnonPassword = User1
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eSalesObjMgr/USER1
[/eservice]
AnonUserName = User1
AnonPassword = User1
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eServiceObjMgr/USER1
[/etraining]
AnonUserName = User1
AnonPassword = User1
ConnectString = siebel.TCPIP.none.none://USER1:2320/siebel/eTrainingObjMgr/USER1
Optional Parameters
The following optional parameters may be manually added to the [defaults]
sections of the file, at the individual application level, or in both locations, with
exceptions for particular applications.
Enabled
A particular .COM Application (for example, /etraining) stops responding to user
requests if this flag is set to 0. The default is 1, or enabled.
SessionTimeout
The time, in seconds, from the user’s last browser request until the user’s
connection times out.
If set to 0, it will never time out. If omitted, the default value is 28800
(eight hours).
For example, if SessionTimeout is set to 28800, then the session ends 28800
seconds (eight hours) after the user’s last browser request.
HTTPPort
The HTTP port used for Web browser communications. The default setting is the
specified port of the Web server in use.
HTTPSPort
The HTTPS port used for secure Web browser connections. The default setting is
the specified port of the Web server in use.
Mandatory Parameters
These parameters already exist in the eapps.cfg file when you open it after
installation to your \bin subdirectory. You may edit them if your environment
requires it.
[swe] Section
The parameters that follow can be found in this section of the eapps.cfg file. These
parameters apply to all .COM Applications.
Language
This is the localized version you purchased for .COM Applications. For example,
enu stands for U.S. English.
Log
These are the types of log entries you selected during installation. For example, an
entry reading “errors” would mean that the log should show only fatal and non-
fatal operational errors.
LogDirectory
This is the location of the log directory, whose default location is
/SWEAppweb/log.
SwcPort
If you use IBM HTTP Server under AIX UNIX, you must reset this parameter to
provide a listening port for Siebel Web Companion. Siebel Systems recommends
resetting the port number from 8197 to 8192 since the Siebel Web Engine uses the
former; for example:
SwcPort=8192
NOTE: You do not need to reset this parameter if you do not use IBM HTTP Server.
For instructions on use of IBM HTTP Server with AIX, see Chapter 21, “Installing
and Configuring the .COM Applications Under UNIX.”
[defaults] Section
The parameters that follow apply to all .COM Applications. Any of the settings that
can be specified under [defaults] can be also specified for individual .COM
Applications (such as /esales) in the [xxx] section. If such a parameter is set for
a particular .COM Application, it overrides the value listed in [defaults].
AnonUserName
If you are accessing the application through the database, the name you use must
be an authorized user of the database. The person whose name is used should be
authorized for access to Public View.
This parameter controls the “handshake” between the Siebel Web Engine and the
Siebel Database.
AnonPassword
The password corresponding to the value entered for AnonUserName.
AnonUserPool
This parameter specifies the maximum number of anonymous user connections
from the Web server to the Application Object Manager. If the environment variable
NUMBER_OF_PROCESSORS is set, then the maximum value is multiplied by that
value.
The anonymous user pool is used during the brief initial interactions from the user
before logging in. After users log in, they have a separate connection.
The default value is 10. If you expect to have a very busy site, you may want to
increase this.
StatsPage
This is the URL (relative to the application’s virtual directory) of the page that
administrators can access to view application statistics. Statistics include the
number of active users, the number of requests, and average speed of request
processing.
Since this page is generated by Siebel Web Engine, you can view it only from a
browser. For example, if StatsPage is set to _stats.swe, and the virtual directory
for your application is Service, then to see the statistics you would enter the
following URL:
http://mysite/Service/_stats.swe
[/xxx] Section
The parameters that follow can be found in this section of the eapps.cfg file. These
parameters apply to each of the .COM Applications. As mentioned previously, any
parameter you set for a particular .COM Application overrides any opposite value
listed under [defaults].
ConnectString
A connect string exists for each .COM Application. Each connect string reflects the
individual object manager for that application and contains information you
entered during setup.
The sample connect string below contains descriptions within parentheses of the
string components.
[/echannel]
If you make any changes to a configuration file in the private directory BIN, as
opposed to those in the siebel_server/bin directory, where siebel_server is
the name of the directory where your Siebel Server resides, you must stop and
restart the following Windows NT Services:
The Siebel .COM Applications are a family of Web-based applications you access
through a standard Web browser.
The .COM Applications use several server-side components to service these browser
clients:
The Application Object Manager, operating within the Siebel Enterprise Server.
This chapter provides instructions for installing and configuring the .COM
Application server components. For information on supported hardware, operating
system platforms, Web browsers and Web servers, refer to Siebel System
Requirements and Supported Platforms.
Pre-Installation Tasks 21
Complete the following tasks before beginning running the eappweb installer.
Before installing the .COM Applications, you must have already installed the
following components:
Less resource contention. Distributing the Web server and the Siebel Server (with
Application Object Manager) on different machines eliminates contention for
CPU and other server resources. However, to take advantage of the performance
improvement, you must have a high-speed network connection between the two
machines.
Load balancing. A single Web server can distribute the load of multiple user
requests among multiple Application Object Manager instances, using the
connection-brokering capabilities of the Siebel Gateway Server.
Greater flexibility with firewalls. Putting the Web components of the HTML Thin
Client on a different machine from the Siebel Enterprise Server and Application
Object Manager allows you to deploy your Web server outside the firewall while
keeping the Enterprise Server components behind the firewall.
After installing the .COM Applications, make sure that the following steps are taken.
Run install_eappweb under an account that has access rights to modify the
iPlanet (formerly, the Netscape Enterprise) configuration files. This account is
typically the root directory.
Make sure that the account that the iPlanet httpd daemon uses has write
permissions for the /eappweb/log directory. Typically this means that you must
change the permissions for the appropriate directory.
Make sure that the account that the iPlanet httpd daemon uses has read
permissions to all files in the /eappweb/public directory. Alternatively, you
may make the public directory available to everyone by inputting the following:
chmod -R a+r /eappweb/public
Make sure that users who will be running the Web server have execution
permission for the scripts installed with the .COM Applications to enable
starting and stopping the Web server and Siebel Web Companion, and write
permission for the log file path.
You must have installed and configured the Siebel Gateway Server and an Enterprise
Server containing at least one Siebel Server before installing the Siebel .COM
Applications. Complete the steps in Chapter 8, “Installing the Siebel Server
Under UNIX,” to install and configure the Enterprise Server entities, following the
configuration chosen in the previous step.
If you are installing the Application Object Manager and Web components of an
HTML Thin Client application on the same machine, use separate installation
directories to avoid file permission problems at installation time.
Make sure that the application server that will support the .COM applications meets
all of the hardware and software platform requirements documented in Siebel
System Requirements and Supported Platforms.
For the best performance and scalability, Siebel Systems recommends that the Web
server reside on a separate machine from the Siebel Enterprise Server.
Before installing the .COM Applications, install, configure, and start the supported
Web server on the machine where your .COM Applications will reside. Follow the
instructions from the vendor to complete these tasks.
NOTE: If you are installing the IBM HTTP Server under AIX, you must also run a
server called Siebel Web Companion whenever you run the Web server. Siebel Web
Companion is installed automatically along with the .COM Applications.
Install the .COM Application files on the same machine as the Web server. The
installation program sets up the Siebel directory structures, copies required files and
components to the target disk, and configures the host environment.
where:
NOTE: The volume label for the CD-ROM is seaunix6xx; it may not be required,
depending on the way in which you access the CD-ROM.
If you have not yet specified the root directory by setting the environment
variable SIEBEL_ROOT, the installer script prompts you to enter it now.
5 To accept the displayed default value, press ENTER. Otherwise, enter the name
of the Siebel root directory.
The installer prompts you to enter the root directory of the iPlanet Web Server/
IBM HTTP Server instance on which you want to deploy the .COM Applications.
https-your_server_instance_name
If you have installed iPlanet Web Server, the Siebel installer prompts you:
7 Specify whether or not you are using Resonate Central Dispatch load balancing
software by entering Y or N, as appropriate.
8 Accept the default Gateway Server, or enter the VIP address of the one you prefer
to use.
10 Enter the name of the Siebel Enterprise Server on which the Application Object
Manager components are running if it is different from the default.
1) tcpip
2) http
12 Enter the number corresponding to the type of networking protocol the Siebel
HTML Thin Client should use to connect to the Application Object Managers.
For information about the Application Object Managers, refer to the Siebel Server
Administration Guide.
1) none
2) zlib
3) pkware
13 Enter the number corresponding to the type of encryption you want to use, if
any, for communications to the Application Object Managers.
NOTE: The Application Object Managers must be configured with the same
encryption setting.
1) errors
2) all
3) none
14 Enter the number corresponding to the level of operational error logging for the
.COM Applications, as described below.
Errors. The default setup option causes nonfatal and fatal operational errors
to be logged.
All (errors and warnings). This setup option causes all operational statistics,
information messages, warnings, and errors to be logged.
None. This setup option causes only fatal operational errors to be logged.
NOTE: For the best performance, choose 1) errors. Choose 2) all only for
debugging.
15 Enter an employee login ID and password that any employee may access
through an electronic billboard or similar medium.
The login ID should be a valid client login for the application you are installing,
regardless of the authentication method your company uses.
The ID used should also have authorization to access the Public View.
16 Enter a password to which all can have access for the login ID entered above.
The Siebel installer prompts you:
This prompt is for those who use a contact-type login ID and password.
The ID used should also have authorization to access the Public View.
20 Accept the default (Y) to install the .COM Applications in a new directory.
The Siebel installer prompts you:
[X] All
When you confirm installing the software packages now, a number of system
messages appear, indicating the status of package installation.
If your Web server is running during the installation, the installation script
prompts you to restart the Web server so that it can load the changes into the
configuration file:
22 Accept the default Y and press ENTER to restart the Web server processes, or
enter N if you want to restart them later.
If you do not restart the Web server processes at this time, you should do so
before making Siebel .COM Applications available to your users.
If you have installed IBM HTTP Server, restarting the Web server processes also
starts Siebel Web Companion, which is required to run in tandem with HTTP
Server when swcsrvr is not running.
If you decide to restart the Web server later, you will need to start Siebel Web
Companion manually. For instructions on starting and stopping Siebel Web
Companion, see “Running the IBM HTTP Server and Siebel Web Companion”
on page 21-23.
Post-Installation Tasks 21
After installing the Siebel .COM Applications, perform the following post-
installation tasks, if needed.
Review the physical and virtual directories created during installation of the .COM
Applications on the Web server host to familiarize yourself with the locations of
files, such as the .COM Applications configuration file (eapps.cfg). The following
list shows physical directories that the installer puts in the $SIEBEL_HOME directory:
/SWEApp/
bin/
language/
public/
demo
files
help
images
scripts
webtempl
Virtual directories are installed on the Web server for each .COM Application, for
example, eservice directory for the eService product.
To make sure that applications run correctly, set the environment variable
SIEBEL_OSD_LATCH to 2.5 times the number of concurrent users you anticipate. For
example, if you anticipate 1,000 concurrent users, run this command at the
command prompt:
This variable controls the maximum number of latches that can be created.
Therefore, do not set it at a significantly higher value than that recommended here.
You can put this command in your .cshrc file. If you do not do this, make sure you
run it before you start your Web server.
For instructions on deploying HTML Thin Client applications see the Siebel HTML
Thin Client Developers Reference.
The eappweb installer installs a single configuration file, eapps.cfg, for all the
.COM Applications by default into the /bin subdirectory of the installation on your
Web server host.
The eapps.cfg file contains configuration information that you entered during the
installation of the .COM Applications on the Web server, including identity and
connectivity information for the Application Object Managers, and login and
security settings.
As a result, you do not, in most cases, need to edit this file unless you are moving
server components to another machine, for which you would need to record new
information.
You may, if desirable, add selected optional parameters manually to affect the .COM
Applications as a whole. You may also override the added parameters to determine
the performance of one or more applications. This is accomplished by adding them
to the appropriate connect string in the applications section of the file and editing
them there, using any editing tool, such as vi.
If you will be running iPlanet Web Server under Solaris, be aware that the iPlanet
Server configuration file obj.conf, located within the iPlanet configuration
directory, references the file eapps.cfg, because the Siebel installer adds the
reference to obj.conf. A typical line the installer would add to obj.conf might be:
Init fn=”swe-init”config-file=”/SWEappweb/bin/eapps.cfg”
siebel-home=”/eappweb”
For information about parameters that you may be required to set at the Application
Object Manager level on the Siebel Server, refer to the appropriate section of the
Siebel Server Administration Guide, Siebel HTML Thin Client Developers Reference,
and Siebel .COM Applications Guide. For example, if your enterprise uses eChannel,
eSales, or eService, you will need to configure LDAP for a secure connection.
To make your changes take effect, you must restart several shell or UNIX shell
scripts, as described in “Shell Scripts You Must Restart” on page 21-23.
[/xxx]
where xxx is the name of the .COM Application you want to edit. xxx should
match the name of the virtual directory in iPlanet configuration file obj.conf that
is mapped to the Siebel plug-in.
Sample eapps.cfg
[swe]
Language = enu
Log = errors
LogDirectory = \SWEApp\log
SwcPort = 8197
[defaults]
AnonUserName = Shakti
AnonPassword = Shakti
AnonUserPool = 10
StatsPage = _stats.swe
[/ebriefings]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eBriefingsObjMgr/
Shakti
[/ebriefings_w]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eBriefingsDCObjMgr/
Shakti
[/echannel]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eChannelObjMgr/Shakti
[/partnerfinder]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/PartnerFinderObjMgr/
Shakti
[/%HTMLSales_VIRTUALDIR%]
ConnectString = siebel.TCPIP.none.none://Shakt:2320/siebel/HTMLSalesObjMgr/Shakti
[/wpsales]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/WebphoneSalesObjMgr/
Shakti
[/wpserv]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/
WebphoneServiceObjMgr/Shakti
[/eai]
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eSalesObjMgr/Shakti
EnableExtServiceOnly = TRUE
[/ecustomer]
AnonUserName = Shakti
AnonPassword = Shakti
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eCustomerObjMgr/
Shakti
[/emarketing]
AnonUserName = Shakti
AnonPassword = Shakti
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eMarketObjMgr/Shakti
[/esales]
AnonUserName = Shakti
AnonPassword = Shakti
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eSalesObjMgr/Shakti
[/eservice]
AnonUserName = Shakti
AnonPassword = Shakti
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eServiceObjMgr/Shakti
[/etraining]
AnonUserName = Shakti
AnonPassword = Shakti
ConnectString = siebel.TCPIP.none.none://Shakti:2320/siebel/eTrainingObjMgr/
Shakti
Optional Parameters
The following optional parameters may be manually added to the [defaults]
sections of the file, at the individual application level, or in both locations, with
exceptions for particular applications.
Enabled
A particular .COM Application (for example, /etraining) stops responding to user
requests if this flag is set to 0. The default is 1, or enabled.
SessionTimeout
The time, in seconds, from the user’s last browser request until the user’s
connection times out.
If set to 0, it will never time out. If omitted, the default value is 28800
(eight hours).
For example, if SessionTimeout is set to 28800, then the session ends 28800
seconds (eight hours) after the user’s last browser request.
HTTPPort
The HTTP port used for Web browser communications. The default setting is the
specified port of the Web server in use.
HTTPSPort
The HTTPS port used for secure Web browser connections. The default setting is
the specified port of the Web server in use.
Mandatory Parameters
These parameters already exist in the eapps.cfg file when you open it after
installation to your /bin subdirectory. You may edit them if your environment
requires it.
[swe] Section
The following parameters can be found in this section of the eapps.cfg file. These
parameters apply to all .COM Applications.
Language
This is the localized version you purchased for .COM Applications. For example,
enu stands for U.S. English.
Log
These are the types of log entries you selected during installation. For example, an
entry reading “errors” would mean that the log should show only fatal and non-
fatal operational errors.
LogDirectory
This is the location of the log directory, whose default location is
/SWEAppweb/log
SwcPort
IBM HTTP Server users may, if desirable, reset this parameter to provide a different
listening port from the default port number for Siebel Web Companion. However,
resetting this parameter is not required.
[defaults] Section
The parameters that follow apply to all .COM Applications. Any of the settings that
can be specified under [defaults] can be also specified for individual .COM
Applications (such as /esales) in the [xxx] section. If such a parameter is set for
a particular .COM Application, it overrides the value listed in [defaults].
AnonUserName
If you are accessing the application through the database, the name must be an
authorized user of the database. The person whose name is used should be
authorized for access to Public View.
This parameter controls the “handshake” between the Siebel Web Engine and the
Siebel Database.
AnonPassword
The password corresponding to the value entered for AnonUserName.
AnonUserPool
This parameter specifies the maximum number of anonymous user connections
from the Web server to the Application Object Manager. If the environment variable
NUMBER_OF_PROCESSORS is set, then the maximum value is multiplied by that
value.
The anonymous user pool is used during the brief initial interactions from the user
before logging in. After users log in, they have a separate connection.
The default value is 10. If you expect to have a very busy site, you may want to
increase this.
StatsPage
This is the URL (relative to the application’s virtual directory) of the page that
administrators can access to view application statistics. Statistics include the
number of active users, the number of requests, and the average speed of request
processing.
Since this page is generated by the Siebel Web Engine during installation, you can
view it only from a browser. For example, if StatsPage is set to _stats.swe, and
the virtual directory for your application is Service, then to see the statistics you
would enter the following URL:
http://mysite/Service/_stats.swe
[/xxx] Section
The following parameters can be found in this section of the eapps.cfg file. These
parameters apply to each of the .COM Applications. As mentioned previously, any
parameter you set for a particular .COM Application overrides any opposite value
listed under [defaults].
ConnectString
A connect string exists for each .COM Application. Each connect string reflects the
individual object manager for that application and contains information you
entered during setup.
The sample connect string below contains descriptions within parentheses of the
string components.
[/echannel]
If your system is Solaris, it is crucial that you configure the iPlanet Web Server to
accept the changes that the eappweb installer makes to the iPlanet server
configuration files after you install Siebel .COM Applications. Otherwise, changes
that you may make in future to the iPlanet Web Server configuration will overwrite
the changes made by the Siebel installation script.
To make sure that the iPlanet accepts changes made by Siebel .COM Applications
1 Navigate to the iPlanet Web Server Administration page. (Refer to the iPlanet
documentation.)
2 Click the button that shows the server instance on which the .COM Applications
were installed.
This takes you to the Server Preferences page for the instance.
3 On the upper right-hand side of the Server Preferences page, click Apply.
This displays another page with a warning message:
This message indicates that the iPlanet Web Server has accepted the changes
made to it by the eappweb installer.
After making changes to any configuration file, restart the following UNIX shell
scripts:
Siebel Web Companion is installed along with the .COM Applications on the IBM
HTTP Server. The installation of the .COM Applications also generates several
scripts for use in starting and stopping IBM HTTP Server and Siebel Web
Companion. These scripts consist of the following:
or
swcctl stop
swcsrvr SiebelHomeDirectory
In the above case, you must use the same SiebelHomeDirectory specified during
installation.
This chapter describes how to install the Siebel Report Server on the Siebel Server,
on a Microsoft IIS or a iPlanet Web Server machine, and on a dedicated Windows
client or Thin Client. For specific version information, refer to Siebel System
Requirements and Supported Platforms.
Actuate ReportCast. Provides access to Siebel Report Server from the World Wide
Web. Using ReportCast, you can access and work with reports through any Web
browser.
Actuate e.Report Designer. Lets you design and build reports using its graphical
user interface.
Siebel Report Server Access. A Siebel integration component that includes Siebel
Report executables, Siebel ReportCast templates, and other Siebel-specific
library files.
Pre-Installation Tasks 22
Before installing Actuate ReportCast, make sure that you have installed, configured,
and started either the Microsoft Internet Information Server (IIS) or the iPlanet Web
Server. Siebel Report Server supports both Web servers on Windows NT.
Install the Siebel Report Server and its associated applications in the following
order:
Server
Actuate ReportCast
Actuate e.Reporting Server
Siebel Report Server Access
Client
You should install Actuate ReportCast on the same machine as your Web server.
2 Navigate to the appropriate directory, depending on which Web server you use:
\Thirdpty\language\actuate\reportcast\netscape
or
\Thirdpty\language\actuate\reportcast\IIS
where language means that language in which you have bought your Siebel
eBusiness Application, for example, enu for U.S. English.
5 Read the license screen and accept the license conditions by clicking Yes.
The installer copies the appropriate files to your computer.
Starting Services
After setup has finished installing ReportCast on Windows NT, follow the
instructions below to start services.
To achieve the best performance, Siebel Systems recommends that you install
Actuate e.Reporting Server on a different machine from the one on which Actuate
ReportCast resides.
3 Double-click SETUP.EXE.
The Welcome screen appears.
5 Read the license screen and accept the license conditions by clicking Yes.
The Choose Destination Directory screen appears.
The installer will place the e.Reporting Server files by default in the following
directory:
C:\Actuate4\Server
6 Accept the default or use the Browse button to navigate to another directory.
To continue, click Next.
The installer prompts you to specify an account name to use to start the services.
7 Type the account name and network password that you want to use. Click
Continue.
If you have not already set up this user account with logon privileges, the
installer prompts you with the following message:
8 Click Yes.
The installer prompts you as to whether or not you want Actuate e.Reporting
Server to start automatically whenever you log on.
11 Follow the instructions described in the text file and close the file when finished.
After a number of informational screens, the Setup Complete screen appears and
prompts you as to whether you want to reboot your computer now or later.
Starting Services
After setup has finished installing Report Server, on Windows NT, follow the
instructions below to start services.
2 From the Windows NT Start menu, choose Settings Control Panel Services.
3 Start the following services:
Actuate Administration Server 4
Install Siebel Report Server Access on the same host on which you installed Actuate
e.Reporting Server to enable communication between e.Reporting Server and the
Siebel Server.
4 Specify the destination directory for the Web Engine and .COM Applications.
The default directory is C:\sea6xx\rptsrvr.
The Setup Status screen appears and the installer proceeds to install all required
files.
When Setup has installed all required files into the directory, the Event Log
screen appears.
6 Click Finish.
This concludes installation of Siebel Report Server Access.
5 Enter:
exit
If the import was successful, no message appears, but you will see a list of report
executable files that were imported.
If you are using IIS as your Web server, the directory path will be similar to
the following example:
C:\Inetpub\wwwroot\Actuate\Default
If you are using iPlanet Web Server as your Web server, the directory path
will be similar to the following example:
C:\Netscape\SuiteSpot\docs\Actuate\Default
NOTE: Only users with administrative privileges can access the ReportCast
Administration page.
NOTE: If the Confirmation page does not appear, verify that the connection to
your Web server is still active.
5 Verify that your changes took place by displaying any ReportCast page.
Actuate Administrator Desktop offers users the added capability of managing one
or more Actuate e.Reporting Servers and Report Encyclopedias, and of controlling
user privileges.
You can install Actuate Administrator Desktop in any machine on your network.
5 Read the License screen and accept its conditions by clicking Next.
The Choose Destination location screen appears.
The progress bar appears and shows the status of file installation.
7 Indicate whether you want to restart your computer now or later, and then click
Finish.
1 Insert the Siebel Windows Client CD-ROM into your CD-ROM drive.
2 Navigate to the following directory:
\Thirdpty\language\actuate\devwb
5 Read the License screen and accept its conditions by clicking Next.
6 Accept the default directory (C:\Actuate4\Devwb) or use the Browse button
to select another directory.
The progress bar appears and shows the status of file installation.
ODBC. Triggers installation of the ODBC drivers. These are needed if you want
to run any of the sample reports.
Core System. Triggers installation of all executables and data files, except for
ODBC drivers and online help.
Each entry shows the amount of disk space it takes up on your drive.
7 Clear any components that you do not want installed, and then click Next.
The progress bar appears and shows the status of file installation.
8 Indicate whether you want to restart your computer now or later, and then click
Finish.
Actuate e.Report Designer lets developers design and create reports, using its
graphical user interface.
NOTE: Installation of Actuate e.Report Designer is not required to run Siebel Report
Server.
1 Insert the Siebel Windows Client CD-ROM into your CD-ROM drive.
2 Navigate to the following directory:
\Thirdpty\language\actuate\erd
5 Read the License screen and accept its conditions by clicking Next.
6 Accept the default directory (C:\Actuate4\Erd) or use the Browse button to
select another directory.
ODBC. Triggers installation of ODBC drivers. These are needed if you want to
run any of the sample reports.
Core System. Triggers installation of all executables and data files, except for
ODBC drivers and online help.
Each entry shows the amount of disk space it takes up on your drive.
7 Clear any components that you do not want installed, and then click Next.
The progress bar appears and shows the status of file installation.
Post-Installation Tasks 22
Perform the following post-installation tasks to make Siebel Report Server available
for users and to confirm proper installation.
This section describes how to modify Siebel client files, such as Sales.cfg,
Service.cfg, and Customer.cfg, in an ActiveX Thin Client deployment on a
server, or on a dedicated client to run with the Siebel Report Server.
2 Locate the configuration (.cfg) file corresponding to the application that you
want to run with Siebel Report Server, and then double-click.
3 Using your default text editor, such as Windows Notepad, edit the following
parameters.
[Actuate Reports]
EnableReportServer = TRUE
Perform the following tasks to confirm that you have installed Siebel Report Server
correctly.
3 From the left panel of the Main Menu, choose any view.
The selected view appears.
4 From the Reports Menu in the menu bar, choose any report.
The Run or Schedule for Later dialog box appears, prompting you as to whether
you want to generate a report now or schedule it for later.
5 Indicate that you want to schedule the report for later, specify the date, time, and
frequency, and click OK.
The scheduled report appears in the view, indicating the scheduled date, time,
and other information.
If the report does not appear, check the order and location in which you installed
the Siebel Report Server components, as described earlier in this chapter.
To eliminate the potential for memory leakage, Siebel Systems strongly recommends
that the Report Server administrator edit two variables within the Windows
repository.
2 After navigating to the path described above, right-click within the Data field in
the right panel and choose New String Value.
In the Value data field, type the values shown below in Step 3.
AC_FACTORY_SERVER_RECYCLE_COUNT=100
This chapter describes how to install the Actuate e.Reporting Server and Actuate
ReportCast, which are components of Siebel Report Server, under UNIX.
Pre-Installation Task 23
Before installing Siebel Report Server, make sure that you have installed,
configured, and started the iPlanet (formerly, the Netscape Enterprise) Web Server
or IBM HTTP Server, as appropriate.
Install Siebel Report Server in the order and location given for the programs
described below.
You should install Actuate ReportCast on the same machine on which your Web
server resides.
Installation Tasks
Read and, afterwards, perform the following tasks to complete installation of
Actuate ReportCast in a UNIX environment.
For the purpose of these instructions, this mount directory will be called mount
point.
mount point/Thirdpty/language/actuate/reportcast/Sunos
where language is the language in which you purchased your Siebel eBusiness
Applications, for example, enu for U.S. English.
AIX
mount point/Thirdpty/language/actuate/reportcast/aix
where language is the language in which you purchased your Siebel eBusiness
Applications, for example, enu for U.S. English.
3 For the remaining installation steps, refer to Installing Actuate ReportCast Release
4.1 for UNIX.
Use the following scripts to start and stop IBM HTTP Server:
For best performance, Siebel Systems recommends that you install Actuate
e.Reporting Server on a different machine from that on which you installed Actuate
ReportCast and your Web server. Siebel Systems also recommends that you not
install Actuate e.Reporting Server on a host on which any other Siebel product
resides.
Installation Tasks
Read and perform the following tasks to complete installation of the Actuate
e.Reporting Server in a UNIX environment.
mount point/Thirdpty/language/actuate/Sunos
where language is the language in which you purchased your Siebel eBusiness
Applications, for example, enu for U.S. English.
AIX
mount point/Thirdpty/language/actuate/aix
where language is the language in which you purchased your Siebel eBusiness
Applications, for example, enu for U.S. English.
3 For the remaining installation steps, refer to Installing Actuate e.Reporting Server
Release 4.1 for UNIX.
NOTE: During the installation process, bypass all prompts except the X Server
prompt by pressing ENTER.
An X Server is required for DHTML/HTML graphs and for all printing in Actuate
e.Reporting Server.
Siebel Report Server Access consists of libraries shared by the Actuate products to
enable communication with the Siebel Server. Siebel Report Server Access also
contains an archive of reports that a user with system administrator privileges must
import to the report encyclopedia in a later step, along with customized Siebel
templates to be used by Actuate ReportCast.
Installation Tasks
You must install Siebel Report Server Access within the same directory in which you
installed Actuate e.Reporting Server. For example, if you installed Actuate
e.Reporting Server into actuate_server_home, you would install Siebel Report
Server Access under actuate_server_home/lib. This location guarantees that
the Actuate e.Reporting Server will find the shared libraries at run time.
From here forward, to make installation steps easier to complete, we will refer to
the Siebel Report Server Access installation directory (actuate_server_home/lib
in our example above) as siebel home.
AIX
uncompress -c mount point/rptsrvr/language/aix/install/bin.tar.Z | tar xvf -
2 Verify that you installed the Siebel shared libraries, archived reports, and the
customized templates of Actuate ReportCast correctly.
Solaris
siebel home/reports/reportsol.acf
siebel home/rptcast/rptcast_solaris.tar.gz
AIX
siebel home/reports/reports.acf
siebel home/rptcast/rptcast_aix.tar.gz
3 Set the following two environment variables in a suitable startup script for this
UNIX account.
For accounts using csh, tcsh, or other C-shell variants, edit the .cshrc file
and insert the following lines:
Solaris and AIX
For accounts using sh, ksh, bash, zsh, or other Bourne shell variants, edit
the .profile file and insert the following lines:
Solaris and AIX
SIEBEL_HOME=siebel home
SIEBEL_PLATFORM=sol
4 After making sure that all required environment variables set will be available
to the Actuate e.Reporting Server startup scripts, restart Actuate e.Reporting
Server.
An easy way of resetting the variables is to log out and log into the UNIX account
you created for Siebel Report Server before restarting Actuate e.Reporting Server.
Post-Installation Tasks
After you install Siebel Report Server Access, you must perform the following tasks:
AIX
If you imported the files successfully, no message appears, but a list of imported
report executable files appears.
netscape home/suitespot/docs/actuate/default
where netscape home is the directory into which you installed your iPlanet
Web Server.
AIX
ReportCast/actuate/templates/default
where ReportCast is the directory into which you installed your Web server.
2 Enter:
Solaris
AIX
NOTE: Only users with administrator privileges can access the Actuate ReportCast
Administration page.
http://webserver/acweb/report_server
where:
webserver = the name of the host on which your Web server resides
http://webserver/cgi_directory/nph-actuate.cgi/acweb/
report_server
where:
webserver = the name of the host on which your Web server resides
http://webserver/acweb/__admin
http://webserver/cgi_directory/nph-actuate.cgi/acweb/__admin
NOTE: If the Confirmation page does not appear, verify that your Web server
connection is still active.
3 Verify that your changes took place by displaying any Actuate ReportCast page.
Post-Installation Tasks 23
Perform the following post-installation tasks to make the Siebel Report Server
available to users and to confirm proper installation:
This subsection describes how to modify Siebel client files, such as Sales.cfg,
Service.cfg, and Customer.cfg, in an ActiveX Thin Client deployment on a
server, or on a dedicated client to run with the Siebel Report Server.
2 Locate the configuration (.cfg) file corresponding to the application that you
want to run with Siebel Report Server, and then double-click.
3 Using your default text editor, such as Windows Notepad, edit the following
parameters.
[Actuate Reports]
EnableReportsServer = TRUE
ConnectString = siebel.tcpip://xxx/siebel/zzzOBJMGR/yyy
xxx = Name of your Siebel Gateway
yyy = Name of your Siebel Server
zzz = Type of Object Manager, for example:
SCCOBJMGR = Siebel Call Center Object Manager
SFSOBJMGR = Siebel Field Service Object Manager
SSVOBJMGR = Siebel Service Object Manager
SSEOBJMGR = Siebel Sales Object Manager
Perform the following tasks to confirm that you have installed Siebel Report Server
correctly.
3 From the left panel of the main menu, choose any view.
The selected view appears.
4 From the Reports menu in the menu bar, choose any report.
The Run or Schedule for Later dialog box appears, prompting you as to whether
you want to generate a report now or schedule it for later.
5 Indicate that you want to schedule the report for later, specify the date, time, and
frequency, and click OK.
The scheduled report appears in the view, indicating the scheduled date, time,
and other information.
If the report does not appear, check the order and location in which you installed
the Siebel Report Server components, as described earlier in this chapter.
The method for uninstalling Siebel products has changed in version 6.x. This
chapter describes how to uninstall Siebel products under Windows NT and UNIX.
NOTE: If you do not want to delete the Siebel Server, skip ahead to Step 5.
3 Stop the Siebel Server, and then close the Services dialog box.
Do not quit the Control Panel yet.
NOTE: You must always uninstall the Siebel Server before uninstalling the Siebel
Gateway Server. Always uninstall the Gateway Server last.
7 Follow the remaining prompts from the uninstallation wizard until you complete
all screens.
8 If you are uninstalling the Siebel Gateway Server, first navigate to the Services
dialog box and stop the Gateway Server.
Repeat Step 6 on page 24-2 and Step 7 above for the Gateway Server.
To uninstall the Siebel Gateway Server and Siebel Servers on your system
1 Stop all services.
2 Manually delete the installation directory and rc3 entries.
3 Restart your machine.
Master Worksheet A
System Administrator:
Database Administrator:
Database Server:
Gateway Server:
Monitoring:
4-KB Data Tablespace 4-KB Long Tablespace 16-KB Data Tablespace Index Tablespace
Table B-1 lists the parameters in the sample tablespace files (tbspaces.sql and
smalltbs.sql) and table group configuration files (tbspaces.ctl and
smalltbs.ctl), shipped with Siebel eBusiness Applications for DB2 UDB for
OS/390.
After choosing the sample file that matches your target database, edit it to replace
the default parameter names with the actual database object names that you use on
your DB2 UDB for OS/390 system and that you have recorded in Table B-1.
NOTE: The three number signs (###) in the first several object names represent a
three-digit numeric sequence, such as 001, that appears in the actual table name.
Table B-1. DB2 UDB for OS/390 Tablespace and Table Group Configuration File Parameters (1 of 3)
Name as It
Appears in
Object Description Shipped Table Actual User Value
Tablespace for row-level logging tables. (Very high transaction rates.) AAAAA###
Tablespace for large tables that require their own 4-KB tablespace. BBBBB###
Tablespace for large tables that require their own 16-KB tablespace. CCCCC###
Tablespace for smaller or medium tables for a 4-KB tablespace. Most DDDDD###
tables will belong in these tablespaces.
Tablespace for any table that requires a 32-KB tablespace. Two such tables FFFFF###
exist in the default configuration.
Table B-1. DB2 UDB for OS/390 Tablespace and Table Group Configuration File Parameters (2 of 3)
Name as It
Appears in
Object Description Shipped Table Actual User Value
Tablespace for repository tables. Most of these are read-only except when HHHHH###
a repository upgrade is underway.
Table B-1. DB2 UDB for OS/390 Tablespace and Table Group Configuration File Parameters (3 of 3)
Name as It
Appears in
Object Description Shipped Table Actual User Value
Database for logging tables with very high transaction rates XXXXX007
implementation N
process 2-5 network connectivity
imprep.ksh 12-32 and the Enterprise Server 3-6, 4-6
imprep.log 10-27 establishing for mobile users 7-19, 8-25
index key length network security
verifying and correcting 11-9 access outside firewall 18-2, 18-4
indexes firewall configuration 18-5
allocating storage space on DB2/ networks
390 11-8 verifying LAN connectivity 7-6, 8-7,
init.ora file 14-7 16-5, 17-4
install_siebel.ksh
location of 12-25 O
installation object validation script
Database Server 10-17, 15-10 editing of 12-29
File System 5-4, 6-4 execution of 12-30
process 2-5 Oracle database
Siebel Server 7-9, 8-9 administration 14-10, 14-12
skill requirements 1-2 configuration guidelines 9-2, 14-3
Installing 22-1, 23-1 configuration parameters 14-7
Interface table usage by EIM 11-4 post-installation
IP addresses recommendations 14-12
about 3-6, 4-6 space for Siebel data 14-9
tablespace allocation 14-9
J
Java Thin Client P
access outside firewall 18-2, 18-4 post-installation tasks
Enterprise Server 6-11
L Gateway Server 6-11
list of invalid objects report 13-5, 13-9 Resonate Central Dispatch 3-10, 4-10
list of invalid objects report script Siebel Server 7-18, 8-22
editing of 13-7 post-migration task 13-22
execution of 13-7 pre-installation tasks
log files Database Server 10-3, 15-3
install.bat 10-22, 12-23, 12-28, 12-31, Resonate Central Dispatch 3-2, 4-2
12-36, 13-21, 15-15
repository import 10-27, 15-20 R
RACF group for Siebel and EIM users 12-6
M RDBMS software
Microsoft SQL Server database verification 2-24
indexes 9-4, 14-5 Release Notes 5-6, 6-5, 7-2, 8-3, 16-3, 17-3
table indexes 9-4, 14-5 repositories, and log files 10-27, 15-20
Mirroring 9-11 repository importation script
MXTB 11-15 editing of 12-32
execution of 12-34
V
verification
Gateway Server 2-13
RDBMS software 2-24
Siebel Server 2-13
Siebel Server database connectivity
software 7-3, 8-3, 16-3, 17-4
Siebel Server prerequisites 7-2, 8-3,
16-3, 17-3
W
Windows NT Accounts, creating for
Resonate Central Dispatch 3-3, 4-3
Windows Thin Client
access outside firewall 18-2, 18-4
caution 19-5
editing configuration files 19-5
parameters order 19-5
tclient.htm 19-4
tclient.stc 19-4
Z
ZPARM
EXTENDED SECURITY 11-15
MXTB 11-15