siebel crm 8.0/8.1 applications protected by oracle ... · pdf filesiebel crm applications...

Siebel CRM 8.0/8.1 Applications protected by Oracle Clusterware 11gR2 An Oracle Technical White Paper

June 2012

Siebel CRM Applications protected by Oracle Clusterware 11gR2

Introduction ....................................................................................................... 3

Overview of A Simple Siebel Architecture .................................................... 4

What is Oracle Clusterware? ............................................................................ 6

High Availability for the Siebel Gateway– Introduction ............................. 6

Software Installation and Configuration ........................................................ 7

Step 1a: Create an Application VIP for the Siebel Gateway ................ 10

Step 1b: Create an Siebel Server Application VIP per node ................ 12

Configuration of the Siebel Gateway and Siebel Servers ................. 12

Step 2a: Create and Test the Action Script for the Siebel Gateway .... 13

Step 2b: Create and Test the Action Script for each Siebel Server ..... 15

Step 3a: Create a Siebel Resource Type With Oracle Clusterware ...... 16

Step 3b: Add the Siebel Gateway Application to Oracle Clusterware 16

Step 4: Add the Siebel Server to Oracle Clusterware ............................ 17

Step 5: Test the Siebel High Availability Environment ......................... 18

Summary ........................................................................................................... 20

Appendix A – Siebel Gateway Resource create script ............................... 22

Appendix B – Siebel Gateway Scripts .......................................................... 25


INTRODUCTION

High availability for Siebel means that a user can access key system services even

when the underlying hardware or software for those services fails.

For example, if a Siebel remote user synchronization session was interrupted by a

failure of the Siebel Server to which it was connected; users can reconnect to a

failover system and restart the synchronization process without any data loss.

This paper documents the setup and configuration on both Siebel and Oracle

Clusterware 11gR2 to achieve High Availability (HA) for the Siebel CRM

Applications.

The scripts used in this document, noted in the appendix, are meant to be sample

scripts. These scripts register Siebel application resources under Oracle Clusterware

control and implement control actions for the Oracle Clusterware script agent HA.

Before using these scripts, customization may be required in order to meet the

needs of your environment. The Oracle Clusterware and Siebel APIs invoked

within these scripts are fully supported by Oracle. The scripts and subsequent

modifications are not supported by Oracle. Care must be taken to build and test

these scripts.

Prior to Oracle Clusterware 11gR2, application resources were configured using the

crs_* utilities such as crs_register, crs_start, crs_stop, crs_profile, etc. Oracle

Clusterware 11gR2 has deprecated this crs_* interface in favor of the singular crsctl

interface1. As a consequence, the way the application resources are configured and

controlled is by means of the common crsctl interface. In addition, Oracle

Clusterware 11gR2 introduces a simplified application VIP interface, appvipcfg.

This interface simplifies the creation and management of the application VIP. This

paper will only describe these interfaces2.

The scripts included in this document have been tested on Oracle Enterprise Linux

5 (OEL5) using Oracle Clusterware 11gR2. The scripts are expected to work on all

Linux and Unix platforms which supports Oracle Clusterware 11g Release 2 or

later.

These scripts are composed of start, stop, check, clean, and abort entry points using

Siebel application primitives and the Oracle Clusterware 11gR2 script agent

1 For a complete list of deprecated crs_* commands, refer to the Oracle Clusterware Administration and Deployment Guide 11gRelease 2(11.2) Part Number E16794-16, Appendix E 2 For Oracle Clusterware pre-11gR2, please see the document ‘Siebel CRM Applications protected by Oracle Clusterware 11gR1’.

Providing High Availability for Siebel

Applications ensures minimal user

interruptions in case of an application

or node failure.

This paper explains how to use Oracle

Clusterware to protect Siebel Applications.

The resources to be protected are the

Siebel Gateway and Siebel Server

Services.


framework3. These action primitives are invoked in a parent script commonly

referred to as the agent action script. It is the action script that is presented to

Oracle Clusterware to control the HA of the application components using the

Oracle Clusterware 11gR2 script agent. Other scripts noted in the appendix will

create the necessary resources required for Siebel HA including any inter-resource

dependencies. Siebel HA using Oracle Clusterware 11gR2 as defined by the

attached scripts may include the Siebel Gateway Name Server or both the Siebel

Gateway Name Server and Siebel Servers. To implement the Siebel HA required

you simply run the scripts relevant to the Siebel component.

OVERVIEW OF A SIMPLE SIEBEL ARCHITECTURE

Siebel CRM Applications are composed of the following main server elements:

Siebel Gateway, Siebel Server and Siebel Web Server Extension (SWSE).

Both the Siebel Gateway Server and the Siebel Server run as services in the system.

SWSE is a plug-in to the web server. For web servers High Availability, set up a

load balancing configuration using one of the Oracle certified HTTP load balancers

which also allow user requests to fail over between web servers. This paper will not

discuss Oracle Clusterware high availability for the SWSE plug-in but will focus on

high availability for the Siebel Gateway Server and the Siebel Server.

The figure1 below illustrates a high level description Siebel work flow describing

Siebel Gateway and Siebel Server communication.

3 For a complete description of application HA using Oracle Clusterware, please see chapter 6, Making Applications Highly Available Using Oracle Clusterware in Oracle® Clusterware Administration and Deployment Guide 11g Release 2 (11.2) Part Number E16794-17


Figure 1: Example of Simple Siebel Deployment

The Siebel Gateway Name Server coordinates the Siebel Enterprise Server and

Siebel Servers. It also is a persistent backing store for the Siebel Enterprise Server

configuration information, including definitions and assignments of component

groups and components, operational parameters and connectivity information.

The Siebel Server is the middle-tier platform that supports both back-end and

interactive processes for every Siebel client. It supports both multi-process and

multithreaded components, and can operate components in background, batch, and

interactive modes.

Note that there can be only one instance of the Siebel Gateway per Enterprise but

there can be multiple Siebel Servers configured for one Siebel Enterprise server.

For each Siebel Server, different components such as Call Center Object Manager,

EIM or Siebel Remote, can be configured to run on each node. Oracle Clusterware

11gR2 can provide HA for each of these components following the guidelines

documented in this paper. However, this paper describes the basic steps to

configure HA focusing on a single Siebel Gateway Server and a single Siebel Server.

You would use these same steps, configuring for network and Siebel Server

resource uniqueness using the same steps below. If configuring HA for each Siebel

Server, best practice suggests that you map a unique VIP to each Siebel Server

