55824279 Siebel Best Practices WP Fnl

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

1

W H I T E PA P E R

B E S T P R A C T I C E S F O R A P P L I C A T I O N C O N F I G U R A T I O N 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

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

Introduction

2

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.

��

��

��

��

�� ➔��

��

��

��

��

��

��

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

3

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.

4

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 & AnalysisFirst, 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.

5

W H I T E PA P E R


Define ChangesBased 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 ChangesBefore 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.”

6

W H I T E PA P E R


Change Category Sub-Category Examples Configuration Tool

Repository Objects Compiled • UI Level: Applet, Application, 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

Siebel Tools

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

Siebel Tools

Schema Additive • New Table: Add new column, 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

Siebel Tools

Non-Additive • Change column default, null to not null column, not null to null column

• Change column type char to varchar, varchar to char

• Decrease column size

Siebel Tools

Files On Siebel Server (webmaster and reports)

Web Templates, Style Sheets, Images, Reports for Proposal Generator

Manual, Third-Party Tools

On Reports Server

Report Executables (.rox), String Translation Files for Reports (.txt)

Third-Party Applica-tion (Actuate e.Report Designer Professional)

Run-time Customizations

Additions of new logic or updates to current logic

Additions of new (or updates to existing) Personalization Rules, State Model, Workflow Policies, SmartScripts and Assignment Manager Rules

Developer Client (dedicated client in 7.7)

Authored Data (by Business Users, Administrators)

File-based Content

Solutions, Literature Siebel Admin Views and third-party tools to modify file-based content

Run-time Data Products, Product Catalog, Price Lists, Workspace Projects

Siebel Admin Views

Table 1: Change categories, examples, and configuration tools.

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

��

��

��

��

��

��

��

��

7

W H I T E PA P E R


Package ChangesAfter 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 ChangesBefore 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.

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.

TestingIn 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.

9

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.

10

W H I T E PA P E R


Deployment Details for Each Change CategoryThe 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—GeneralThe 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.

Section Two

11

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—CompiledChanges 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.

12

W H I T E PA P E R


Repository—Non-CompiledCertain 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.

13

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.

14

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 SchemaCustomers 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.”

15

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.

16

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.

17

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 AdministratorCustomers 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.

18

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.

19

W H I T E PA P E R


Techniques to Reduce Downtime During DeploymentWhile 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.

Section Three

20

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.

21

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).

22

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.

23

W H I T E PA P E R


Deployment ScenariosHere 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-velopment system after confirm-ing functionality. Use ADM, EIM or UI Export to export to file.

Deploy to target database using ADM, EIM or UI Import.

Responsibility/Views

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 Database Configuration Utility.

Perform Repository Import and apply the physical schema changes using the Repository Migration process.

2000 Repository objects

Three SRF files (one each for the three languages in the deploy-ment) and browser scripts

Run a script to perform the com-pilation for the three languages in a pre-production environment.

Run a script to copy the files to the application servers while the servers are not running.

Appendix One

24

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.)

25

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.

26

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.

27

W H I T E PA P E R


Deployment/Activation Summary for Common Configuration Areas for Release 7.7 and 7.8

Configuration Area Category Deployment Mechanism

Activation Step

Access Control Admin Run-time Customization

UI Export/Import or Create IntObj for ADM

None

Access Groups Run-time Customization

ADM None

Bundle Promotion (C/OM) Run-time Customization

ADM (7.8) None

Bundle Discount (C/OM) Run-time Custom-ization

ADM (7.8) Refresh the cache using the UI button or restart the server.

Aggregate Discount Sequences (C/OM)

Run-time Customization


Assignment Manager Run-time Customization

ADM a. Regenerate triggers if 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 Customization


Audit Trail Admin Run-time Customization


None

Correspondence templates Run-time Customization

Manually or through EIM

None

Cost List (C/OM) Run-time Customization

ADM (7.8) None

Data Map Object (C/OM) Run-time Customization

ADM (7.8) None

Data Transformation Run-time Customization


Reload Maps. To use the maps. In case any existing map is updated, purge the cache.*

Discount and E&C Matrix (C/OM) Run-time Customization


Dispatch Rule Run-time Customization


Refresh the cache using the UI button or restart the server.

Correspondence Templates Run-time Customization

Manually and EIM None

Expense Type Run-time Customization

ADM None

Appendix Two

28

W H I T E PA P E R


Configuration Area CategoryDeployment Mechanism

Activation Step

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

iHelp Run-time Customization UI Export/Import or Create IntObj for ADM

Restarting the server has no effect. Activate each item from the UI using the Activate button.

Workspace Projects (C/OM)

Run-time Customization ADM (7.8) Objects in the workspace 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 or Create IntObj for ADM

Reload from the Applet menu.

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 through EIM

None

Report Files File Manually copy .txt files / import .rox files via Actuate MgmtConsole

None

Repository Objects (general)

Repository Repository Migra-tion process

Restart the Siebel servers. 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 or Create IntObj for ADM

Reload from the Applet menu item.

29

W H I T E PA P E R


Configuration Area CategoryDeployment Mechanism

Activation Step

SmartScripts Run-time Customization UI Export/Import Activate from the UI.

SRF File Manually copy to each server

Restart the server.

State Model Run-time Customization ADM None

Symbolic URL Run-time Customization UI Export/Import or Create IntObj for ADM

None

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 each server

Restart the Siebel Server.

Webmaster files File Manually copy to each server

Files are updated to each 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 or Create IntObj for ADM

Refresh the cache using the UI button or restart the server.

Workflow Policies Repository, Run-time Customization

EIM or Manual, Rep Migration

Yes. WorkMon restart. Possible regeneration of Db triggers (GenTrig). Also governed by Expiration date.

Workflow Process Repository Siebel Tools UI Export/Import or “Workflow Admin Service” BusSvc or through the Re-pository Migration process

Yes. Siebel Tools and Siebel Client WF Admin, or the Workflow Admin Service business process.

* Restarting the server will also activate the object.

www.siebel.com

World HeadquartersSiebel Systems, Inc.2207 Bridgepointe ParkwaySan Mateo, CA 94404United StatesTel: 1-800-647-4300Tel: 1-650-295-5000Fax: 1-650-295-51 1 1

EuropeSiebel Systems UK LimitedSiebel CentreThe GlantyEgham, Surrey TW20 9DWUnited KingdomTel: 44-0-1784-494900Fax: 44-0-1784-494901

Asia PacificSiebel Systems AustraliaLevel 1, 80 Pacific HighwayNorth Sydney, NSW 2060AustraliaTel: 61-2-9012-3100Fax: 61-2-9012-3333

JapanSiebel Systems Japan K.K.Ebisu Prime Square1-1-39 Hiroo, Shibuya-KuTokyo, 150-0012JapanTel: 81-3-5464-7700Fax: 81-3-5464-7702

Latin AmericaSiebel Systems Brasil LtdaAv. Nações Unidas, 12.901 20 andar - Torre Norte04578-903 - São Paulo - SPBrazilTel: 55-11-3444-0450Fax: 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)

Documents

55824279 Siebel Best Practices WP Fnl