Siebel Deployment -Release management.

Today Ram Mohan reader of Siebel Unleashed is sharing with us an article describing basics activities performed for Siebel Deployment during a release.  A good articles for Siebel newbie’s especially who have just started as Siebel Administrator. Please do provide your feedback.


Introduction 

Siebel Deployment or Releases are done to prorogate the developed changes from one environment to another environment like Dev to test, test to UAT, UAT to prod. Migrating repositories between databases is a common requirement when going live to a new development, testing, or production environment.

Whenever there is release or migration between environments the following Type of data needs to be moved.

  1. SRF
  2. Siebel Repository
  3. Master Data

Note: We take the example of moving the changes from DEV to testing Environment. So Development is the Source Environment and Test is the Target Environment.

Siebel Repository Migration from Source to Target:

Siebel Repository Migration is required whenever there is change in workflows or database layer objects (Table, columns or indexes etc…) Siebel Repository. Sometimes we will move only the SRF without Siebel Repository for small bug fix releases. It is Best practice to move the Siebel repository for all the Migrations or Builds from one Environment to another environment regardless of the type of release(may be bug fix or big Release).

There are two ways of doing the Repository migration

  1. Though the Database configuration Wizard provided by the Siebel which provides user interface
  2. Though the Scripts – Directly using the scripts which are intern created and executed by the Siebel Database Configuration Wizard.

Even if you do the Repository migration though the Database configuration wizard it will create same scripts and execute in the back ground.

Please refer the Going live with the Siebel Business Application PDF from Siebel bookshelf for doing the repository migration through Siebel Database Configuration Wizard.

Steps for Repository migration through scripts (Windows Environment):

  1. Export the Repository from Source Environment(DEV):
    • Login to one of the Application server in the Source Environment (Dev)
    • Open the Command prompt and Execute the Following Command with the Parameters of the Environment.
      $SIEBEL_HOME\siebsrvr\bin\repimexp.exe /a E /G ALL /u SADMIN /p password /c devsiebent_DSN /d siebel /r ‘Siebel Repository’ /f D:\export.dat /l D:\export.log
    • Where $SIEBEL_HOME\siebsrvr\bin\repimexp.exe is the Location of the repimexp.exe, which is Executable file to Export Siebel repository. Same Executable will be used for the Repository Export and Import but with Different Action (/a) option.
    • After successful run of the above script Export Dump file (export.dat) and Log file will be created in the specified directories in the script.
  2. Move the export file to the Application server in Target environment.
  3. Stop the Siebel Application servers in target environment
  4. Import the Repository in the Destination Environment using the below Command
    • $SIEBEL_HOME\siebsrvr\bin\repimexp /a I /G ALL /u SADMIN /p ******* /c devsiebent_DSN /d siebel /r NewSiebelRepository /f D:/export.dat /l D:\import.log
  5. Log-in to tools in the target environment and rename the Old repository appropriately and rename the newly imported repository (NewSiebelRepository) to ‘Siebel Repository’.
  6. Run the DDL SYNC if there is any Table Level Changes in the New Siebel Repository using below Scripts.
    • Create the Schema file from the Repository using below command:
      $SIEBEL_HOME\siebsrvr\bin\ddldict /u sadmin /p SADMIN_PASSWORD /c devsiebent_DSN /d Siebel /f ‘D:\schema.ddl’ /e y /a y /l ‘/D:\dictionayschema.log’ /n ‘Siebel Repository’ /T DCIR
    • Apply the Schema changes to database from schema file:
      $SIEBEL_HOME\siebsrvr\bin\ddlimp /u siebel /p SIEBEL_PASSWORD /c devsiebent_DSN /g SSE_ROLE /f ‘D:\schema.ddl’ /e n /B TS_PRDSBL_DATA /X TS_PRDSBL_IDX /R Y /W Y /s N /l ‘/D:\Applyschema.log’
  7. Move the SRF to the Target Environment servers
  8. Run the genbscript to generate browser script using following command and move it to Web server’s Public Folder
    • $SIEBEL_HOME\siebsrvr\bin\genbscript $SIEBEL_HOME\siebsrvr\bin\enu\publicsector.cfg TARGET_LOCATION_PATH ENU
    • You need to run this command once for each language your Application supports
  9. Start the Application servers

 