resource as defined in the Oracle Clusterware and noted below.


WHAT IS ORACLE CLUSTERWARE?

Oracle Clusterware is portable cluster software that allows clustering of single

servers so that they cooperate as a single system. Oracle Clusterware also provides

the required infrastructure for Oracle Real Application Clusters (RAC), a multi-

instance active/active clustered RDBMS. In addition, Oracle Clusterware enables

the protection of any application within the cluster. Oracle Clusterware is

supported on all major operating systems4.

Figure 2: Oracle Clusterware Topology Overview

HIGH AVAILABILITY FOR THE SIEBEL GATEWAY– INTRODUCTION

This paper describes Oracle Clusterware 11gR2 to enable high availability for the

Siebel Gateway Name Server and the Siebel Server Services. Note that since there

can be only one Siebel Gateway running per Enterprise Server, the Gateway can

only be configured to run in Active/Passive mode. Siebel Servers can be configured

to run in Active/Active mode to fully utilize all available resources in the

environment.

Oracle Clusterware must be installed and configured to manage the application and

application dependent resources. The start, stop and check and clean of the

application and dependent resources will be managed by the Oracle Clusterware

software solution. If there is an application failure, Oracle Clusterware will attempt

to restart the application. The number of attempted restarts of the resource is user

configurable. Once the number of configured restart attempts for a particular

resource is reached, Oracle Clusterware will perform failover of this process and

4 For more information on Oracle Clusterware, see: http://otn.oracle.com/clusterware

The Siebel Gateway Server serves as the

dynamic address registry for Siebel

Servers and components.

At startup, every Siebel Server within the

Siebel Enterprise stores its network

address in the non-persistent address

registry of the Siebel Gateway.

Hence, it is important for the Gateway

Server to be highly available.


dependent resources, such as the Application Virtual IP (VIP)5, to another

available node in the cluster.

In case of a node failure, Oracle Clusterware will failover a Virtual IP (VIP) to

another node in the cluster. Once the relocation of the VIP to another node has

been established, Oracle Clusterware will restart the Siebel resource on the new

node. Siebel CRM users are now able to re-connect back to the application with

minimal interruptions.

When server or software maintenance is required, leverage Oracle Clusterware

11gR2 online resource relocation functionality to move the application resource,

such as the Siebel Gateway Name Server, to another available node in the cluster

with no interruption of service.

SOFTWARE INSTALLATION AND CONFIGURATION

This paper assumes that Oracle Clusterware 11gR2 has been installed and the

Oracle Clusterware users and user groups specific to the operating system have

been created on all nodes in the cluster in advance, as per the Oracle Clusterware

installation and configuration guide.

It is required that all nodes have access to the Siebel software. This can either be

achieved by using a shared installation based on ASM Cloud File System (ACFS)

shipped with the Oracle Clusterware, or a shared NFS mount, or by using a local

node installation of the software (default for Oracle Clusterware) where the binary

tree and absolute path is identical on all nodes.

For more information on the installation and setup, please consult the Oracle

Clusterware Administration and Deployment Guide6 and the Siebel Installation

Guide which is available for download on edelivery.oracle.com or the Siebel

Support Web7.

5 Application Virtual IPs allow autonomous client connect to the application and an expedient notification if the network stack fails. 6 For the Oracle Clusterware Administration and Deployment Guide refer to: http://docs.oracle.com/cd/E11882_01/rac.112/e16794/title.htm 7 The Siebel Installation guide can be downloaded for free from http://edelivery.oracle.com A login is required for the Siebel Support Web


Figure 3: Siebel Configuration where 2 instances of Call Center OM, 2 Siebel Remote Servers and 1 instance of the Siebel Gateway Server are protected by Oracle Clusterware for Siebel. The RAC database is also protected by another instantiation of the Oracle Clusterware.

CONFIGURING SIEBEL IN A HIGH AVAILABILITY ENVIRONMENT

In order to run the Siebel Gateway and the Siebel Server in a High Availability

configuration, highly available network resources are required. In addition to

redundant network adapters, Oracle Clusterware 11gR2 will be used to provide the

virtual IP addresses or virtual hostnames for those components. These network

resources are essential for external client communication to the application and as a

consequence, the Siebel components will have defined dependencies on these

network resources managed by the Oracle Clusterware stack.


As noted earlier, Oracle Clusterware 11gR2 will be used to start, stop, check and

clean the application and dependent resources. These operations are presented to

the Clusterware as management entry points to control application and are invoked

by an Oracle Clusterware entity called the script agent. This paper provides generic

action scripts for these entry points based on primitives provided by the Siebel

CRM software. The check action is used to monitor and detect fault of the

application and dependent resources. Upon detecting an application or resource

failure Oracle Clusterware will perform the appropriate restart, failover and clean

operations. It is imperative that the check action is coded, tested and functioning

properly. Failure of the check action triggers failover.

The following abbreviated steps outline how the Siebel application and dependent

network resources are configured with the Oracle Clusterware 11gR2 HA

Framework. The following section provides detailed syntax and examples, however

the appendix has operational action scripts and Siebel application scripts to create

the necessary resources.

These steps assume that the Oracle Clusterware 11gR2 and the Siebel software

binary trees are correctly installed and functionally tested:

1. Create, customize if necessary and test the action scripts for

a. The Siebel Gateway b. Every Siebel Server to be deployed on a cluster node.

2. Create an Application VIP for

a. The Siebel Gateway b. One for Every Siebel Server to be deployed on a cluster node.

3. Register the application with Oracle Clusterware

a. The Siebel Gateway b. Every Siebel Server to be deployed on a cluster node.

4. Define Role Management

a. assign the appropriate owner, access and execution privileges to the application resources

5. Test the Siebel High Availability environment for a. The Siebel Gateway

b. Every Siebel Server to be deployed on a cluster node.

When registering resources with Oracle Clusterware 11gR2, resource dependencies can be defined. Dependencies dictate whether other resources must be started or stopped with the registered resource, for example the application VIP must be started before the application resource and stopped after the application resource.

In this paper, the Siebel Gateway and

Siebel Server High Availability

configuration assumes a 2 node cluster.

In a active/passive setup, one server

actively runs applications and services.

The other is usually idle. If the active

server fails, its workload is switched to the

idle server, which then takes over

application processing.

The Siebel Server Gateway and the Siebel

Server can be placed on different nodes to

utilize all available resources.


