TECHNICAL NOTE 0140: Managing The Siebel Development

Environment

Last Modified: 13 November 2001

Area(s): Configuration - Dev Env
Release(s): V6 (Siebel 2000-Enterprise)
Latest release tested
V7 (Siebel 7)
against:

Background

All sections in this document, except Section 6, “Extending the Database”, apply to all versions
of Siebel Tools from version 3.0 onward and are highly recommended when managing the Siebel
development environment.. Contact the Siebel Technical Account Manager (TAM) or Siebel
representative for instructions on database extensibility when working with a version of Siebel
Tools earlier than 3.1.3.

Information in this technical note does not apply to the Siebel 98 release.

For Siebel Tools version 6.x or above, please refer to the Siebel Tools Guide version 6.x.

For Siebel Tools version 7.x or above, please refer to the Siebel Tools Guide version 7.x.

Summary

1. This technical note explains how to set-up and work in the version 3.x Siebel Tools
development environment. Use this document as a checklist when first establishing the
development environment and as a reference through out the configuration phase of the
Siebel eBusiness Application implementation. It will also guide users through eventual
migration of the configurations to test and production databases.

2. Establishing the Development Environment

Create a complete development environment that includes both a Siebel database server
and a Siebel application server; if the database operating system is MS Windows NT,
these can reside on the same physical machine for the purpose of simplicity. This
environment must be completely separate from the production environment: no
development work should be performed in the production environment. Maintain a
separate test environment into which configuration can be migrated for system testing
before installation in the production environment. As with the development environment,
the test environment should include both a Siebel database server and an application
server.
 The development database will store the working copy of all repositories being
configured by the developers. Configuration work should only take place on the
development database. Once a repository is configured, use the Siebel REPIMEXP utility
to transfer that repository to the test (and later, production) environments.

3. Directory Locations

The following convention is used in this document to specify directory locations of the
Siebel application software in the development, test and production environments:

<APPSRVR_31_ROOT> refers to the directory where the version 3.1 application server
software is installed. The default for this directory is C:\SIEBEL.

<DBSRVR_31_ROOT> refers to the directory where the version 3.1 database server
software is installed. The defaults are as follows: C:\DBSRVR\INFORMIX (for Informix
databases)

C:\DBSRVR\MSSQL (for MS SQL Server databases)

C:\DBSRVR\ORACLE (for Oracle databases)

C:\DBSRVR\SYBASE (for Sybase databases)

4. Repository Management

Naming Conventions

It is important to establish and maintain a naming convention of repositories in all

environments. A number of dependencies on repository names exist: both the Siebel
eBusiness Application client and Application server programs point to a specific
repository by name. The procedures for upgrading to new versions of the Siebel
eBusiness Applications are also dependent on repository names.

A consistent naming convention ensures successful configuration and testing. In addition,

it minimizes the work required when migrating new repositories or performing upgrades.
Follow these guidelines in determining the repository naming conventions:

o Production Environment: Decide on a repository name to be used in the

production environment. By default, this is "Siebel Repository" and should only
be changed if there is a compelling reason, as much of the Siebel documentation
and the default configuration of the Siebel eBusiness Applications assume the
use of this name.

o Test Environment: Choose the same name for the active repository in the test
environment as well as for the current working repository in the production
environment. The default name is "Siebel Repository". Using the same name
simplifies the process of migrating repositories from development to test or from
test to production, and eliminates the need to change the client or application
 server configurations when migrations are done.

o Development Environment: Use descriptive names for the other repositories in

the development environment. Typically, the development environment will
contain a number of repositories in addition to the current repository, which is
being configured. These may include the initial repository loaded with the Siebel
application, other repository versions used in Siebel application upgrades, and
repositories from previous versions of the custom configuration. These
repositories should be given unique and fully descriptive names, for example,
"Siebel V3.1.2 Original" for the initial repository shipped with the Siebel
eBusiness Applications version 3.1.2.

Repository Backup

Make backup copies of the development repositories on a regular basis to save the
configuration work. A daily backup takes only a few minutes and can prevent the loss of
months worth of work. Make backup copies of the entire development database, using the
utilities provided by the RDBMS vendor, or use the Siebel application utility
REPIMEXP.EXE to export the contents of a specific repository to a flat file.

