White Paper

Best Practices for Application Configuration

Deployment in Siebel 7.7 and Siebel 7.8

October 2005
Table of Contents

Introduction 1

Section One 3
Planning & Analysis 4
Define Changes 5
Configure Changes 5
Package Changes 7
Deploy/Activate Changes 7
Testing 8

Section Two 10
Deployment Details for Each Change Category 10
Repository Objects—General 10
Repository—Compiled 11
Repository—Non-Compiled 12
Repository—Additive and Non-Additive Schema 14
Authored Data by Business Users or Administrator 17

Section Three 19
Techniques to Reduce Downtime During Deployment 19
Repository 19
Schema 21
Run-time Customizations—Additions/Updates to Current Logic 22
Authored Data by Business Users or Administrators 22

Appendix One 23
Deployment Scenarios 23

Appendix Two 27
Deployment/Activation Summary for Common Configuration Areas
for Release 7.7 and 7.8 27
W H I T E PA P E R

Introduction

This document describes the best practices for application configuration deployment in a
Siebel 7.7 or Siebel 7.8 environment, and focuses on the procedures to package, deploy, and
activate a customized Siebel application. While an overall change management process may
be used, this document addresses the process for deploying an approved and implemented
change request from a development environment to a test or production environment.

The primary audience for this document includes IT leads and managers responsible for
deploying and migrating operations against Siebel environments. Useful information is
also included for development leads and managers to help them participate in deploy-
ment planning and execution. Content in this document is limited to the deployment to
a Siebel Enterprise and does not cover other deployment options such as mobile clients or
handheld clients.

This document details the following:

• The high-level process flow associated with managing a change request
• Deployment management details for the common change categories
• Techniques to help minimize downtime during deployment

Appendix One offers a sample deployment scenario to help clarify the process further.

Appendix Two includes a table that lists common configuration areas, along with
deployment-related information.

You should use this document in conjunction with the following books from the Siebel 7.7
and Siebel 7.8 bookshelves:
• Going Live with Siebel Business Applications
• Configuring Siebel Business Applications
• Using Siebel Tools
• Siebel Enterprise Integration Manager Administration Guide
• Applications Administration Guide
• Siebel Reports Administration Guide
• Testing Siebel Business Applications
• Technical notes referenced in this document

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
1
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Using a Non-Standard Change Request, you should have Siebel Expert Services review
the following:
• New indexes
• Docking visibility changes
• Non-standard changes to the data model
• Non-standard ways to minimize the downtime from deployment
• Performance Tuning
• Architecture Review

This document discusses changes relevant only in the Siebel environment, and it does
not point out any external interface issues that need to be addressed.

The following list of terms used within this document are specific to the deployment of
Siebel application changes:
• Change Request: A logical entity that represents the reason behind performing a change
to the application functionality. It might be created using a change management system
or created and tracked using other means.
• Categories: Within Siebel applications, customized objects are organized into different
categories based on their physical nature, deployment behavior, and tools in use. For
example, objects that reside within the Siebel Repository are considered a category of
objects called Repository Objects.
• Run-time Customizations: Within Siebel applications, these are normally records in
the Siebel run-time database that are configured or customized by developers and
Siebel administrators to influence the application’s functionality. Run-time customiza-
tions also include values that drive the business execution within production for items
like list of values and assignment rules. Run-time customizations are considered one
change category.
• Schema Synchronization: This is a step within the Siebel Repository migration process
that applies the customized schema objects in the repository to the database.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
2
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Section One

A process flow typically associated with managing a change request in a Siebel environment
is described in Figure 1, below.

�����������������

���������� ������
��������� ������� ������ �������� ����
�������� ����������

�����������������
�� ������������������������������������������������������➔����������������������
� ��������������������������������������������������������

����������������������������
�� ����������������������������������������������������������

�����������������������
�� ��������������������������������������������������

������������������
�� ���������������������

����������������
�� ���������������������������������������������������������������������������

���������������
�� ����������������������������������������������������������������������������������

�����������������
�� ��������������������������������������������������������������������������������������
� ����������������������������������������������������������������������������������
� ����������������������

Figure 1. Process flow associated with managing a change request in a Siebel 7.7 or
Siebel 7.8 environment.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
3
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

The following sections give an overview of the steps in the process flow outlined in Figure 1.

Planning & Analysis

First, you must clearly define and document the business requirements for the change
request, as well as identify its business impact. For example, end users may need to make
changes to an existing business process or adapt to changes in the user interface and business
logic. The next step is to map the business requirements to technical requirements as follows:
• Identify the changes to the application configuration
• Identify resources required to implement the changes
• Identify the required time to implement the changes
• Define the scope of the changes
• Document the high-level design for the change request

Be sure to analyze the impact on the data model and existing interfaces and consider the
impact to performance from these changes to the application. Although performance-related
configurations are not covered in this document, custom scripts (server level) are an exam-
ple of what to consider when looking at performance impact. Consider changes to scripts
based on frequently called events as well as logic acting on large amounts of data. Discuss
the performance with business users and document acceptable key performance indicators
(KPIs). KPIs are a set of metrics that can be established to define the acceptable performance
characteristics for a given functionality.

In this phase a Deployment Item List should also be created. This list contains a record for
each item that must be packaged and deployed to capture the necessary customizations
associated with the change request. It can also contain additional deployment-related
information such as deployment technique to use, any deployment prerequisites, ownership,
approvals, and so on. It is important to keep this list up to date and to add additional details
as they emerge during the course of the project. The list is not only used to make sure that
all customizations are being deployed, but it is also used to plan the deployment process and
any automated steps. You can track the Deployment Item List with the Siebel 7.8 change
management functionality, through a third-party change management system, or manually
in a spreadsheet.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
4
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Define Changes
Based on the high-level design document, identify the required changes to the repository,
run-time customizations and configuration files. For example, repository changes may
involve creating a new join, creating a new field, or changing the property of an existing
field for an existing business component. Subsequently, perform a dependency check in
Siebel Tools to make sure all dependent objects also reflect the changes made to the business
component. Identify any required changes to external system integration, detail the resource
plan for each component of the change request, and then create a more detailed design
document. From this, you can define a test plan based on the detailed design. Be sure to
update the Deployment Item List as needed with any changes or additions you make.