Oracle Clusterware 11gR2 start and stop dependencies offer a rich dependency model with hard, weak, pullup, dispersion and attraction attributes8. The following steps illustrate the configuration and deployment of Siebel Servers and the Siebel Gateway Server in the Oracle Clusterware HA framework.

Step 1a: Create an Application VIP for the Siebel Gateway

Go to: $GRID_HOME/bin (/u01/app/11.2.0/grid/bin by default) and issue

the following as superuser, a.k.a, the root user:

In this example, the Siebel Gateway application VIP named sieb_gtwy_vip is

created on the primary public network, Oracle Clusterware resource

ora.net1.network (network=1), with a user configurable virtual IP address. The

application VIP is a local root owned resource and as such, must be created as root.

Note that ‘network 1’ is the default public network created at the time the Oracle

Clusterware was configured. This network will use the same network interface and

defined subnet as the default public network. If you require a dedicated network

resource, you will need to define a different network resource using a separate

network interface and separate subnet. To determine and validate network

configurations use the command ‘crsctl status resource ora.net<N>.network’

where <N> represents the network number (1 being the default). This command

will provide you the current and available network attribute settings for a given

network known to the Oracle Clusterware. Note: This command and all

commands illustrated in this paper assume single line syntax.

The subnet for the sieb_gtw_vip VIP must be the same as the subnet defined for

the physical NIC defined for ora.net1.network (here: eth0). In LINUX and UNIX

environments the subnet can be determined using the command ‘/sbin/ifconfig –a

<IF>’, where <IF> represents the network interface, such as eth0. The CIDR

addressing can be derived using the “mask” parameter value and the inet address

defined.

The IP address must either be registered in the DNS used in the environment or be

defined in the local hosts file on all nodes in the cluster prior to issuing this

command.

8 Idem, Oracle® Clusterware Administration and Deployment Guide 11g Release 2 (11.2)

# $GRID_HOME/bin/appvipcfg create –network=1 \ –ip=<VIP ADDRESS> -vipname=sieb_gtwy_vip –user=root \ –group=<GROUPID>


When the Application VIP is created it is automatically registered with Oracle

Clusterware. When creating the application VIP sieb_gtwy_vip, you should see the

following echoed to stdout:

Executing cmd: /u01/app/11.2.0/grid/bin/crsctl add resource sieb_gtwy_vip -type app.appvip_net1.type –attr “USR_ORA_VIP=<VIP ADDRESS>, START_DEPENDENCIES=hard(ora.net1.network) pullup(ora.net1.network,STOP_DEPENDENCIES=hard(ora.net1.network),ACL=’owner:root:rwx,pgrp:root:r-x,other::r–,user:root:r-x’,HOSTING_MEMBERS=<HOSTNAME WHERE THE VIP STARTED>, APPSVIP_FAILBACK=”

To confirm the resource registration and to check status with the Oracle Clusterware issue the command:

Which results in the following status:

NAME=sieb_gtwy_vip TYPE=app.appvip_net1.type TARGET=OFFLINE STATE=OFFLINE

TARGET is to be online, STATE is currently offline as the resource has not been

started yet.

Application VIPs are local resources created and owned by root. Oracle

Clusterware provides UNIX like ACL control over any defined resource9. If the

sieb_gtwy_vip will need to be executed by non-root users, define the correct ACL

accordingly. It is common that the execution permissions would be granted to the

owner of the Siebel binaries as in this example, the user orasiebel.

To set or modify permissions on the sieb_gtwy_vip execute, as root:

The Siebel software owner (orasiebel) is explicitly granted permission to start, stop

and relocate the sieb_gtwy_vip application VIP resource that runs with root

privileges. Note that this is distinct from the Oracle Clusterware core VIP resources

used by the Real Application Clusters database which may be running in the same

environment.

9 See the ACL list and owner in the execution output for appvipcfg above

# $GRID_HOME/bin/crsctl setperm resource sieb_gtwy_vip –u user:orasiebel:r-x

# $GRID_HOME/bin/crsctl status resource sieb_gtwy_vip


Step 1b: Create an Siebel Server Application VIP per node

Similarly to Step 1a, create an Application VIP for each Siebel Server.

As root execute:

Where <VIP ADDRESS> is the virtual IP address for the Siebel Server which is

different from the sieb_gtwy_vip address. Note that the default public network is

used here as with the Siebel Gateway Server.

Once the resource is created, check the resource registration and status by

executing the command:

This command should return with:

NAME=sieb_srv_vip TYPE=app.appvip_net1.type TARGET=OFFLINE STATE=OFFLINE

TARGET is offline, STATE is currently offline as the resource has not been

started yet.

As noted earlier application VIPs are created and run as root. In order for non-root users to manage the VIP resource, correct permissions must be set for the user on that resource:

where ‘\’ represents a command line break for single line command syntax.

A single Siebel Server VIP can be configured to be shared by multiple Siebel Servers running on a specific server. If you require individual Siebel Server HA, a unique VIP should be configured for each of the Siebel Servers running in the environment. In our example, we will create a single Siebel Server VIP per server to be shared by the Siebel Servers running on the server.

Configuration of the Siebel Gateway and Siebel Servers

The Siebel Gateway needs to be configured to run on the VIP just created in step

1a (sieb_gtwy_vip). Therefore, Oracle strongly recommends using a name resolution

# $GRID_HOME/bin/appvipcfg create –network=1 –ip=<VIP ADDRESS> -vipname=sieb_srv_vip –user=root

# $GRID_HOME/bin/crsctl setperm sieb_srv1_vip –u \ user:orasiebel:r-x

# $GRID_HOME/bin/crsctl status resource sieb_srv_vip


for this VIP. The name resolution can either be performed using a DNS or by

adding an alias to the hosts files of all the nodes in the cluster.

When configuring the Siebel Gateway, the virtual IP and virtual host name should

then be used as the Gateway Name Server Host Name.

Figure 4: Siebel Gateway Configuration

Similarly, the Siebel Server host parameter needs to be configured to use the virtual

host name of the Gateway Name Server Host and not the physical host name of

the server.

Step 2a: Create and Test the Action Script for the Siebel Gateway

In this step, the script that will be used to start, stop, and check the status of the

Siebel Gateway Server is created and tested. However, this step will not go into

details on how to create the script. Instead, use the sample script “sieb_gtwy.scr”

provided in Appendix B as an example.

From the Oracle Clusterware point of view, there needs to be one script accepting

“start”, “check”, “stop”, and “clean” as command line arguments, since Oracle

Clusterware will call this script for each of those actions, passing the respective

argument.

The Siebel Gateway is configured to run on the virtual host name for the server,

which resolves to the VIP created in step 1a (sieb_gtwy_vip). Therefore, the VIP

needs to active before the Siebel Gateway can be started.


For our example, as the orasiebel user execute:

Upon a successful execution of this command, the following message is displayed:

Attempting to start `sieb_gtwy_vip` on member `node1` Start of `sieb_gtwy_vip` on member `node1` succeeded.

Due to explicit startup dependencies between the Siebel Gateway and the Siebel

Gateway VIP defined in the script supplied when the Siebel Gateway resource is

created, the Siebel Gateway will be started on the node where the assigned

sieb_gtwy_vip is running. If the VIP is not running, it will be started implicitly. In

this example, Siebel application resources and their dependencies are not restricted

to run on specific nodes in the cluster. A PLACEMENT resource attribute can be

defined when the Siebel application resource or VIPs are created, controlling the

start, failover or relocation eligibility of a server in the cluster. This topic will be

addressed in subsequent versions of this document. If interested, details on

PLACEMENT and other Oracle Clusteware 11gR2 resource attributes can be

found in the earlier referenced Oracle Clusterware 11gR2 Admin. Guide.

Regardless of placement policy, crsctl commands to start, stop, and relocate any

resource can be executed from any node in the cluster.

Once the VIP has been started successfully, the start function of the action Script

for the Siebel Gateway can be tested. Since the Siebel Gateway itself has not been

registered with Oracle Clusterware yet, any action of the action script needs to be

tested manually.

Therefore, change to the Siebel software owner (here: orasiebel), go to the directory

where the action script for the Siebel Gateway has been stored and issue:

On the next prompt, enter:

Note: a successful execution of the script would result in echo $? and must return

the value 0. However, in order to make sure that the script returns the right value

depending on the operation performed, check the successful execution using the

$ $GRID_HOME/bin/crsctl start sieb_gtwy_vip

sieb_gtwy.scr start

echo $?


operating system command “ps” to list running processes. As the orasiebel user

issue:

At this stage, this command should list a running Siebel Gateway.

In order to test the check action for the Siebel Gateway, issue the command listed

below as the orasiebel user. Similarly to the test above, issue echo $? after calling

the action script with the appropriate parameter (check). Make sure that “0” is

returned, indicating a successful execution:

Once the start and check is functioning as expected, the sieb_gtwy.scr should be

called with the stop parameter to test the shutdown of the Siebel Gateway process.

As before, issue ‘echo $?’ to verify the result. Again, a zero value should be returned

upon a successful shutdown of the Siebel Gateway.

Step 2b: Create and Test the Action Script for each Siebel Server

Similarly to Step 2a, create the script that will be used to start, stop and check the

status of each Siebel Servers deployed. See Appendix C for an example of the

sieb_srvr.scr script.

Test the script (see examples in step 2a for the sieb_gtwy_scr tests) and ensure it is

working before creating the application profile in step 3.

NOTE: ONCE THE SIEBEL APPLICATIONS ARE CREATED AND

ADDED TO THE ORACLE CLUSTERWARE, DO NO EXECUTE THE

START, STOP, CHECK AND CLEAN ACTIONS OUTSIDE OF THE

ORACLE CLUSTERWARE HA FRAMEWORK. ALL CONTROL OF

THE APPLICATION MUST NOW BE EXECUTED USING CRSCTL.

ps –ef |grep siebsvc | grep gtwyns

sieb_gtwy.scr check

echo $?

sieb_gtwy.scr stop

echo $?


Step 3a: Create a Siebel Gateway Resource Type With Oracle

Clusterware

Generally, all resources are unique but some resources may have common

attributes. Oracle Clusterware uses resource types to organize these similar

resources. Benefits that resource types provide are:

• Manage only necessary resource attributes

• Manage all resources based on the resource type To create a Siebel resource type to more easily manage Siebel application resources, issue the following:

where $GRID_HOME is the absolute path for the Oracle Clusterware binary install and $DIRPATH = the absolute path location of the script files, for example, /opt/siebel_HA_scripts/siebel_gtwy.scr

Step 3b: Add the Siebel Gateway Application to Oracle Clusterware

After creating and thoroughly testing the action scripts for the Siebel Gateway and

the Siebel Servers, insure that there are no instances of the Siebel Gateway and

associated processes running on any server in the cluster. Only then, register the

Siebel Gateway resource with the Oracle Clusterware. When you register an

application with the Oracle Clusterware, the relevant information about the

application for the management of the application and relevant resources of the

application as well as the execution profile of the application are stored in the

Oracle Clusterware Repository (OCR). This information includes the absolute path

the the action script described above, the defined permissions (ACL) for the

application resource as well as any required start/stop resource dependencies.

To add and ‘register’ the Siebel Gateway application with the Oracle Clusterware,

As the orasiebel user, issue:

where $GRID_HOME is the absolute path of the Oracle Clusterware binary install,

$SIEBEL_HOME is the absolute path for the Siebel Gateway Name Server binary

install and $LOG_DIR is a user defined logging directory.

# $GRID_HOME/bin/crsctl add type siebel_gtwy_type \ -basetype cluster_resource \ -attr "ATTRIBUTE=ACTION_SCRIPT, \ TYPE=string,DEFAULT_VALUE=$DIRPATH/siebel_gtwy.scr, \ ATTRIBUTE=SIEBEL_HOME,TYPE=string, \ FLAGS=REQUIRED,ATTRIBUTE=LOG_DIR, \ TYPE=string,FLAGS=REQUIRED"

$ $GRID_HOME/bin/crsctl add resource siebel_gtwy_app -type siebel_type -attr \ "ACL='owner:orasiebel:rwx,pgrp:siebel:r-x,other::r--', \ SIEBEL_HOME=$SIEBEL_HOME,LOG_DIR=$LOG_DIR, \ CHECK_INTERVAL=30,RESTART_ATTEMPTS=10,START_TIMEOUT=300, \ STOP_TIMEOUT=300,AUTO_START=restore, \ START_DEPENDENCIES=hard(siebel_gtwy_vip)pullup:always(siebel_gtwy_vip), \ STOP_DEPENDENCIES=hard(intermediate:siebel_gtwy_vip)"


This command adds the siebel_gtwy_app as a defined type siebel_type and

subsequently defines a number of resource attributes associated with the

siebel_gtwy_app. These attributes include the ACTION_SCRIPT with the

application control entry points, ACL read, write, execute permissions for the

orasiebuser and siebel group members, the SIEBEL_HOME, a user defined

LOG_DIR, CHECK_INTERVAL indicating the frequency of the check action,

application restart attempts, and related timeout if the application does not start, in

addition to stop timeouts and the AUTO_START attribute indicating whether the

application should be restarted when the server comes up. The

START_DEPENDENCIES and STOP_DEPENDENCIES are directives for

associated relationships with the siebel_gtwy_vip, whereby, the sieb_gtwy_app

cannot start unless the siebel_gtwy_vip is started, and, if it is not running, an

attempt will be made to pull the siebel_gtwy_vip up and put the state online.

Similarly, the STOP_DEPENDENCY will take down the siebel_gtwy_app when

the siebel_gtwy_vip resource is stopped. The siebel_gtwy_vip is a required resource

for the siebel_gtwy_app.

Step 4a: Create a Siebel Server Resource Type With Oracle Clusterware

As mentioned, generally, all resources are unique but some resources may have

common attributes. Oracle Clusterware uses resource types to organize these

similar resources. Configuring a Siebel Server Resource Type with a common

action script allows for simple and efficient resource grouping of common

resources that invoke the same actions. This avoids having to maintain multiple

action scripts or script definitions associated with each resource. In addition Oracle

Clusterware status commands and execution can filter on resource type.

To create a Siebel Server resource type to more easily manage Siebel Server application resources, issue the following:

where $GRID_HOME is the absolute path of the Oracle Clusterware binary install

and $DIRPATH is the absolute path location of the script files, as in the previous

example.

Step 4b: Add the Siebel Server to Oracle Clusterware

As with the Siebel Gateway, the Siebel Server needs to be added and ‘registered’

with Oracle Clusterware and permissions correctly set to run as the Siebel operating

system user (here: orasiebel). Execute the following command as the Oracle

Clusterware software owner (here: oracle):

# $GRID_HOME/bin/crsctl add type siebel_srv_type -basetype cluster_resource \ -attr "ATTRIBUTE=ACTION_SCRIPT,TYPE=string, \ DEFAULT_VALUE=$DIRPATH/siebel_srv.scr, \ ATTRIBUTE=SIEBEL_HOME,TYPE=string, \ FLAGS=REQUIRED,ATTRIBUTE=LOG_DIR, \ TYPE=string,FLAGS=REQUIRED"


where $GRID_HOME is the absolute path of the Oracle Clusterware binary install,

$SIEBEL_HOME is the absolute path for the Siebel Server binary install and

LOG_DIR is a user defined logging directory.

As with the Siebel Gateway resource the CHECK_INTERVAL,

RESTART_ATTEMPTS, START_TIMEOUT, STOP_TIMEOUT,

AUTO_START and start/stop dependencies are defined as attributes of the

siebel_srv_app resource and are managed by the Oracle Clusterware. These settings

have been tested and optimal for Siebel component high availability.

Step 5: Test the Siebel High Availability Environment

Before deploying the Siebel HA environement, testing is required. This step will be

used to outline some basic tests that should be performed. Depending on the

production environment, additional tests may be required.

The tests should emphasize:

1. Use of Oracle Clusterware commands to operate on registered resources

a. To ensure that dependencies are maintained and executed

correctly.

b. To validate that Siebel application components under Oracle

Clusterware control are not executed outside of the HA

framework.

2. To validate reaction to failure scenarios such as

a. Process failures

b. Node failures

c. Network failures

3. To practice maintenance operations which require relocation of resources

among nodes

Suitable scenarios should begin with tests which start and stop the registered Siebel

applications using Oracle Clusterware commands. These commands must work

properly before continuing with any other tests. When the start and stop of the

application is executed outside of the Oracle Clsuterware HA framework,

unpredictable results may occur.

To test the start of the Siebel Gateway issue:

$ $GRID_HOME/bin/crsctl add resource siebel_srv_app -type siebel_srv_type -attr \ "ACL='owner:orasiebel:rwx,pgrp:siebel:r-x,other::r--', \ SIEBEL_HOME=$SIEBEL_HOME,LOG_DIR=$LOG_DIR, \ CHECK_INTERVAL=30,RESTART_ATTEMPTS=10, \ START_TIMEOUT=300, STOP_TIMEOUT=300,AUTO_START=restore, \ START_DEPENDENCIES=hard(siebel_srv_vip)pullup:always(siebel_srv_vip), \ STOP_DEPENDENCIES=hard(intermediate:siebel_srv_vip)" NEED DEPENDENCY ON GTWY


Logically, the Siebel Gateway needs to run before any Siebel Server should be

started, since necessary configuration information is required from the Siebel

Gateway by each starting Siebel Server.

Therefore, the start action of the Siebel Server action script (sieb_srvr.scr – see

Appendix C) checks whether or not a Siebel Gateway is running in the cluster. If

no Siebel Gateway is running, it will start a Siebel Gateway using the defined pullup

dependency on the sieb_gtwy_vip resource. Nevertheless, it makes sense to test this

scenario during production testing.

Following the test steps in this paper, stop the Siebel Gateway and try starting the

whole stack by starting the Siebel Server as the high level application:

Then start the Siebel Server:

The start of the Siebel Server should also start the Siebel Gateway on one of the

nodes in the cluster. Proper startup of the Siebel Gateway and Siebel Servers should

be confirmed using `crsctl stat resource –t`.

It should also be noted that based on the dependency settings the VIPs for the

Siebel Gateway and the Siebel Servers should have been started implicitly, too.

Those VIPs will always run on the same node as the associated Siebel Services

(Gateway or Server).

However, starting those Siebel Services in this way (using a Siebel Server startup to

start the Siebel Gateway) may start all components on the same node. While this is

generally not a problem and certain application profile settings (or starting the

Siebel Servers using the –c <nodename> when issuing the crs_start command)

might prevent that, there might still be scenarios in which a relocation of one of

those components is desirable.

Therefore, suitable relocation tests using the `crsctl relocate resource <RES>`

command should be performed. When running those tests, it should be also

ensured that dependencies will follow the root resource. E.g. one can only relocate

a resource that other recourses are not dependent on.

If there are dependencies to the resource, the ‘force’ (-f) option must be used to

relocate the respective resource. However, appropriate error messages will be given

in this case. If the force option is used, all resources (including the dependent ones)

$ $GRID_HOME/bin/crsctl start sieb_gtwy_app

$ $GRID_HOME/bin/crsctl start sieb_srv_app

$ $GRID_HOME/bin/crsctl stop sieb_gtwy_app


will be relocated.

To test the relocation of the Siebel Gateway go to and issue:

In the above example the Siebel Gateway is relocated to ‘node2’, which assumes

that it was running on ‘node1’ before. Further relocation tests can be performed for

each Siebel component registered in the cluster as well as for VIPs.

After suitable tests have shown that Oracle Clusterware commands can successfully

be used to start, stop, and relocate all the registered resources, tests should be

performed for the check operations. Those tests should include all plausible failure

scenarios. Note, the viability of the process protected by Oracle Clusterware

depends on the correct execution and resulting return codes in order to take the

necessary corrective action. If the check action does not execute, or executes

incorrectly, you may experience unpredictable results. It is well worth the effort to

evaluate the check action in various scenarios. See the appendix for the Siebel

Check action scripts invoked for all of the Siebel resources.

Oracle does not generally recommend on how those failure scenarios should be

tested. Suitable test scenarios should be developed and performed in accordance to

the production environment.

SUMMARY

The information presented assumed that the following steps have been completed:

• Oracle Clusterware is installed10

• Oracle Real Application Clusters is installed11

• Siebel Gateway is installed

• Siebel Server is installed

• Oracle HTTP Server is installed12

• Siebel Siebel Web Server Extention (SWSE) is installed13

10 For the Oracle Clusterware Installation and Configuration guides refer to: http://www.oracle.com/pls/db111/portal.portal_db?selected=11&frame= 11 For the Oracle Real Application Clusters Installation and Configuration guides refer to: http://www.oracle.com/pls/db111/portal.portal_db?selected=11&frame= 12 For installation of the Oracle HTTP Server, refer to: http://download.oracle.com/docs/cd/B25221_04/nav/docindex.htm

$ $GRID_HOME/bin/crsctl relocate -c node2 sieb_gtwy_app


Based on this software infrastructure, Oracle Clusterware can be used to protect

the Siebel Gateway and the Siebel Servers in a High Availability environment.

This paper does not claim to be complete in its instructions. Instead, the general

procedure is outlined and respective cross-references and recommendations have

been made in regards to the required steps to deploy in production environments.

The sample scripts and application profiles provided in Appendix A-D can be used

to implement this High Availability environment for Siebel applications discussed

in this paper. But customization will be required before using them in production.

NOTE: Oracle Clusterware has pre-packaged agents for many applications. A pre-

packaged agent for Siebel CRM will be available soon. Please see:

http://www.oracle.com/technetwork/products/clusterware/overview/index.html

For up-to-date release status for the Siebel agents.

13 For documentation on the installation of all Siebel Components refer to http://edelivery.oracle.com and download the “Siebel Business Applications Media Pack 8.0 Release for Linux x86” (when working on Linux x86).


APPENDIX A – SIEBEL GATEWAY RESOURCE CREATE SCRIPT

#!/bin/ksh # # This script: # Creates Siebel GATEWAY VIP, sieb_gtwy_vip. # Sets the correct ACLs on sieb_gtwy_vip # Creates the Siebel Resource TYPE siebel_type. # Adds the Siebel GATEWAY APP, seib_gtwy_app # Executes status on these two resources, sieb_gtwy_vip and sieb_gtwy_app # after this script exits. # create_sieb_gtwy_res.sh # SCRIPT=$0 ACTION=$1 IP="" SIEBEL_HOME="" LOG_DIR="" USER="" GROUP="" usage2() { echo "Creates Siebel Virtual IP, resource type, and gateway resource " echo "Root privilege is required" echo " " } usage() { echo "Usage: $0 " echo " --siebel_home <siebel_home> Siebel home directory" echo " --log_dir <log_dir> Location of the log file" echo " --ip <ip_address> IP address" echo " --user <user> Operating System user name that owns the instance" echo " --group <group> (Optional) Name of the group to which the " echo " Operating System user belongs" exit 1 } if [ $(whoami) != "root" ]; then echo "User doesn't have root privilege to execute the script." echo "Ensure that user have root privilege and then reissue the command." exit 1 fi # check for empty arguments NBR_ARG=$# if [ $NBR_ARG -eq 0 ] then usage fi # check for help if [ $1 = "-h" ] then


usage2 usage fi # get option siebel_home if [ $1 = "--siebel_home" ] then if [ X$2 = "X" ] then echo "Option 'siebel_home' must be followed by a value" usage else if [ -d "$2" ] then SIEBEL_HOME=$2 else echo "Directory $2 does not exists" exit 1 fi fi else echo "Missing mandatory option 'siebel_home'" usage fi # get option nodes if [ $NBR_ARG -ge 3 ] && [ $3 = "--log_dir" ] then if [ X$4 = "X" ] then echo "Option 'log_dir' must be followed by a value" usage else LOG_DIR=$4 fi else echo "Missing mandatory option 'log_dir'" usage fi # get option ip if [ $NBR_ARG -ge 5 ] && [ $5 = "--ip" ] then if [ X$6 = "X" ] then echo "Option 'ip' must be followed by a value" usage else IP=$6 fi else echo "Missing mandatory option 'ip'" usage fi # get option user if [ $NBR_ARG -ge 7 ] && [ $7 = "--user" ] then if [ X$8 = "X" ] then


echo "Option 'user' must be followed by a value" usage else USER=$8 fi else echo "Missing mandatory option 'user'" usage fi # get option group if [ $NBR_ARG -ge 9 ] then if [ $9 = "--group" ] then if [ X${10} = "X" ] then echo "Option 'group' must be followed by a value" usage else GROUP=${10} fi else echo "Invalide option $9" usage fi fi # check if action script exists case $SCRIPT in /*) DIRPATH=$(dirname $SCRIPT) ;; *) DIRPATH=$(dirname $(pwd -P $0)/${0#\.\/}) ;; esac if ! [ -f "$DIRPATH/siebel_gtwy.scr" ]; then echo "The action script $DIRPATH/siebel_gtwy.scr file does not exist." echo "Ensure the action script file exists in the current directory and reissue the command." exit 1 fi # find crs_home CRS_HOME=`awk /crs_home/ /etc/oracle/olr.loc | awk -F"=" '{print $2}'` # Add gtwy-vip # as root if [ X$GROUP = "X" ] then $CRS_HOME/bin/appvipcfg create -network=1 -ip=$IP -vipname=siebel_gtwy_vip -user=$USER >/dev/null 2>&1 else $CRS_HOME/bin/appvipcfg create -network=1 -ip=$IP -vipname=siebel_gtwy_vip -user=$USER -group=$GROUP>/dev/null 2>&1 fi # Set gtwy-vip perms


# The VIP is a root resource. ACLs must be defined to manage the resource # SYNTAX: crsctl setperm resource resource_name -u user:oracle:r-x $CRS_HOME/bin/crsctl setperm res siebel_gtwy_vip -u user:oracle:r-x # add siebel_type $CRS_HOME/bin/crsctl add type siebel_type -basetype cluster_resource -attr "ATTRIBUTE=ACTION_SCRIPT,TYPE=string,DEFAULT_VALUE=$DIRPATH/siebel_gtwy.scr,ATTRIBUTE=SIEBEL_HOME,TYPE=string,FLAGS=REQUIRED,ATTRIBUTE=LOG_DIR,TYPE=string,FLAGS=REQUIRED" # add siebel_gtwy_app if [ X$GROUP = "X" ] then GROUP="root" fi $CRS_HOME/bin/crsctl add resource siebel_gtwy_app -type siebel_type -attr "ACL='owner:$USER:rwx,pgrp:$GROUP:r-x,other::r--',SIEBEL_HOME=$SIEBEL_HOME,LOG_DIR=$LOG_DIR,CHECK_INTERVAL=30,RESTART_ATTEMPTS=10,START_TIMEOUT=300,STOP_TIMEOUT=300,AUTO_START=restore,START_DEPENDENCIES=hard(siebel_gtwy_vip)pullup:always(siebel_gtwy_vip),STOP_DEPENDENCIES=hard(intermediate:siebel_gtwy_vip)" # status resource $CRS_HOME/bin/crsctl stat res siebel_gtwy_app siebel_gtwy_vip -t echo " " echo "To start Siebel gateway VIP, as root execute:" echo " crsctl start resource siebel_gtwy_vip" echo " " echo "To start Siebel gateway resource, as the Siebel owner execute:" echo " crsctl start resource siebel_gtwy_app" echo " " echo "NOTE: starting the siebel_gtwy_app may pull up the siebel_gtwy_vip" echo " "

APPENDIX B – SIEBEL GATEWAY ACTION SCRIPT SCRIPT

#!/bin/ksh # # This script executes the start, stop, check and clean actions # for the Siebel Gateway Name Server # sieb_gtwy.scr # SCRIPT=$0 ACTION=$1 # Actions (start/stop/check/clean) RET1=1 RETVAL=1 # get SIEBEL_HOME attr CRS_HOME=àwk /crs_home/ /etc/oracle/olr.loc | awk -F"=" '{print $2}'` OUT=`$CRS_HOME/bin/crsctl stat res siebel_gtwy_app -f` SIEBEL_HOME=ècho $OUT | awk -F"SIEBEL_HOME=" '{print $2}'|awk '{print $1;}'` # get LOG_DIR attr LOGDIR=ècho $OUT | awk -F"LOG_DIR=" '{print $2}'|awk '{print $1;}'` LOGDIR="$LOGDIR/siebel_gtwy.log"


case $1 in # Start the gtwysrv process 'start') . $SIEBEL_HOME/siebenv.sh $SIEBEL_HOME/bin/start_ns 1>>/$LOGDIR 2>&1 RET1=$? if [ ${RET1:-0} -eq 0 ]; then RETVAL=0 else RETVAL=1 fi ;; # Stop the gtwysrv process 'stop') . $SIEBEL_HOME/siebenv.sh $SIEBEL_HOME/bin/stop_ns 1>>/$LOGDIR 2>&1 RET1=$? if [ ${RET1:-0} -eq 0 ]; then RETVAL=0 else RETVAL=1 fi ;; # Check for gtwyns process is running 'check') . $SIEBEL_HOME/siebenv.sh $SIEBEL_HOME/bin/check_ns 1>>/$LOGDIR 2>&1 exit $? ;; # Clean gtwyns process 'clean') . $SIEBEL_HOME/siebenv.sh $SIEBEL_HOME/bin/stop_ns 1>>/$LOGDIR 2>&1 RET1=$? if [ ${RET1:-0} -eq 0 ]; then RETVAL=0 elif [ ${RET1:-0} -eq 1 ]; then RETVAL=0 fi ;; # invalid action *) echo "usage: $0 {start | stop | check | clean}" ;; esac if [ $RETVAL -eq 0 ]; then exit 0 else exit 1 fi


APPENDIX C – SIEBEL GATEWAY CHECK ACTION SCRIPT

#!/bin/ksh # # This is the check action script called by sieb_gtwy.scr # This script executes a light weight check action based # on process ps output existence of siebsvc and-or gtwyns # check_ns called from sieb_gtwy.scr action script. # This script should be placed in the $SIEBEL_HOME # directory defined for the sieb_gtwy.scr action script # USAGE="usage: check_ns [-r <siebel root>] " PS=/bin/ps ## set variables used in siebctl command below ## SVCNAME=gtwyns CLSAGFW_ONLINE=0; CLSAGFW_UNPLANNED_OFFLINE=1; CLSAGFW_PLANNED_OFFLINE=2; CLSAGFW_UNKNOWN=3; ## make sure that SIEBEL_ROOT is set (either from command line or ## environment) ## if [ "X$SIEBEL_ROOT" = "X" ] then print "The Siebel root directory must be specified using the \"-r\" switch" print "or the SIEBEL_ROOT environment variable" print "$USAGE" exit 1 fi ## make sure no more arguments were specified ## if [ "X$*" != "X" ] then print "Unexpected argument(s): $*" print "$USAGE" exit 1 fi # check if the gateway is already running running_gtwy=`$PS -ef | grep siebsvc | grep gtwyns 2> /dev/null` if [ "X$running_gtwy" = "X" ] then print "Gateway resoure=$_CRS_NAME is UNPLANNED_OFFLINE" print "service=$SVCNAME is UNPLANNED_OFFLINE" return $CLSAGFW_UNPLANNED_OFFLINE else print "Gateway resoure=$_CRS_NAME is ONLINE" print "service=$SVCNAME is ONLINE" return $CLSAGFW_ONLINE fi


APPENDIX D – SIEBEL SERVER RESOURCE CREATE SCRIPT

#!/bin/ksh # # This script: # Creates Siebel SERVER VIP, sieb_srv_vip. # Sets the correct ACLs on sieb_srv_vip # Creates the Siebel Server Resource TYPE siebel_srv_type. # Adds the Siebel SERVER APP, seib_srv_app # Executes status on these two resources, sieb_srv_vip and sieb_srv_app # after this script exits. # create_sieb_srv_res.sh # SCRIPT=$0 ACTION=$1 IP="" SIEBEL_HOME="" LOG_DIR="" USER="" GROUP="" usage2() { echo "Creates Siebel Virtual IP, resource type, and server resource " echo "Root privilege is required" echo " " } usage() { echo "Usage: $0 " echo " --siebel_home <siebel_home> Siebel home directory" echo " --log_dir <log_dir> Location of the log file" echo " --ip <ip_address> IP address" echo " --user <user> Operating System user name that owns the instance" echo " --group <group> (Optional) Name of the group to which the " echo " Operating System user belongs" exit 1 } if [ $(whoami) != "root" ]; then echo "User doesn't have root privilege to execute the script." echo "Ensure that user have root privilege and then reissue the command." exit 1 fi # check for empty arguments NBR_ARG=$# if [ $NBR_ARG -eq 0 ] then usage fi # check for help if [ $1 = "-h" ]


then usage2 usage fi # get option siebel_home if [ $1 = "--siebel_home" ] then if [ X$2 = "X" ] then echo "Option 'siebel_home' must be followed by a value" usage else if [ -d "$2" ] then SIEBEL_HOME=$2 else echo "Directory $2 does not exists" exit 1 fi fi else echo "Missing mandatory option 'siebel_home'" usage fi # get option nodes if [ $NBR_ARG -ge 3 ] && [ $3 = "--log_dir" ] then if [ X$4 = "X" ] then echo "Option 'log_dir' must be followed by a value" usage else LOG_DIR=$4 fi else echo "Missing mandatory option 'log_dir'" usage fi # get option ip if [ $NBR_ARG -ge 5 ] && [ $5 = "--ip" ] then if [ X$6 = "X" ] then echo "Option 'ip' must be followed by a value" usage else IP=$6 fi else echo "Missing mandatory option 'ip'" usage fi # get option user if [ $NBR_ARG -ge 7 ] && [ $7 = "--user" ] then if [ X$8 = "X" ]


then echo "Option 'user' must be followed by a value" usage else USER=$8 fi else echo "Missing mandatory option 'user'" usage fi # get option group if [ $NBR_ARG -ge 9 ] then if [ $9 = "--group" ] then if [ X${10} = "X" ] then echo "Option 'group' must be followed by a value" usage else GROUP=${10} fi else echo "Invalide option $9" usage fi fi # check if action script exists case $SCRIPT in /*) DIRPATH=$(dirname $SCRIPT) ;; *) DIRPATH=$(dirname $(pwd -P $0)/${0#\.\/}) ;; esac if ! [ -f "$DIRPATH/siebel_gtwy.scr" ]; then echo "The action script $DIRPATH/siebel_srv.scr file does not exist." echo "Ensure the action script file exists in the current directory and reissue the command." exit 1 fi # find crs_home CRS_HOME=`awk /crs_home/ /etc/oracle/olr.loc | awk -F"=" '{print $2}'` # Add srv-vip # as root if [ X$GROUP = "X" ] then $CRS_HOME/bin/appvipcfg create -network=1 -ip=$IP -vipname=siebel_srv_vip -user=$USER >/dev/null 2>&1 else $CRS_HOME/bin/appvipcfg create -network=1 -ip=$IP -vipname=siebel_srv_vip -user=$USER -group=$GROUP>/dev/null 2>&1 fi


# Set srv-vip perms # The VIP is a root resource. ACLs must be defined to manage the resource # SYNTAX: crsctl setperm resource resource_name -u user:oracle:r-x $CRS_HOME/bin/crsctl setperm res siebel_srv_vip -u user:oracle:r-x # add siebel_type $CRS_HOME/bin/crsctl add type siebel_srv_type -basetype cluster_resource -attr "ATTRIBUTE=ACTION_SCRIPT,TYPE=string,DEFAULT_VALUE=$DIRPATH/siebel_srv.scr,ATTRIBUTE=SIEBEL_HOME,TYPE=string,FLAGS=REQUIRED,ATTRIBUTE=LOG_DIR,TYPE=string,FLAGS=REQUIRED" # add siebel_srv_app if [ X$GROUP = "X" ] then GROUP="root" fi $CRS_HOME/bin/crsctl add resource siebel_srv_app -type siebel_type -attr "ACL='owner:$USER:rwx,pgrp:$GROUP:r-x,other::r--',SIEBEL_HOME=$SIEBEL_HOME,LOG_DIR=$LOG_DIR,CHECK_INTERVAL=30,RESTART_ATTEMPTS=10,START_TIMEOUT=300,STOP_TIMEOUT=300,AUTO_START=restore,START_DEPENDENCIES=hard(siebel_srv_vip)pullup:always(siebel_srv_vip),STOP_DEPENDENCIES=hard(intermediate:siebel_srv_vip)" NEED DEPENDENCY ON GTWY

# status resource $CRS_HOME/bin/crsctl stat res siebel_srv_app siebel_srv_vip -t echo " " echo "To start Siebel Server VIP, as root execute:" echo " crsctl start resource siebel_srv_vip" echo " " echo "To start Siebel gateway resource, as the Siebel owner execute:" echo " crsctl start resource siebel_srv_app" echo " " echo "NOTE: starting the siebel_srv_app may pull up the siebel_srv_vip" echo " "

Providing High Availability for Siebel CRM Applications

December 2007, Version 1.6

Author: John P. McHugh

Contributing Authors: Jonathan Pham, Andrey Gusev, Philip Newlan, Roland Knapp

Kelly Tan, Markus Michalewicz, Bhaskar Gupta

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

oracle.com

Copyright © 2007, Oracle Corporation and/or its affiliates. All rights reserved.

This document is provided for information purposes only and the

contents hereof are subject to change without notice.

This document is not warranted to be error-free, nor subject to any

other warranties or conditions, whether expressed orally or implied

in law, including implied warranties and conditions of merchantability

or fitness for a particular purpose. We specifically disclaim any

liability with respect to this document and no contractual obligations

are formed either directly or indirectly by this document. This document

may not be reproduced or transmitted in any form or by any means,

electronic or mechanical, for any purpose, without our prior written permission.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates.

Other names may be trademarks of their respective owners.

siebel crm 8.0/8.1 applications protected by oracle ... · pdf filesiebel crm applications...

Documents