REPIMEXP.EXE exports can also be used to integrate Siebel application repositories

with the source code control environment. When configuration of a specific version of
the application is completed, export the repository to a flat file and keep this file in an
archive or source code control system, together with the other application components,
such as client .cfg and .cdf (.srf file in version 4.x or higher) files, batch scripts,
Enterprise Integration Manager .ifb files, and so forth, that comprise that version.

See the Siebel Tools Reference Guide for further instructions on the use of
REPIMEXP.EXE.

The batch file ExpRep.bat is provided to simplify the use of REPIMEXP.EXE.

ExpRep.bat is located in the <dbsrvr_31_root> directory on the development application
server where the Siebel application version 3.1 database software is installed.

Before executing ExpRep.bat, open ExpRep.bat with a standard text editor, such as MS
WordPad, and make sure that the following parameters are set correctly for the
development environment:

SRC_USR = SADMIN Siebel Username

SRC_PSWD = SADMIN Siebel User Password

SRC_TBLO = SIEBEL Database Tableowner

SRC_TBLO_PSWD = SIEBEL Tableowner Password

SRC_ODBC = "Siebel_Server_Database" ODBC Data source Name

SRC_REPOS_NAME = "Siebel Repository" Repository Name

 EXP_USR = SADMIN Export Repository Username

EXP_PSWD = SADMIN Export Repository Password

EXP_TBLO = SIEBEL Export Repository Tableowner

EXP_ODBC = "Siebel_Server_Database" Export Repository ODBC Data source

Name

EXP_REPOS_NAME = "Siebel Repository" Export Repository Name

FILE_NAME = customer.dat The name of the export file to create

After editing ExpRep.bat, execute it as follows:

a. Open a command prompt window on the same development application server.

b. Navigate to the directory <APPSRVR_31_ROOT>\bin.
• Run the batch file SIEBENV.BAT to set the required environment
variables.
• Navigate to <DBSRVR_31_ROOT> directory and run ExpRep.bat.

ExpRep.bat will first prompt users to verify the parameters entered above. Review these
carefully. If they are not exactly as listed above, press Ctrl–C and terminate the script,
then re-edit ExpRep.bat to correct the errors. If the parameters are correct, press Enter to
continue with the script. ExpRep.bat generates a log file called ExpRep.log. Review this
log file for errors once the script has completed.

5. Developer Setup

Use Local Databases

Although Siebel Tools can be used against the development database server, developers
should never make configuration changes directly in the server database.

o Users cannot undo undesired changes to a specific project when working directly
against the server (the only option is to recover the entire repository).

o Changes are immediately available to other developers when they compile a .cdf
file (.srf file in version 4.x or higher) or check out projects. If work on the project
has not been completed, these incomplete changes can cause problems for other
developers.

To prevent such problems and make sure efficient team-based development, each
developer should be configured as a mobile user, with a local SQL Anywhere database.
This local database will initially be populated with a read-only copy of all projects on the
server. As developers need to modify a specific project, they can check out the project
from the server database. This operation locks the project on the server database, to
prevent other developers from modifying it, and transfers a modifiable copy of the project
to the local database. The developer can then modify and unit test the project against the
 local database, and check the project back into the server database once work is complete.
The local database copy of the project can always be reverted to the server version in the
event the developer wants to discard the local configuration work.

Set Up Developers

Follow these steps to set up developers as mobile users:

a. Install Siebel Tools on all developers’PCs. Install the Siebel Tools in a directory separate
from the standard Siebel eBusiness Applications. For example, if the Siebel application is
installed in c:\siebel, install the development tools into c:\siebdev. This will make sure
that the development and runtime environments are distinct. Siebel Remote may be used
in both environments, so make sure that the two installations do not conflict. Refer to the
Installation and Upgrade Guide for further details on installing Siebel Tools.

b. Using a Siebel eBusiness Applications client connected to the development server

database, create an Employee and a Mobile User record for each developer. Use the
developer’s first and last names for the employee first and last names and a standardized
short name, such as first initial plus last name, for the login name. This makes it easy to
identify who has locked a project.

c. Grant each developer a position and a responsibility. All developers can be granted the
"Siebel Administrator" responsibility, or create a responsibility with access to all views
except the System, Service, and Marketing Administration views to prevent unintended
changes to important system preferences. Use a common position for all developers, but
for testing purposes set up an organization structure that models the business.