Configure Changes
Before making any changes, make sure that the affected objects are backed up or that
there is another mechanism to track the history of the changes (for example, using a
source code control management system) to enable you to recover an object to a prior
version if necessary.

Using the design from the prior stage, make the configuration changes as required. Based on
the categories of changes needed for each design, review Table 1 to identify the configuration
tool to be used.

The deployment management details for each change category in the following table are
described in Section Two, “Deployment Details for Each Change Category.”

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
5
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Change Category Sub-Category Examples Configuration Tool

Repository Objects Compiled • UI Level: Applet, Application, Siebel Tools
Screen, View, Web Template,
Report (New Reports, Report
Name Changes)
• Bus Object Level: Business
Component, Business Object,
Business Service, Link, Pick
List, Integration Object
• DB Layer: Table

Non-Compiled Workflow Policy Objects, Workflow Siebel Tools

Processes, Reports Objects (gener-
ated into Report Object Library,
.ROL, file)

Schema Additive • New Table: Add new column, Siebel Tools

new non-unique index
• Existing Table: Add null
column, not null column;
Increase char/varchar/numeric
column size
Add non-unique index; Alter non-
unique index

Non-Additive • Change column default, null Siebel Tools

to not null column, not null to
null column
• Change column type char to
varchar, varchar to char
• Decrease column size
Files On Siebel Server Web Templates, Style Sheets, Manual, Third-Party
(webmaster and Images, Reports for Proposal Tools
reports) Generator

On Reports Report Executables (.rox), String Third-Party Applica-

Server Translation Files for Reports (.txt) tion (Actuate e.Report
Designer Professional)

Run-time Additions of new Additions of new (or updates to Developer Client

Customizations logic or updates existing) Personalization Rules, (dedicated client in 7.7)
to current logic State Model, Workflow Policies,
SmartScripts and Assignment
Manager Rules

Authored Data File-based Solutions, Literature Siebel Admin Views

(by Business Users, Content and third-party tools
Administrators) to modify file-based
content

Run-time Data Products, Product Catalog, Price Siebel Admin Views

Lists, Workspace Projects
Table 1: Change categories, examples, and configuration tools.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
6
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Package Changes
After the configuration of all the changes associated with the change request has been
completed, the respective customized items are packaged according to the deployment
item list. “Packaging” here refers to identifying and exporting the customizations to file.
For example, you can:
• Export the repository containing the repository changes using the Database
Configuration Utility.
• Export the changes to the run-time data customizations using the Application
Deployment Manager (ADM) or Enterprise Integration Manager (EIM), combined
with export of the interface tables.
• Compile the repository objects into the run-time SRF (Siebel Repository File) and
generate the browser scripts as needed.

All the steps above can be executed interactively from a script or through a command line.
See Section Two, “Deployment Details for Each Change Category” for details.

It is recommended that you store and track the packaged customizations in a secure manner
along with the deployment item list—for example, in a source code control management
system or in a secure place in the file system with controlled access privileges.

Deploy/Activate Changes
Before deployment, make sure that repository objects, run-time customizations, and files in
the target environment are backed up. Figure 2 shows the high-level steps and the order in
which the various change categories are brought into the target environment.

����������������������� ������������� ��������� �������������������

� ������������� � ���������� � ������� � ������
� ��������� � ������������� � ������� � ��������������
� �������������������������� � � � ���������� � ��������������
� ����������������������� � ����������� � ������ � ��������
� �������������������������� � ������� � ��������������������
� ���������������� � ����������� � � ����
� ����������
����������������������� �����������������������
� ��������������������
��� ����������������������� � ���������������������
� ��������������������� � � �����
��� �������������
� ��������������������������

��������������� ��������������

Figure 2. Change categories and the order in which they are executed.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
7
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

There can also be dependencies between individual items that will dictate the order in
which they must be deployed (both across change categories as well as within a category).
For example, if a new State Model is developed for which a set of new list of values (LOV)
has also been created, then the LOV definitions must be deployed first because the LOVs
referenced in the state model will be validated against the LOV definitions in the database
on import. It is important to identify these dependencies ahead of time and to test the
deployment process of the collective changes in a test environment before moving into
production. The deployment sequence for run-time customizations supported by ADM
can be controlled by establishing data type relationships in the ADM Administration view.
See the “Migrating Customizations Between Applications” section in Going Live with Siebel
Business Applications for documentation on using ADM.

It is recommended that you automate the deployment/activation process as much as pos-

sible (for example, using the ADM custom scripts) to make sure that the same deployment
process performed in the test environment is repeated in the production environment. This
helps to achieve a high-quality deployment and also helps minimize downtime. See Alert
2012 on how the Repository Migration task can be run unattended.

The actual deployment and activation of each customization may require a different tool
or mechanism. See Section Two, “Deployment Details for Each Change Category” and
Appendix Two to identify the necessary deployment tools and activation steps needed.

Testing
In this phase all changes made as part of the change request are tested before rolling out any
changes to the production environment. The main objectives of this phase are to make sure
the functionality of the implemented customizations are verified and have not adversely
affected prior functionality. Run the test plans you created to test the changes in a separate
test environment. Make sure that the test plans cover testing of integration with any external
systems. Also, be sure to validate that the key performance indicators (KPIs) are met. Note
that for a major release it is recommended that performance testing is performed in a “pro-
duction-like” environment before deploying into actual production—for example, a scaled-
down version of the production system.

Be sure to follow the Deployment Item List and the associated deployment process devel-
oped for the production system when deploying into the test environment. This ensures that
the results will be the same when you later deploy into the production environment.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
8
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Use the test results to make any further configuration changes or corrective changes in the
development environment. Hence, the development and testing phases may be iterative until
you get the desired results from testing. Be sure to update the Deployment Item List accord-
ingly and to use the updated list when you redeploy before the next test cycle.

You may automate the testing of application functionality and performance using the test
automation APIs. See Testing Siebel Business Applications for details and license require-
ments. For customer order management objects, you can use the Scenario Tester to simulate
a post-deployment environment.