Master Data Migration:

To move Master data such as List of Values, responsibilities, Views, PDQs etc we can use one of the below given approaches

  1. ADM (Application Deployment Manager): Please Refer the Siebel Application Deployment manager Guide for migrations using ADM.
  2. EIM (Enterprise Integration Manager): can also be used to achieve the same.

 SRF Movement from Source (DEV) to Target (Test) Environment:

SRF can be moved in following ways from source to target.

  1. Compile SRF in Source Environment (DEV) and move it to target Environment. This approach is followed Do this whenever there in no repository movement (in minor bug fixes release).
  2. Move the Siebel Repository to the Target Environment (Test) and Compile SRF in target environment. This is followed normal releases.

Using the Command Line Scripts is very easy if you understand importance and Parameters of Each Command.  Below is the explanation of some of the switches used in different commands in this article:

/a: Represents the Action to be taken, E for Export the Siebel Repository. I for import the Siebel repository.
/G: Rrepresents the languages to be exported or imported. Option ALL will export or Import all the languages in the Repository or DAT file
/C: Represents the Server Data source name to connect to Database. Check the Application cfg file or ODBC configuration Tool for the exact server Data source name
/d: Represents the table owner name, normally it is SIEBEL
/r: Represents the Repository name to be Exported .Most of the Environments it will be ‘Siebel Repository’. Since a Siebel Environment can have multiple Repositories but only one with the Name ‘Siebel Repository’ (repository name to be used by Application is specified in the Application cfgs).
/f: Represents Export file name and Location, it will be in .dat format.
/l: Specifies is the Location of the Log File.

The above commands Paths and Directory structure will change between Windows and UNIX environments. You have to 4 Commands to do the entire Repository migration task. Prepare the above commands and save them as Batch scripts in Windows and Shell scripts in UNIX for future release. You can do simple modifications to these scripts for every release and execute them.

Please let me know if any clarifications, modifications and OS specific Commands required.

13 Responses to Siebel Deployment -Release management.

  1. Hi Neel,

    I hope you are well. Thank you for this wonderful site which gives us real insights into the Siebel System. I need your help as I am planning to audit a Siebel 8.0 upgrade and CRM components. Can you please provide us with high level footprint of the key areas to consider Siebel Security vulnerabilities. Any more details on this would be really useful. Thanks, Sid

  2. Hi,
    Thanks for very good article. I am working as siebel system administartor.
    while going through driver_dev2prod.ucf file i came across “strgupgd” utility being used in one of the file execute entries. Any idea what it does and how?

  3. Hi All,
     
    Maybe this is useful for some of you.
     
    While Creating the Schema file from the Repository using below command:

    I had to use /d switch parameter value “dbo” – which is siebeltableowner name and not the SIEBEL.
    $SIEBEL_HOMEsiebsrvrbinddldict /u sadmin /p SADMIN_PASSWORD /c devsiebent_DSN /d Siebel /f ‘D:schema.ddl’ /e y /a y /l ‘/D:dictionayschema.log’ /n ‘Siebel Repository’ /T DCIR
    om the Repository using below command:$SIEBEL_HOMEsiebsrvrbinddldict /u sadmin /p SADMIN_PASSWORD /c devsiebent_DSN /d Siebel /f ‘D:schema.ddl’ /e y /a y /l ‘/D:dictionayschema.log’ /n ‘Siebel Repository’ /T DCIR

  4. Let’s say we want to establish a formal Software Configuration Management process has steps such as version control, build and deploy.

    1. What are the artifacts need to be in the version control repository, .sif, .srf, .dat?

    2. What’s the process to migrate a release from DEV to TST now, with such a version control repository in place? Your procedure simply moves everything from DEV to TST. In a formal release process with a version control system, we want to baseline a release in the version control system and take from there to the target environments. Is this possible with Siebel?

    Thanks
    Jirong

    • Looking for a SCM process , have you managed to get a solution for your question ? Thanks Raj

Leave a Reply

Contribute