The Requirement:

Create a button on a List Applet. On Click of that button the Status of SR should get changed to ‘Close SR’.

Solution:

As we all know there are several ways to this requirement. If button was not involved then a Simple On Field Update Set n user property would have sufficed. In this case we need to invoke a custom method that should set the field value. That leaves us with two approaches

Approach 1:

Create a Named Method n user property. Invoke a workflow and set the status to ‘Close SR’. The workflow and user property will look something like this.

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.

Requirement: 

When a Service Request is closed then attachments of that SR should be extracted and sent to a different application though SFTP. 

The interesting part in this requirement was SFTP part as I had never done that before. 

Approach: 

The approach for this requirement was pretty simple: 

1. Setup a Policy which will trigger a workflow when SR is closed (Policy because we wanted it to be asynchronous)
2. The workflow will query for attachment records and run a loop around them
3. A business service will be called  in this loop which will
   1. Query for attachment record in eScript
   2. Execute GetFile method to obtain path of uncompressed file
   3. Use Clib.System command execute a shell script on UNIX (passing path as argument)
   4. Shell script will issue SFTP command to actually put files on different application server

Challenges: 

The biggest problem that I faced in this was making SFTP work. 

FTP protocol allows you to hardcode username and passwords in shell scripts like this: 

ftp -n ftpsite << !
quote USER username
quote PASS password
binary
put $1
quit

But SFTP was built to overcome this limitation and doesn’t allow password to supplied as an argument due to security reasons (S stands for Secure). So, you have following option to make SFTP work. 

1. SSH Keys:The most common method (which we also used) is to use ssh keys.  The system that wants to connect (in this case it was Siebel) will generate a Public key and a Private Key. Public Key resides on the target server and Private Key resides on the server where the session is initiated (Siebel). This approach allows you to connect to target server without actually using the password. 
2. Expect Library:  
   The Second approach is to use Expect Library. It allows you to automate certain tasks but script is tedious to write and often error prone. 
3. PSFTP tool: 
   You can also use PSFTP tool which allows you supply password as an argument and takes care of rest of things. 

The Second and third approach are plagued with same problem as FTP, your password is exposed to everybody who has access to shell script. This is not desirable in secure environments.

1. Performance:
Siebel eScript is an interpreted language which means it is read and executed by eScript engine line by line at runtime which affects performance of a Siebel application. Also the functions and script has to be loaded in memory which means a badly written script can easily cause memory leaks and application crash.

2. Upgrade:
This is one the biggest reasons of avoiding scripts. As you never know when a function will be made obsolete by Siebel an you need to replace it with new function. Also, Siebel doesn’t take care of scripting and you need to do manual effort to port your scripts to upgraded version

3. Manageability:
Writing scripts here and there and all over application makes application difficult to manage which means you never know when a small change done on one object might introduce a error in other object application. Also script written by one developer needs to be understood first before making changes in it making it is a time consuming and error prone process.

Now, what are reasons that force us to still resort to scripting despite the pitfalls and problems discussed above. I think below are the prime reasons for that but feel free to add to it in case if you feel something is missing:

1. Lack of declarative solution:
More often than not complex business requirements force us to use scripting as there are no declarative solution available to complete them

2. Tight Deadlines:
Although writing scripting is a time consuming task but still it is easier to complete complex requirement using scripting than configuration and workflows.

3. Lack of knowledge:
To complete a complex requirement through declarative solution requires thorough knowledge of Siebel data model (database and tables) which  comes after years of experience where as scripting requires you to have knowledge of BO layer which makes easy to implement requirements using scripting.

This lands us in a Catch 22 situation. On one hand we fill the mind of developer to focus on declarative solutions and avoid scripting at all cost and on other hand more often than not he ends up writing scripts to achieve complex requirements. The biggest pitfall of such a paradox is: “Developer just uses eScript and doesn’t try to understand it, which results in inefficient and messy solutions.”

I am not supporting eScript but I am just trying to say that we end up using eScript sooner or later, so why not understand it better in order to use it in most efficient way when the time comes. So, I ask this question again

Is Scripting is really EVIL?

My answer to this question is NO. Atom bomb destroyed Nagasaki and Hiroshima and also movies like Armageddon has shown that Atom Bomb might be only thing that might save our earth in case if an asteroid decides us to pay a visit . So, it really depends on how you use a particular thing. Even a solution achieved through configuration can be as devastating as a solution achieved through scripting if not done properly. I have actually seen some solutions function better when done through scripting as compared to configuration. I have seen developers creating tables and BC’s so that they can avoid writing a 10 lines of code and use data map instead.

Now, the question is do we need to have such an extreme view for scripting and also when to use scripting and when to avoid scripting??

According to me scripting on BC’s and Applet’s events should be avoided (almost like plague) but when it comes to finding solution of complex business requirements then you should keep you mind open and evaluate both scripting as well as declarative solution. Even Alex doesn’t consider a well written business service as scripting. So, what do you think???

Recently I came across a problem in which I used it to save myself from a tricky situation. I was using S_ORG_EXT_ XM table to build a new entity which is having 1: M relationship with Account. We used most of the ATTRIB columns rather extending table. There was one field where we used LOVs to display Data to user. As per client coding standards, we were supposed to store LIC value in tables and show display values since the Application was supposed to go Multilingual in coming years. Since I was not aware of this standard and I placed an LOV on field based on ATTRIB and stored display value in column.

I was using the below config , which is straightforward :

Picklist config –

When we realized this problem, I was suggested to make it Multilingual by giving Translation Table Name at column level but I realized that since it’s a reusable table (S_ORG_EXT_XM). Tomorrow someone else can use it for some other entity and if I give Translation table, then that column will be useless for that developer since it won’t accept values other than those LOVs. More over its OOB table so doesn’t wanted to touch it as it might hamper Application upgrade.

I just quickly analyzed that now calculated field can be used here. Here is how it worked for me.

Remove pick list from existing field, place it on calculated field.

A Calculated Field Looking up LIC and having Pick list with 2 Pick Maps.

Now expose the above Calculated Field in Applet rather Actual Field. This will always show Display Value to User and behind the scenes store LIC in table via Pick map. Even Query, Sorting worked fine.