After deploying into the production environment, perform a limited set of tests—often
referred to as user acceptance tests—to verify the new functionality and make sure all the
customizations were correctly deployed.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
9
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Section Two

Deployment Details for Each Change Category

The sections below describe the deployment management details for different change cat-
egories (see Table 1). See also Appendix Two for a summary of deployment- and activation-
related information for common configuration areas.

Repository Objects—General
The repository objects are divided into three main categories from a deployment
perspective:
• Compiled objects
• Schema objects (these are also compiled, but they require an additional database
synchronization step)
• Non-compiled objects

Details on the three different categories are described in the following sections. However,
for all three categories, the repository objects themselves are generally migrated together
using one process. The compiled objects, including schema objects, are compiled into one
file accessed by the Siebel application server at runtime, the Siebel Repository File (SRF).
The general packaging/deployment process for the repository and SRF is described in this
section. Exceptions are noted in the detailed sections below.

Packaging/Deployment
Repository—Export the repository containing the changes to file using the Database
Configuration Utility. Note that you perform this export only after the development team
has acknowledged that the customizations are ready for deployment. The exported reposi-
tory file is migrated into the test or production environment using the Repository Migration
process. This migration process also includes the step to apply the schema changes within
the repository to the database and execute them as part of the migration. It is recommended
that you perform this step whether or not the new repository contains schema changes.

The repository deployment step is considered complete once it has been imported to the
target database and given a name known to the Siebel Enterprise.

For information on the Database Configuration Utility, see the “Managing Repositories”
section in Using Siebel Tools. For information on the Repository Migration Utility, see
the “Migrating Repositories Between Databases” section in Going Live with Siebel
Business Applications.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
10
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

SRF and Browser Scripts—Use Siebel Tools to compile the SRF files from the repository
containing the changes. You must compile a separate SRF for each language to be supported.
A full compile is recommended when deploying to test or production environments. Also,
note that Siebel Tools’ SRF compilation requires binary sort setting in the database, so the
SRF cannot be compiled from a database with a dictionary sort setting. The SRF files must
be copied to the objects directory on all the Siebel application servers while the servers are
off line. While compiling the SRF, you can generate any browser scripts. Update the scripting
options in Siebel Tools to point to a directory of your choice where the browser scripts will
be created (this is a one-time step). You must then copy the browser scripts to the webmaster
directory on each Siebel Server.

For information about compiling .SRF files and generating browser scripts, see Using Siebel
Tools on the Siebel Bookshelf.

Activation—The deployment consisted of the repository, SRF file and the browser scripts.
For the new repository and SRF to take effect, the application servers must be restarted. To
activate the browser scripts, either restart the Web servers or issue the UpdateWebImages
SWE command. For details, see FAQ 2104: How Do You Deploy Customized Images, Style
Sheets, Help Files, and Scripts To Your Web Servers? and the “Configuring for Security:
Overview” section in the Security Guide for Siebel Business Applications.

Repository—Compiled
Changes to UI objects, business objects, business components, integration objects, and
tables require you to recompile the .SRF file. The repository itself must also be migrated
to the target environment along with the .SRF. See the previous section on compiling and
deploying the .SRF and migrating the repository.

Note that changes to the compiled objects often have interdependencies with other types
of customizations. For example, if a business service is part of one or more new workflow
processes, remember to also deploy these workflow processes from development to test or
production environment (see the “Workflow Process” subsection in Section Three).

Changes to the integration object structure are also associated with changes in other busi-
ness layer objects, as well as integration run-time settings relating to EAI (Enterprise Appli-
cation Integration). As part of putting the new object structure into effect, all synchronous
interfaces affected by the deployment are stopped and started (through the server restart),
which may also directly affect any associated external systems.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
11
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Repository—Non-Compiled
Certain objects in the repository are not compiled into the .SRF, but are either accessed
directly from the repository at runtime or used by other objects during the design and
packaging—for example, reports objects exported into Reports .ROL. The noncompiled
objects are usually deployed together as part of the overall repository migration. Alterna-
tive deployment steps for certain types are noted in the following sections.

Workflow Policy Objects

Changes: Changes to Workflow Policy objects, Workflow Policy columns or Workflow Policy
programs are considered major functionality changes because they drastically change an
existing object or add new objects for policy support. You make these changes using Siebel
Tools and access them directly from the repository during runtime by the Siebel application.

Packaging/Deployment: See the “Repository Objects—General” section.

Activation: When rolling out changes to the Workflow Policy objects in the repository,
you must restart the Workflow Monitor Agent (WorkMon) server component to make the
changes take effect. However, because the configuration changes reside within the repository,
typically the application servers themselves (not just the Workflow Monitor Agent com-
ponent) will need to be restarted to put the new repository in effect. If the rollout includes
changes to existing Workflow Policy objects you must make sure that the current outstand-
ing requests have been processed through the older (current) configurations before the
WorkMon component is shut down.

Any changes made to the Workflow Policy conditions in the run-time customization will
also require the database triggers to be regenerated through the Generate Triggers (GenTrig)
server component unless the Workflow Policy has “batch flag” set to TRUE, or if the changes
are limited to the Workflow Policy actions. In all cases, you must restart the workflow moni-
tor and action agents for the affected groups. See the “Workflow Policy” section in Siebel
Business Process Designer Administration Guide.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
12
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Workflow Processes
Changes to Workflow Processes: Configuration changes to Workflow Process definitions in
the repository are made in the repository using Siebel Tools.

Packaging/Deployment: To migrate the changes to a target environment, use the UI Work-

flow Process export/import in Siebel Tools, the Workflow Admin Service business service,
or the Repository Migration process as part of migrating the entire repository. After the
Workflow Processes are imported, click Deploy in Siebel Tools to mark Workflow Process as
completed and ready for activation. The Deploy button allows the processes to be activated
in the following step. The Workflow Admin Service business service in Siebel 7.8 could be
used to import, deploy, and activate Workflow Processes in bulk.

The UI method is documented in the Siebel Business Process Designer Administration Guide.