d. On the Siebel application server, extract each developer’s local database using the
dbxtract.exe utility. The dbxtract creates a template for the developer’s local database that
is populated only with business data, not repository data. All enterprise visible data is
extracted into this template, together with any limited visibility data (Contacts, Accounts,
Opportunities etc.) for which that developer is on the associated team to which this user
has access.

e. Initialize the Developer’s Mobile Client Database. Begin by double-clicking the ‘Local
Database Initialization’icon in the Siebel Tools Program Group on each developer’s
workstation to launch the local database initialization program. Specify the Siebel
developer login created in step b and an appropriate password. The initialization program
creates the sse_data.dbf local database in the \database directory of the Tools installation,
for example c:\siebdev\bin. (in version 4.x or higher, the initialization program creates
the sse_data.dbf local database in the \local directory of the Tools installation, for
example c:\siebdev)

f. Perform an initial Check Out of all projects on each local database, as described below.

Check Out and Check In

Check Out and Check In are the commands used to copy projects between the local
database and the server. When a project is checked out, a copy of it remains on the server.
 Users can also choose whether or not to lock that project on the server with the Server
Lock option, which works as follows:

o If a project is checked out with Server Lock, the project is locked on the server
database. Other developers can check out the project to obtain a read-only copy
but cannot lock it in order to update it. Specifying Server Lock also locks the
project on the local database, which allows the user to modify it locally.
o If Server Lock is not specified, the project is unlocked in both the server and
local databases, preventing users from making local changes to the project.
Another developer can lock the project on the server.

When a project is checked in, the project is copied from the local database to the server
database, replacing the existing definition of the project on the server. In order to check
in a project, the user must have it locked on the server database (that is, the user must first
have performed a Check Out with Server Lock turned on).

Note that when a Check In or Check Out is performed, the project on the target database
is overwritten with the new project.

Initial Check Out

After creating each developer’s local database, perform an initial Check Out to populate
the local database with a read-only copy of all projects from the repository. This permits
the developer to compile a .cdf file (.srf file in version 4.x or higher) against the local
database, which is required to fully test the changes locally.

As mentioned in Step 5 above, immediately after initializing the local database, no

repository data is visible when user starts Siebel Tools and connects to the local database.
The newly initialized local database contains only a skeletal repository without any
projects. If user chooses File > Open Repository… from the menu, no repositories will be
listed. Follow these steps to Check Out all projects to each developer’s local database:

a. Choose Tools > Check Out from the Tools menu. The dialog box shown in Figure5-1
will appear.

b. Select the development repository, as identified by name according to the repository

naming convention. Click Check Server to display a list of available Repositories in the
development database.

c. Make sure that Check All Projects in the radio group is checked

d. Make sure Server Lock is unchecked.

e. Make sure the Server Data Source is pointing to the server development database and the
Client Data Source is pointing to the local database previously initialized.

f. Click Check Out.

g. After checking out all projects, the local database will now contain the initialized
repository data. Choose File > Open Repository… from the menu and select the
repository. Development can now be started using Siebel Tools.
 Figure 5-1: Initial Check Out

Check Out For Modification

Before developers can modify a project on the local database, they must first check out a
copy of the project from the server database. Follow these steps to check out a copy of a
project:

a. Choose Tools > Check Out, which displays the dialog shown in figure 5-1 above.

b. Make sure that the correct repository is selected. (This should be the repository that was
opened in the previous section.)

c. Select only the projects or projects to be modified.

d. Make sure ‘Server Lock’is checked so that the selected projects will be locked on both
the server database and the local database. This will prevent other users from modifying
the projects to be configured.
e. Make sure the Server and Client data sources are specified correctly.

f. Click Check Out.

Check Out For Refreshing

In a multi-user development environment, developers frequently need to check out

projects modified by other developers, not to modify them but to update (refresh) their
local development environment. When checking out projects purely for refreshing, the
projects do not need to be locked. In this case, simply select the specific projects to
refresh in the Check Out dialog box (to get ALL modified projects, press the ‘Check
Server’button and check the ‘Updated’radio button) and do not check ‘Server Lock’.
Make sure that all projects modified by other developers are checked out to make sure
valid local configuration.