Summary steps are as follows:

• Copy or import the Workflow Processes into the target repository using any of the three
methods mentioned above.
• Click Deploy for each Workflow Process within the Siebel Tools UI.

Activation: A newly deployed Workflow Process must be activated using either the Siebel
run-time client or the Workflow Admin Service business service (see the previous section for
Siebel Bookshelf references). The business service provides the additional benefit of activat-
ing all the customized processes in one step. In addition, note that the new definitions of the
Workflow Processes will not start executing until the activation step is complete.

Reports (Objects generated into .ROL file)

You can make functional and structural changes to existing report objects, such as adding
new columns or adding one or more subreports. See Siebel Reports Administration Guide
for details.

Changes: Make changes to reports using Siebel Tools. You need to generate an .ROL file for
each report object that has been modified, using the Generate Actuate Report option in the
Tools menu in Siebel Tools.

Packaging/Deployment: No changes specific to Siebel need to be packaged. However, you

must regenerate the report executable (.ROX) from the new .ROL file using the Actuate
e.Report Designer Professional. This report executable (.ROX) file is then migrated to the
Actuate Reports Server using Actuate Management Console.

Activation: There is no actual activation step, but the new report will take effect for all new
requests after it is deployed in the Actuate Reports Server.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
13
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Assignment Manager Objects

Changes to Assignment Manager Criteria, Attribute and Assignment Object (child-object
to Workflow Policy Object): The Assignment Manager objects are stored in the repository and
changes are made using Siebel Tools.

Packaging/Deployment: Note that although these objects are accessed directly from the
repository in the database at runtime, for most changes to Criteria and Attributes you will
also need to recompile the SRF because it is used by the Assignment Manager Administra-
tion views. See Siebel Assignment Manager Admininstration Guide for details.

Activation: When rolling out changes to the Assignment Manager repository objects, you
must restart the Assignment Manager server component to make the changes take effect.
However, because the configuration changes reside within the repository, you must restart
the application servers themselves, and not only the Assignment Manager component, to put
the new repository in effect.

If any run-time customization changes have also been made to Assignment Policies in
the run-time database, you must restart the Workflow Monitor Agent for the Assignment
Manager and regenerate the database triggers through the Generate Triggers (GenTrig)
server component. Also, if any changes have been made to Assignment Manager Rules in
the run-time customization, you must refresh the Assignment Manager’s rules cache by
releasing the new rules from the Assignment Manager Rules Administration view. Note
that any currently executing Assignment Manager tasks will continue to use the old rules
until the tasks are completed.

See the Server Administration Requirements After Configuration section in Siebel

Assignment Manager Administration Guide for additional deployment-related
details for Assignment Manager.

Repository—Additive and Non-Additive Schema

Customers may make additive or non-additive changes to the database schema (see Table
1 for detailed examples). The standard deployment process for both types of change is the
same (see also Section Three, “Techniques to Reduce Downtime during Deployment”).

Changes: Additive changes include extending the schema by adding tables, columns, or
non-unique indexes, and mapping these extensions to the business objects layer and UI
layer. Non-additive changes include changing the column default, changing the column
from null to not-null, and so on. The changes to the schema definition objects are made
using Siebel Tools.

Packaging/Deployment: See Section Two, “Repository Objects-General.”

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
14
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Activation: After the repository has been imported during the deployment step to the target
environment, you must synchronize the schema changes to the physical database while the
system is off line. You can do this synchronization as a step of the Repository Migration
process or you can do it separately. The Repository Migration process runs from the Siebel
Server installation directory and connects directly to the database. It does not depend on the
actual server processes and infrastructure, but the database requires that the physical objects
to be modified are not used by any other user processes. During the schema synchronization
step the Repository Migration process generates a DDL file to be applied to the database that
updates the physical schema to match the repository schema object definition. Consult with
your DBA to review the DDL and determine the outage window. If your database platform
is on z/OS, review the Siebel documentation carefully for additional steps that are specific to
this platform.

The activation of the schema customizations is considered complete once the schema
synchronization step has completed successfully and the Siebel Server has been restarted
to use the newly imported repository.

More About Schema Synchronization: This is a step within the Repository Migration
process that is also known as “DDLSync.” During this step any customizations done
to the Tables object in Siebel Tools are applied to the database schema. This application
is done through an internal Siebel utility called ddlimp.exe. This utility compares the
schema customizations (Table object) in a given repository and alters the objects in the
database schema to match the repository by issuing SQL commands. These commands
are usually not visible to the end user.

Files on the Siebel Server

As part of the application configuration you may need to customize the UI (layout/format)
through changes to Web templates, images, or style sheets. You may also need to change or
add report files used by the Proposal Generator.

Changes: Changes to Web templates and style sheets provided by Siebel Systems are
typically made using third-party tools because Siebel Systems does not provide the tools
to modify them.

Packaging/Deployment: Siebel Systems does not provide any specific tools to deploy the
Web templates and style sheets modified by customers. The modified Web templates should
be copied to the Siebel Application Server into the webtempl directory. The modified images,
style sheets, and other UI-related objects should be copied to subdirectories under the web-
master directory. See the “Migrating Repositories Between Databases” and “Post-Repository
Migration Tasks” sections in Going Live with Siebel Business Applications.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
15
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Note that the files under the webmaster directory must be deployed to all application servers
before activation because a Web server may request the newly deployed files from any of the
application servers.

Copy report files used by the Proposal Generator to the Reports directory on all the
application servers.

Activation: For the Web templates changes to take effect, the Siebel Application Servers
must be restarted. For the changes to style sheets and other webmaster files to take effect,
you must restart the Web servers or issue the SWE command UpdateWebImages. Note
that even though the webmaster files eventually reside on the Web server, they are actually
deployed to the Siebel Application Server. More information is available on Siebel Sup-
portWeb in FAQ 2104.

Files on the Reports Server

As part of the application configuration, certain report executables and translation text files
may need to be deployed on the Reports Server. See Siebel Reports Administration Guide for
more details on deploying reports.