Check In Projects

Users can only check in projects that they have locked, which means, that they must first
have checked them out with the Server Lock turned on. Here are some rules to follow:

o Before performing a Check In, make sure that the projects being checked in are
in a stable state and have been thoroughly tested against the local database.
Check in projects only when all dependent code is complete.

o Check in all dependent projects at the same time to make sure that the
configuration on the server remains consistent. For example, if a new PickList
object is created in the PickList project and that object is referenced in the
Opportunity project, check in both projects to the server at the same time.

o Consider the timing of the check in and its impact on the work of other
developers carefully. In some instances, users may need to check in a project
before completing configurations on it. For example, another developer’s
configurations may depend on a particular feature that was added to the project.
Hence, the user may need to check in the project before configuring other
features to allow other developers to test their configurations with the new
feature. This takes careful planning to make sure that the dependent configuration
is completed before starting other independent configurations.

Complete the following steps to check in projects:

a. Choose Tools > Check In. The Check In dialog box displayed in Figure 5-2 appears.

b. The dialog box shows a list of all projects that are locked. Either select the individual
projects to check in, or select ‘Locked Projects’to select all locked projects. Only select
‘Locked Projects’if all configuration work is complete and stable.

c. If ‘Server Unlock’is checked, also check ‘Client Unlock’, and vice-versa. This will make
sure that the server and client locking statuses are consistent. If checking in a project for
other users to access, where work on the project is not complete, do not check Server
 Unlock or Client Unlock.

d. Make sure that the Server and Client data sources are pointing to the correct databases.

e. Click Check In.

Figure 5-2. Project Check In.

Cancel Check Out

Occasionally users may need to discard the changes that have been made to a checked out
project. For example, it may be easier to start making changes from scratch, instead of
undoing the changes already made. There is no "Undo Check Out" command. Instead,
repeat the Check Out procedure of the project from the server database to overwrite the
existing copy of the project with the copy of the project that is on the server. Repeating
the Check Out will not remove the server lock, however. To unlock the project on the
server, Check In the project just checked out again.

6. Extending the Database (Development Environment)

 As with configuration work, database extensibility must first be performed against the
local database in the development environment. This provides recoverability in the event
of mistakes and allows the developer to thoroughly test changes before making them
available to all developers. Database extensibility involves six steps:

a. Check out and lock the project

b. Update the logical schema definition in the local environment

c. Apply the physical schema extensions to the local database

d. Prepare the server database prior to applying schema extensions

e. Apply the changes to the server database

f. Apply the server database changes to other local databases.

Five things must be done to perform database extensibility:

• Check out and lock the project

• Change the local database.
• Update the local environment.
• Apply the changes to the server database.
• Apply the server database changes to other local databases.

Check Out And Lock The Project

With Siebel Tools running against the local database, check out the project that contains
the data model. The default name of this project is "Newtable". Be certain to specify
Server Lock when checking out the project.

Update the Logical Schema Definition in the Local Environment / Change The
Local Database

Make the desired changes to the tables, columns, indexes, and mappings contained in the
Newtable project. Refer to the Siebel Tools Reference Guide for further instructions on
modifying the data model.

Apply the physical schema extensions to the local database - Update the local
environment

Once the changes are complete, follow these steps to update the local environment:

a. Click the "Server" button in the Table List window to apply the changes to the local
database. A warning message that database extensibility from the client is not supported
may appear.
b. If this error message appears, click OK to continue with the operation. The "Update
Schema" dialog box shown in figure 6-1 below will then be seen.

c. Specify "All Modified" tables, type the local database password (which must be in upper
case), and click Update.

Figure 6-1: Update Schema Dialog.

d. Once this process has completed, press the "Client" button in the Table List window.
Select "All Modified" tables in the Update Client Schema dialog box shown below,
specify the table and index table spaces if desired, and click Update.

Figure 6-2:Update Client Schema Dialog

 e. Test the changes thoroughly.

Typically, data model changes are exposed in screens or views; test all of these,
checking out updated copies modified by other developers, if necessary, against
the local database.

f. Check the "Newtable" project back in to the server database.

Prepare the Server Database Prior to Applying Schema Extensions

Complete the following actions prior to applying the changes to the server database:

• All mobile users must perform a full synchronization.

If Siebel Anywhere is not used, mobile users must synchronize their databases and make
no further changes to their local databases until the schema upgrade has been complete.
Because these users will need to be re-extracted and initialized to receive the schema
upgrade, any changes made after the schema changes are applied to the server database
will be lost when they are upgraded.

When using Siebel Anywhere, it is recommended that all mobile users perform a full
synchronization to alleviate long upgrade times. With Siebel Anywhere, the local Siebel
system will disable updates to the system until all of the upgrade has been downloaded,
which could be lengthy if the mobile user has not synchronized regularly.

• Make sure that all connected clients have disconnected from the database server.
• If Siebel Anywhere is not used, stop all processes running on all Siebel Application
Servers, including all Siebel Remote Processes, once all mobile user transactions have
been merged and routed. If using Siebel Anywhere, stop all Siebel application server
processes except the Transaction Processor and Transaction Routers. Leave these
processes running on all Siebel Remote Application Servers. There will be instructions to
stop these processes in a later step.
• Perform a full backup of the database once all mobile user transactions have been merged
and routed.
• Make sure that the database configuration meets the database requirements outlined in the
Siebel eBusiness Applications Upgrade Manual, Chapter 2, Section "Verifying Database
Configuration".

Apply The Changes To The Server Database

Check the "Newtable" project back into the server database to update the repository schema
definition there. Do not click on the either the Server or Client buttons while connected to the
server database.

At this point, the logical database schema of the server database has been updated, but the
changes have not been applied to the physical server database. The batch File DDLSync.bat is
provided to support this process.

DDLSync.bat performs the following:

 • Exports logical schema definition from specified repository to DDL file.
• Synchronizes physical schema with this logical schema definition.
• Propagates new repository schema changes to mobile users (if Siebel Anywhere is being
used).

DDLSync.bat is located in the <dbsrvr_31_root> directory on the development application server

where the Siebel application version 3.1 database software is installed. Open DDLSync.bat with
a standard text editor, such as MS WordPad, and make sure that the following parameters are set
correctly for the development environment:

SRC_USR Siebel Username

SRC_PSWD Siebel User Password

SRC_TBLO Database Tableowner

SRC_TBLO_PSWD Tableowner Password

USE_REPOSITORY Name of Development Repository

ODBC ODBC Data source Name

DATA_AREA Database storage area for tables

INDX_AREA Database storage area for indexes

SIEBEL_ANYWHERE_UPG "Y" or "Y" or "N"

DATABASE_PLATFORM "Informix" or "MSSQL" or "Oracle" or "Sybase"

After editing DDLSync.bat, execute it as follows:

a. Open a command prompt window on the same development application server.

b. Navigate to the directory <APPSRVR_31_ROOT>\bin.
c. Run the batch file SIEBENV.BAT to set the required environment variables.
d. Navigate to <DBSRVR_31_ROOT> directory and run DDLSync.bat.

DDLSync.bat will first prompt users to verify the parameters entered above. Review these
carefully. If they are not exactly as listed above, press Ctrl–C and terminate the script, then re-edit
DDLSync.bat to correct the errors. If the parameters are correct, press Enter to continue with the
script. DDLSync.bat generates a number of log files. Review these for errors once the script has
completed. The log files are named as follows:

• ExpSchem.log
• DDLSync1.log
• DDLSync2.log
• Dock_Log.log
• DBRepos.log
Apply Server Database Changes To Other Local Databases

The approach taken to propagating the schema changes to mobile users varies depending on
whether the Siebel Anywhere module is used or not. In either case, re-generate the SQL
Anywhere template database file to update the schema to the same version as the database server,
using the application server utility GENNEWDB. Refer to the chapter "Siebel Remote
Implementation" in the Administration Guide for instructions on re-generating the SQL
Anywhere template file. Note that the base file APPSRVR_31_ROOT\BIN\SIEBENV.BAT
should be run in the command window before running GENNEWDB. The environment variable
SIEBEL_REPOSITORY that this file sets, must point to the name given to the migrated
repository in the target database.

First regenerate the template local database.

re-initialize all mobile user databases.