Changes: Customers may have modified an existing report or created a new report using
the Actuate e.Report Designer Professional and would like to deploy the resulting executable
(.ROX) on the Reports Server. For multilingual reports, you may have to create or modify a
translation text file (.TXT file) also.

Packaging/Deployment: The deployment tool for .ROX files is the Actuate Management
console that is used to import the report to the Actuate Encyclopedia accessed by the Reports
Server. The .TXT files are copied directly into specified location in the file system on the
Reports Server host. As part of deploying the reports, make sure that the appropriate privi-
leges are assigned.

Activation: There is no actual activation step for either the .ROX file or the .TXT file, but
the changed or the new report will take effect for all new requests after it is deployed to the
Actuate Reports Server.

Run-time Customizations—Additions/Updates to Current Logic

Customers may add or change the configuration to enforce conditions or change logic for
many run-time customization data types.

Changes: For example, customers may add or modify required states for a state model to
meet business requirements. One or more personalization rules may be added or modified
to restrict the visibility of an applet or view based on position. Similarly, SmartScripts may
be added or modified to enhance an employee’s usability or productivity. These changes are
made from the corresponding Administration views in the Siebel Client.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
16
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Packaging/Deployment: You can use the Application Deployment Manager (ADM), EIM,
or export/import from the Siebel Client Administration views for packaging and deploying
run-time customizations depending on the type. (See Appendix Two for deployment
information on different types.) Note also that you can extend types supported by ADM
by creating custom ADM Integration Objects/Content Objects. Types using file attachments
are supported by ADM from Siebel 7.8—for example, Literature, Correspondence
Templates, and so on.

Refer to the following documentation for additional information:

• ADM—the Migrating Customizations Between Applications section in Going Live with
Siebel Business Applications
• Siebel Enterprise Integration Manager Administration Guide
• Applications Administration Guide for different features (workflow, Assignment Manager,
and so on)

Activation: Many of the run-time customizations require an activation step, but not all. See
Appendix Two for activation steps for different types. Note also that the availability of some
run-time customizations are governed also by a publish/active flag, or active/expiration date.
See the Applications Administration Guide for details.

Note: You might have to update the ADM Batch Import workflow process to set the file import
directory. This is the directory from which ADM will read the XML files. Also, make sure the
ADM workflow process is set to active in the application UI (this is a one-time step when you
refresh the database).

Authored Data by Business Users or Administrator

Customers may add or change authored data to manage the content for certain business
functions. Note that in some organizations the business users manage these changes directly
in the production environment. In other organizations the changes are first created and
tested in a development or test environment and then later deployed to the production
environment by an administrator.

Changes: For example, customers may add or modify Solutions and Literature used as sales
tools by the sales force. Similarly, Product Catalog and Price Lists used for order manage-
ment could be added or modified.

Packaging/Deployment: For Customer Order Management, Workspace Projects offer a

different level of packaging for versioned objects. Versioned objects can be grouped into a
Workspace Project, which then can be deployed through ADM as one of its supported types.

Other objects representing authored data are deployed in the same way as the run-time
customizations referenced in the previous section.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
17
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Activation: Versioned objects in Customer Order Management require being “released”

starting on either the current or a specific date before they can be used in production. Also,
many of the non-versioned data in Customer Order Management requires its specific cache
to be refreshed after deployment. Note that you can automate these operations using the
Siebel API documented in the Product Data Service and Import/Export API Reference
bookshelf guide.

There is usually no actual deployment activation step for other areas, but note that the avail-
ability of many authored data areas is controlled by a published/active flag, and so on, and
requires coordination with external business-driven events and processes.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
18
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Section Three

Techniques to Reduce Downtime During Deployment

While the deployment of any typical set of configuration changes will require taking the
system off line for at least a brief period, there are several techniques that can minimize the
downtime. These techniques depend on the changes deployed, the system environment, and
other factors. The following sections describe some techniques to reduce the downtime for
individual change categories.

The impact from the system downtime may be different for each deployed customization.
By deploying the customizations of a change request in parallel you may be able to mini-
mize the total downtime further. To illustrate the deployment of customizations related to a
change request, an example is given in Appendix One.

Note: Authored data and run-time customizations could be rolled out to a live system, but be
careful to analyze the nature of the customizations and their dependencies. A simple case would
involve the rollout of one object while a more complex case would involve the rollout of vari-
ous objects that are interdependent. In the latter case, the child objects must be deployed first,
followed by the parent objects. During the short deployment window, the system is likely to serve
an incomplete set of customizations to end users. Such situations might result in severe run-time
errors and, in extreme cases, data corruption.

Repository
(See Table 1 for detailed examples.)
You can import the repository containing the changes into production with a different
name using the Repository Import process as a pre-deployment step—while the system is
still live—to reduce the downtime window. Then, after the system is taken off line during
the deployment window, the pre-existing repository is renamed and archived, and the
name of the new repository that was just deployed changes to reflect the production name.
The Repository Import is invoked from the Database Configuration Utility.

Similarly, you can copy the recompiled .SRF file containing the changes with a different
name into the live production environment and then rename it later once the system is
taken down. Be careful to make sure that the correct .SRF files are in place on all the servers
before bringing the system back up. It is strongly recommended that you automate the
steps to copy, rename, and then verify name and content on the target (for example, by
“diff ” or examining date and size) using scripts to reduce the risk of any deployment errors.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
19
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Integration Objects-Integration Points

Deploying changes affecting integration with external systems should be carefully con-
sidered before deployment. Careful planning and pre-deployment preparation work both
within Siebel Systems and within the external system may be needed to help keep the
downtime to a minimum.

If the change is to add only a new object that uses an existing integration point, then
the downtime of such a change is mainly driven by the deployment of the new .srf. This
assumes the external systems can send in the requests using the new data structure with-
out any significant changes to these systems. If the incoming or outgoing data structure
is changed, it is advisable to allow the current integration operations to come to a natural
completion point across all the involved applications before restarting the system and
using the new data structure. Also, note that the EAI infrastructure is often closely tied
to the Siebel Business Process execution, which you may also need to consider (see the
“Workflow Processes” section that follows and the “Workflow Policy” section in Siebel
Business Process Designer Administration Guide).