If Siebel Anywhere is a licensed module, please use it to automatically distribute the schema
changes to mobile users in the development environment, who will be automatically upgraded as
they synchronize. To use Siebel Anywhere, login to Siebel Tools and connect to the server
database. In the Table List window, click on the "Client" button and select "All" tables to create
the transactions that will route the schema changes to mobile users. Once this process completes,
run Transaction Processor and Transaction Router to route these changes to mobile users in the
development environment. mobile users will receive an error when they attempt to synchronize
and will be prompted to upgrade their schema. The schema upgrade must be applied before
mobile users will be able to synchronize. Please specify variable SIEBEL_ANYWHERE_UPG =
Y before running DDLSync.bat in the previous step.

Please refer to the Siebel Anywhere Guide for further instructions on using Siebel Anywhere.

7. Migrating Repositories Between Databases

Overview of Repository Migration

Users may want to migrate configurations from one database to another, for example, from the
development database to a test environment or subsequently from development to production.
Note that repository customizations should not be migrated to the production environment until
extensive testing has been completed to verify that the customizations work correctly and meet
the business requirements.

The procedure for migrating a repository from one database to another is as follows:

• Prepare target database for new repository

• Run the Repository Migration batch file
• Upgrade mobile databases which are dependent on target database

Prepare Target Database for new Repository

Complete the following actions prior to migrating the repository to the target database:
 • Have all mobile users perform a full synchronization.

If Siebel Anywhere is not used, mobile users must synchronize their databases and make
no further changes to their local databases until the schema upgrade has been complete.
Because these users will need to be re-extracted and initialized to receive the schema
upgrade, any changes made after the schema changes are applied to the server database
will be lost.

If using Siebel Anywhere, it is recommended that all mobile users perform a full
synchronization to alleviate long upgrade times. With Siebel Anywhere, the local Siebel
system will disable updates to the system until all of the upgrade has been downloaded,
which could be lengthy if the mobile user has not synchronized regularly.

• Make sure that all connected clients have disconnected from the database server.
• If Siebel Anywhere is not used, stop all processes running on all Siebel Application
Servers, including all Siebel Remote Processes, once all mobile user transactions have
been merged and routed

If using Siebel Anywhere, stop all Siebel Application Server processes except the
Transaction Preprocessor and Transaction Routers. Leave these processes running on all
Siebel Remote Application Servers. Instructions to stop these processes are available at a
later step)

• Perform a full backup of the production database once all mobile user transactions have
been merged and routed.
• Make sure that the production database configuration meets the database requirements
outlined in the Siebel eBusiness Applications Upgrade Manual, Chapter 2, Section
"Verifying Database Configuration".
• Verify the names of all repositories in the target. In the next step, users can choose a new
name that the repository being migrated will have in the target database. Siebel
Systemsrecommends that the name of the "production" repository remains constant.
Rename the existing production repository to identify that it has been superceded. In the
next step, an upgrade repository is imported. Give this the standard name for the
production repository.

If using Siebel Anywhere, rename the current production repository to ‘Siebel

Repository Old’. The dbupgmgr program, which is called by the repository migration
batch file to route the database schema upgrade to the mobile users, requires that the
current production repository be named with this specific name. This repository must be
the same repository that was in use when the mobile users were extracted. Please note
that this step is critical when using Siebel Anywhere. If the repositories are not named
correctly, all mobile users have to be re-extracted to propagate the schema changes.

Run the Repository Migration Batch File

The batch file Dev2Prod.bat is provided to support this process.

Dev2Prod.bat performs the following:

• Exports designated repository from source database.

 • Imports designated repository into target database.
• Exports logical schema definition from specified repository to DDL file.
• Synchronizes physical schema of target database with this logical schema definition.
• Propagates new repository schema changes to mobile users (if Siebel Anywhere is used).

Dev2Prod.bat is located in the <dbsrvr_31_root> directory on the development application

server where the Siebel version 3.1 database software is installed. Open Dev2Prod.bat with a
standard text editor, such as MS WordPad, and make sure that the following parameters are set
correctly for the development environment:

SRC_USR Source Database: Siebel Username

SRC_PSWD Source Database: Siebel User Password

SRC_TBLO Source Database: Database Tableowner

SRC_REPOSITORY Source Database: Name of Development Repository

SRC_ODBC Source Database: ODBC Data source Name

TGT_USR Target Database: Siebel Username

TGT_PSWD Target Database: Siebel User Password

TGT_TBLO Target Database: Database Tableowner

TGT_TBLO_PSWD Target Database: Tableowner Password

TGT_REPOSITORY Target Database: Name of Migrated Repository (to be

created on your production system). If using Siebel
Anywhere, specify ‘Siebel Repository’for this
parameter. Please note that this step is critical for
using Siebel Anywhere. If the repositories are not
named correctly, all mobile users have to be re-
extracted to propagate the schema changes.

TGT_ODBC Target Database: ODBC Data source Name

DATA_AREA Database storage area for tables

INDX_AREA Database storage area for indexes

SIEBEL_ANYWHERE_UPG "Y" or "N". If Siebel Anywhere is a licensed module,

use it to automatically distribute the schema changes
to the mobile users, who will be automatically
upgraded as they synchronize. To do so, specify "Y"
for this parameter.

DATABASE_PLATFORM "Informix" or "MSSql" or "Oracle" or "Sybase"

After editing Dev2Prod.bat, execute it as follows:

a. Open a command prompt window on the same development application server.

b. Navigate to the directory <APPSRVR_31_ROOT>\bin.
c. Run the batch file SIEBENV.BAT to set the required environment variables.
d. Navigate to <DBSRVR_31_ROOT> directory and run Dev2Prod.bat.

Dev2Prod.bat will first prompt users to verify the parameters entered above. Review these
carefully. If they are not exactly as listed above, press Ctrl–C and terminate the script, then re-edit
Dev2Prod.bat to correct the errors. If the parameters are correct, press Enter to continue with the
script. Dev2Prod.bat generates a number of log files. Review these for errors once the script has
completed.

The log files are named as follows:

o ExpRep.log
o ImpRep.log
o ExpSchem.log
o DDLSync1.log
o DDLSync2.log
o Dock_Log.log
o DBRepos.log

Turning Off Transaction Logging

The repository migration batch file that run in the previous step automatically set the system
preference "Docking: Transaction Logging" to TRUE on the target database. If there are no
mobile users in the target database environment, you should now re-set it to FALSE, using a
Siebel eBusiness Applications version 3.1 client connected directly to the target database.

Restarting Siebel Remote Processes

If there are mobile users in the target database environment, restart the application server
processes, regardless of whether Siebel Anywhere is used or not. When the processes have been
restarted, wait until the Transaction Processor and the Transaction Router have processed all
pending transactions before proceeding with the remaining steps.

Re-Generate SQL Anywhere Database Template

Using the application server utility GENNEWDB, re-generate the SQL Anywhere template
database file to update its schema to the same version as the one on database server. Refer to the
chapter "Siebel Remote Implementation" in the Administration Guide for instructions on
regenerating the SQL Anywhere Template file. Note that the base file
<APPSRVR_31_ROOT\BIN\SIEBENV.BAT> must be run in the command window before
running GENNEWDB. The environment variable SIEBEL_REPOSITORY that this file sets,
must point to the name given to the migrated repository in the target database.

Re-Extracting Mobile Users

If Siebel Anywhere is not used to upgrade mobile clients, re-extract all mobile users, using the
DBXTRACT utility. Make sure that the new SQL Anywhere database templates have been
copied to all production application servers before re-extracting all mobile users. The batch file
DISTMPL.BAT is provided to assist with copying the SQL Anywhere template. Refer to the
Administration Guide for instructions on using DBXTRACT.

Upgrade Mobile Databases, which are Dependent on Target Database

The approach taken to propagating the schema changes to mobile users varies depending on
whether the Siebel Anywhere module is used or not.

If Siebel Anywhere is not used for the upgrade, re-extract and re-initialize all mobile user
databases.

If Siebel Anywhere is a licensed module, use it to automatically distribute the schema changes to
mobile users who will be automatically upgraded as they synchronize. To do so, specify variable
SIEBEL_ANYWHERE_UPG = Y before running Dev2Prod.bat in the previous step (Run the
Repository Migration Batch File). Run Transaction Processor and Transaction Router to route
these changes after the Dev2Prod.bat script completes. Mobile users will receive an error when
they attempt to synchronize and will be prompted to upgrade their schema. The schema upgrade
must be applied before mobile users will be able to synchronize.

Please refer to the Siebel Anywhere Guide for further instructions on using Siebel Anywhere.