Workflow Processes
The following applies if the Workflow Processes are not deployed as part of an overall
repository migration—for example, for a bug fix where only the Workflow Process objects
are affected.

Because Workflow Process definitions are versioned and have an explicit activation step,
you can perform the deployment while the system is still online, after which the activa-
tion is performed once the system is off line or in a quiescent state. Allow the currently
executing logic and/or queues to finish before the newly deployed processes are activated.
See also run-time customizations with explicit activation steps in the section for run-time
customizations below.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
20
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Schema

Additive Schema
(See Table 1 for detailed examples.)
It is highly recommended that you any synchronize any schema changes during a planned
database outage window. However, if the DBA has analyzed the changes in conjunction with
the Siebel Development Lead/Architect and determined that they are purely additive, you
could apply the changes as a separate deployment step before the deployment downtime
period. Note that the pre-deployment step in this case is applying certain schema changes
before hand. These changes are a part of the entire set of schema customizations that must
be deployed to the target environment in its entirety so that the repository, SRF, and schema
objects are matching. Note that the ability to apply changes to the database while it is online
depends on the RDBMS capabilities. Check with your DBA to review the DDL and deter-
mine whether they can be applied online. Assistance from Siebel Expert Services is required
for optimizing schema deployment as described in this scenario.

Non-Additive Schema
(See Table 1 for detailed examples.)
If the business requirement is to reduce downtime to an absolute minimum, additional
tuning may be possible to optimize the schema deployment step. This may involve bypassing
the Siebel program (ddlimp.exe) and manually running highly optimized SQL statements.
This process requires advanced database knowledge as well as a thorough understanding of
the Siebel schema. Assistance from Siebel Expert Services is required for optimizing schema
deployment in this scenario.

Note: This does not mean that the ddlimp.exe used to synchronize the schema does not run
efficient SQL. When optimizing the SQL statements to be executed, this utility does not consider
the size of the tables and other database settings specific to your case.

Files on the Siebel Server

(See Table 1 for detailed examples)
In general, you need to restart the Siebel Application Servers for Web templates changes to
take effect, and you must restart the Web servers or issue a SWE command for changes to
style sheets, images, and other webmaster files to take effect.

One technique to minimize downtime is to automate the deployment by performing the file
copy from scripts. This is to make sure that the copy will happen as quickly as possible to the
various targets, as well as to eliminate the risk of human error. It is also strongly recom-
mended that you develop scripts to automate a post-deployment verification step to make
sure the actual files were successfully deployed to all their destinations (through content diff,
or comparing size/timestamp, and so on).

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
21
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Further, by applying normal load balancing techniques, the end user impact could be
minimal. For example, the changes can be applied to the servers in a “rolling” fashion. This
involves first taking a subset of the servers offline and deploying all the changed files (Web
templates, .SRF, and so on) to these offline servers, but while the remaining servers are still
live. Then, during a short downtime window after the remaining servers are also taken off
line, the newly updated servers can be put back into production. Finally, once the remain-
ing servers are updated, you can put them all back on line. This may involve a temporarily
reduced capacity that needs to be considered as part of the deployment planning (unless
additional hardware is available during the deployment window).

Run-time Customizations—Additions/Updates to Current Logic

(See Table 1 for detailed examples)
A few run-time customization types have an explicit activation step (other than restarting
the component or server). You can deploy configuration changes to these types into the tar-
get environment as a pre-deployment step before taking the system down, after which they
are explicitly activated once the servers are online but before allowing general user access. (If
they are activated solely by restarting the component or server, the risk is that an unplanned
server restart may inadvertently activate the changes and leave the system in an inconsistent
state.) Examples include:
• Workflow Processes (explicit activation in Siebel Client)
• Workflow Policies (expiration date)
• State Models (expiration date)
• iHelp (explicit activation)
• Assignment Manager Rules (explicit activation)

As discussed in the previous “Files on the Siebel Server” section, another technique to mini-
mize the deployment impact for run-time customizations is to use automation. As men-
tioned, automating the deployment process as much as possible ensures that the deployment
steps themselves are efficient and also reduces the risk of human error. You can use ADM or
custom scripts to automate the deployment of run-time customization changes. See Going
Live with Siebel Business Applications for additional information on using ADM.

Authored Data by Business Users or Administrators

(See Table 1 for detailed examples.)
For C/OM objects, you can automate some of the deployment and activation steps using
APIs to reduce manual steps and achieve an efficient deployment process. (See the Product
Data Service and Import/Export API Reference bookshelf for details.) Also, a C/OM Work-
space Project has an explicit activation step that can use the same pre-deployment technique
described in the previous section for run-time customizations.

There is usually no downtime involved when deploying most other authored data.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
22
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Appendix One

Deployment Scenarios
Here is one deployment scenario to help you understand how you can prepare a deploy-
ment from one environment to another. The scenario is referred to as a “major release” and
contains changes to run-time customizations, the Siebel Repository (compiled and non-
compiled), and .SRF files.

Scenario: Major Release

In a major release, significant functionality changes are rolled out to the end users who
might need to be trained on these changes. End users are expected to change their pro-
cesses and their navigation within the application. This release impacts external systems
and requires coordination with other teams for the development and rollout. It is also
expected that the current work queue needs to run through completion before the
deployment can start.

Object Type Packaging Steps Deployment Steps

List of Values Export the objects from the de- Deploy to target database using
velopment system after confirm- ADM, EIM or UI Import.
Responsibility/Views ing functionality. Use ADM, EIM
or UI Export to export to file.
State Model

Assignment Rules only

Smart Scripts

Views

Positions and Organizations

Positions and Organizations

WF Policies

C/OM Workspace Projects

20 new/updated WF Processes Export the repository using the Perform Repository Import
Database Configuration Utility. and apply the physical schema
2000 Repository objects changes using the Repository
Migration process.

Three SRF files (one each for the Run a script to perform the com- Run a script to copy the files to
three languages in the deploy- pilation for the three languages in the application servers while the
ment) and browser scripts a pre-production environment. servers are not running.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
23
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Testing the Deployment Process

It is highly recommended that you test the planned deployment process itself in a test
environment before rolling it out to a production environment. The goal of this testing is
to correct any deployment errors, which may be due to the database, automated scripts, or
other steps in the deployment process. Before reaching this step, it is vital to have executed
the various deployment scripts and commands to some degree of confidence in another
test environment.

The following high-level steps are carried out for testing the deployment process:
1. Refresh the test environment database from the production database, or from a scaled-
down version of the production database.
2. Alter any confidential data as necessary.
3. Perform the deployment steps and run any automated scripts against the test environ-
ment. The full deployment process should be tested, and the target environment startup
and shutdown sequence needs to be the same as expected in production. Be sure to
test any pre-deployment operations that take place before the system is put off line—
for example, turning off system monitoring agents, and so on.
4. Identify any errors in the deployment process and make necessary changes.
5. Repeat from Step 3 above until the operation runs without any errors end-to-end.
6. Perform simple testing on the application to make sure the deployment did include
the intended objects.

Continue with the user acceptance test (UAT) and other tests. Once the testing is satisfactory,
you are ready for the production deployment.

Downtime and Pre-Deployment Considerations

To minimize downtime during the production rollout, the following key points influence the
design of the deployment script:
1. For some of the run-time customizations, pre-deployment can occur because these objects
require a specific activation step other than restarting a component or server. This means
that you can import these objects to the database while the system is still up and activate
them after the system is restarted but before users are allowed into the system. For this
scenario, these objects are as follows:
a. Assignment Rules
b. C/OM Workspace Projects
2. You can perform the repository import step using the Repository Migration process while
the target system is online. Because this operation typically takes between one and two
hours, you could start it one hour before the actual maintenance window. (However, you
still need to restart the system for the new repository to be put into effect.)

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
24
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Based on the information above, you can see deployment of changes as two separate activi-
ties. The first step is the pre-deployment step, and the second is the operations that occur
within the downtime window. Notice that the first step is not as time-critical as the second
and would most likely not occur within a single script, so more control is available during
the deployment.

The following steps are first taken against the test environment before being applied against
the actual production environment. Note that various other pre- and post-deployment steps
are necessary as dictated by your current IT policies. Examples include procedures for user
notification, executive and business change approvals, and IT operational activities regarding
to system changes. These additional steps will impact not only the Siebel environment, but
other integrated applications as well.

Deployment Activities in Test and Production Environments

As mentioned earlier, the steps to follow in the test environment are very similar to the steps
followed in the actual production environment. The steps below are the same for the pro-
duction and test deployment except for Step 1:
1. Prepare the staging environment with production data.
2. Retrieve the packaged deployment customizations and deployment item list from the
source control system or from the server on which you store these (repository dat file,
.SRF, xml files, and so on). Review the deployment item list and verify that all changes
are included and correct.
3. Run the Database Configuration Utility to perform a repository import. Run the reposi-
tory import as “New Custom Repository.”
4. During the repository import, you could start the deployment of the run-time cus-
tomizations for which a specific activation step is necessary. Note that the dedicated
(developer) client can be used to connect directly to the server database for the purpose
of running ADM to import run-time customizations. See also Step 11.
5. At some point during the import, users are notified that they need to terminate their ses-
sions. This is where the system would enter a cool-down window to allow all internally
queued requests to complete (this applies to the workflow process and policies here).
6. Shut down the application servers (effective downtime begins).
7. Rename the original Siebel Repository “Original Siebel Repository” and the new reposi-
tory “Siebel Repository.”
8. Continue to use the Repository Migration process to synchronize the new schema
changes to the physical database.
9. While the schema synchronization process is running, run the script to copy the SRF files
and browser scripts to their respective Siebel Server directories.
10. Restart the application servers after the schema synchronization and the copy of SRF/
browser scripts have completed.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
25
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

11. Unless the run-time customizations have not already been imported using the developer
client, after the environment is up ADM can be invoked using the server manager com-
mand line (or through ADM Admin view) to import the XML files holding the remain-
ing run-time customization changes.
12. After all the configuration changes are deployed, perform any required activation
steps (not necessarily in the following order; in this scenario the activation steps
are independent):
a. Activate the workflow processes from the application UI or through the Workflow
Admin Business Service.
b. Activate C/OM Workspace Projects.
c. Release Assignment Manager Rules.
d. Release SmartScripts.
e. Start the workflow policy monitor agents. These can be started automatically upon
restarting the server by setting the initial task and AutoStart to True and the Default
Tasks to a value larger than zero. These agents are properties of the component defi-
nition. The group name property would have to be set on the component definition
level, which means new tasks for other policy groups would require a new compo-
nent definition or an explicit command to start another monitor agent task.

In this scenario, it is not necessary to restart the environment for the new run-time custom-
izations to take effect. If you need to restart the server to activate other run-time customiza-
tions after they have been imported to the database, then it would be best to perform the
deployment of these objects before the first shutdown step, but after the system is effectively
taken off line—that is, after all user sessions and processes have completed.
1. Test and validate the system before making it available for end users.
2. After the system has been validated, you can export, archive, and then delete the old
repository from the production instance using Siebel Tools after confidence has been
established in the new customizations. Also, to facilitate fixes to the new configuration,
copy the Original Siebel Repository to the development environment for comparison
purposes.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
26
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Appendix Two

Deployment/Activation Summary for Common Configuration Areas

for Release 7.7 and 7.8

Configuration Area Category Deployment Activation Step

Mechanism
Access Control Admin Run-time UI Export/Import None
Customization or Create IntObj
for ADM

Access Groups Run-time ADM None

Customization

Bundle Promotion (C/OM) Run-time ADM (7.8) None

Customization

Bundle Discount (C/OM) Run-time Custom- ADM (7.8) Refresh the cache using
ization the UI button or restart
the server.

Aggregate Discount Sequences Run-time ADM (7.8) Refresh the cache using
(C/OM) Customization the UI button or restart
the server.

Assignment Manager Run-time ADM a. Regenerate triggers if

Customization changing criteria.
b. Restart Workflow
Monitor agent.
c. Release Rules from
the UI through the ap-
plet menu item.

Adjustment Groups (C/OM) Run-time ADM (7.8) Refresh the cache using
Customization the UI button or restart
the server.

Audit Trail Admin Run-time UI Export/Import None

Customization or Create IntObj
for ADM

Correspondence templates Run-time Manually or None

Customization through EIM

Cost List (C/OM) Run-time ADM (7.8) None

Customization

Data Map Object (C/OM) Run-time ADM (7.8) None

Customization

Data Transformation Run-time UI Export/Import Reload Maps. To use

Customization or Create IntObj the maps. In case any
for ADM existing map is updated,
purge the cache.*

Discount and E&C Matrix (C/OM) Run-time ADM (7.8) Refresh the cache using
Customization the UI button or restart
the server.

Dispatch Rule Run-time UI Export/Import Refresh the cache using

Customization or Create IntObj the UI button or restart
for ADM the server.

Correspondence Templates Run-time Manually and EIM None

Customization

Expense Type Run-time ADM None

Customization

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
27
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
 W H I T E PA P E R

Deployment
Configuration Area Category Activation Step
Mechanism
Fund (C/OM) Run-time Customization ADM (7.8) None

iHelp Run-time Customization UI Export/Import Restarting the server has

or Create IntObj no effect. Activate each
for ADM item from the UI using the
Activate button.

Workspace Projects Run-time Customization ADM (7.8) Objects in the workspace

(C/OM) projects need to be released
using the UI button or APIs
with the current (=blank)
or a specific date as the
required start date.

List of Values Run-time Customization ADM Refresh the cache using

the UI button or restart the
server.

Message Type (C/OM) Run-time Customization ADM (7.8) Refresh the cache using
the UI button or restart the
server.

Personalization Rules Run-time Customization UI Export/Import Reload from the Applet

or Create IntObj menu.
for ADM

Predefine Queries Run-time Customization ADM None

Price List (C/OM) Run-time Customization ADM (7.8) Refresh the cache using
the UI button or restart
the server.

Product Catalog (C/OM) Run-time Customization ADM (7.8) Refresh the cache using
the UI button or restart the
server.

Product Data (C/OM) Run-time Customization ADM (7.8) Refresh the cache using
the UI button or restart
the server.

Product Feature (C/OM) Run-time Customization ADM None

Product Line (C/OM) Run-time Customization ADM None

Promotion (C/OM) Run-time Customization ADM (7.8) None

Proposal Templates Run-time Customization Manually or None

through EIM

Report Files File Manually copy .txt None

files / import .rox
files via Actuate
MgmtConsole

Repository Objects Repository Repository Migra- Restart the Siebel servers.

(general) tion process Additional activation is
necessary for schema ob-
jects: Run DDLSync or the
entire Repository Migration
process to synchronize the
schema objects.

Responsibilities Run-time Customization ADM Click the Clear Cache

button from the UI.

Runtime Events Run-time Customization UI Export/Import Reload from the Applet

or Create IntObj menu item.
for ADM

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
28
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
W H I T E PA P E R

Deployment
Configuration Area Category Activation Step
Mechanism
SmartScripts Run-time Customization UI Export/Import Activate from the UI.

SRF File Manually copy to Restart the server.

each server

State Model Run-time Customization ADM None

Symbolic URL Run-time Customization UI Export/Import None

or Create IntObj
for ADM

User List Run-time Customization ADM None

Views Run-time Customization ADM None

Volume Discount (C/OM) Run-time Customization ADM (7.8) Refresh the cache using
the UI button or restart the
server.

Web Templates File Manually copy to Restart the Siebel Server.

each server

Webmaster files File Manually copy to Files are updated to each

each server Web server when the Web
server is restarted, or when
an administrator uses the
SWE command “UpdateWe-
bImages” to manually
refresh the files on the
Web server.

WebServices Run-time Customization UI Export/Import Refresh the cache using

or Create IntObj the UI button or restart the
for ADM server.

Workflow Policies Repository, Run-time EIM or Manual, Yes. WorkMon restart.

Customization Rep Migration Possible regeneration of
Db triggers (GenTrig).
Also governed by
Expiration date.

Workflow Process Repository Siebel Tools UI Yes. Siebel Tools and Siebel
Export/Import or Client WF Admin, or the
“Workflow Admin Workflow Admin Service
Service” BusSvc business process.
or through the Re-
pository Migration
process

* Restarting the server will also activate the object.

B E ST P R AC T I C E S FO R A P P L I C AT I O N C O N F I G U R AT I O N
29
D E P L O Y M E N T I N S I E B E L 7. 7 A N D S I E B E L 7. 8
www.siebel.com

World Headquarters
Siebel Systems, Inc.
2207 Bridgepointe Parkway
San Mateo, CA 94404
United States
Tel: 1-800-647-4300
Tel: 1-650-295-5000
Fax: 1-650-295-5 1 1 1

Europe
Siebel Systems UK Limited
Siebel Centre
The Glanty
Egham, Surrey TW20 9DW
United Kingdom
Tel: 44-0-1784-494900
Fax: 44-0-1784-494901

Asia Pacific
Siebel Systems Australia
Level 1, 80 Pacific Highway
North Sydney, NSW 2060
Australia
Tel: 61-2-9012-3100
Fax: 61-2-9012-3333

Japan
Siebel Systems Japan K.K.
Ebisu Prime Square
1-1-39 Hiroo, Shibuya-Ku
Tokyo, 150-0012
Japan
Tel: 81-3-5464-7700
Fax: 81-3-5464-7702

Latin America
Siebel Systems Brasil Ltda
Av. Nações Unidas, 12.901
20 andar - Torre Norte
04578-903 - São Paulo - SP
Brazil
Tel: 55-11-3444-0450
Fax: 55-11-3444-0666

© 2005 Siebel Systems, Inc. All rights reserved. Siebel, the

Siebel logo, Siebel CRM OnDemand, and “IT’S ALL ABOUT
THE CUSTOMER” are trademarks of Siebel Systems, Inc. and
may be registered in certain jurisdictions. Other marks belong
to their respective owners.

10P10-WP175-05628 (10/05)