Component Parameter export and Comparison

Component Parameter comparison
In Siebel,all the component configuration such as their parameter value are stored in Siebns.dat file.
If during migration to any other environment there arises some need to compare component parameter with other environment then it can be a lot of time consuming and tedious task if we perform it by GUI.

Reason being
1. If you try to export parameter to .csv sheet then only Reset level component parameter will get exported not the parameter under Hidden and Advanced.So you can not do sheet comparison.

So there are 2 ways in which we can compare component,Enterprise parameters.

Spool through Srvrmgr
Connect to server manager using
srvrmgr /e <EnterpriseName> /g <GatewayNSHostname> /u sadmin /p <SADMIN_pwd>
and use following command to take spool of parameters
spool
spool abcdef.xls
list hidden param for comp XXX show PA_NAME, PA_VALUE
list advance param for comp XXX show PA_NAME, PA_VALUE
list param for comp XXX show PA_NAME, PA_VALUE
spool off

Repeat this step for all the components.
After getting all the Parametrs in .xls sheet ,you can compare sheet from different environment and compare them with some comparison tool like Beyond Compare.

cfgmerge utility from oracle
The cfgmerge program is a command-line utility that creates a parameter migration script after comparing two different Siebel environments.The cfgmerge utility resides in the bin subdirectory of the Siebel Server root directory as the executable program cfgmerge.

Before running the cfgmerge utility, make sure all component groups of interest are enabled on both the source and target application.In all cases, run the cfgmerge utility in the target environment.

• Make a backup copy of the target application's siebns.dat file.Rename it target_siebns.dat
• Make a backup copy of the source application's siebns.dat file.Rename it source_siebns.dat
• Move the source_siebns.dat file and the target_siebns.dat file copies to the bin subdirectory of the Siebel Server root directory, which contains the cfgmerge utility.

Run the cfgmerge utility using the following commands to execute the application comparison. The cfgmerge utility can run a comparison in Enterprise mode or Siebel Server mode:
Running Enterprise-mode comparison:
cfgmerge -l language_code -i source_siebns.dat,target_siebns.dat -e source_enterprise_name,target_enterprise_name -o output_file.cmd
Running Siebel Server-mode comparison:
cfgmerge -l language_code -i source_siebns.dat,target_siebns.dat -e source_enterprise_name,target_enterprise_name -s source_server_name,target_server_name -o output_file.cmd

DBCHCK Utility

DBCHCK

DBCHCK is Siebel supplied utility to compare the Logical Schema in the Siebel Repository against the Objects in the Physical Oracle Database.
DBCHCK can be useful to to identify custom indexes added by the development team but not added to the Repository using Siebel Tools.This should be run from the siebsrvr folder.

Command Used
dbchck /u <User Name> /p <Password> /s <ODBC Data Source> /t <Table Owner> /dict /all

What is DDL sync and how to do it?

DDL Sync is one of the most important step as part of code migration to new environment.
So here we will discuss

• why do we perform DDL sync?
• What are the steps involved in this process? and
• How can we do this?

DDL Sync
DDL sync is used to have a sync between your Siebel Repositories & physical schema in Oracle DB. ddlsync compares the logical schema (schema definitions in your repository) with your physical schema (i.e. physical db table/column definitions) and applies the differential changes on the physical schema so that they are both in sync 

Steps involved
DDL Sync is 3 steps process which includes

• ddldict to export customer schema definitions from the repository into schema.ddl file .
• ddlimp to apply the schema definitions in schema.ddl to the physical schema ignoring error .
• ddlimp to apply the schema definitions in schema.ddl and stop on error to ensure that logical and physical DB are in sync. 

How to perform DDL Sync

DDL sync can be done through Wizard which can be invoked by 

[ ] 1 - Install Database

[ ] 2 - Upgrade Database

[ ] 3 - Apply Additive Schema Changes

[ ] 4 - Import/Export Repository

[ ] 5 - Migrate Repository

[X] 6 - Run Database Utilities

or we can do DDL sync with separate commands.

Navigate to bin directory in siebsrvr.

ddldict /u sadmin /p ###### /c Enterprise_DSN /d siebel /f /#####/81/siebsrvr/schema.ddl /e y /a y /l /######/81/siebsrvr/log/sch_dict.log /n "Siebel Repository" /t dcir

Above command will generate Schema.ddl at the specified location.Now we have to apply the schema changes to Physical DB.

ddlimp /u SIEBEL /p ###### /c Enterprise_DSN /g SSE_ROLE /f /#####/81/siebsrvr/schema.ddl /e n /B SIEBELDATA /X SIEBELINDEX /R Y /W Y /s Y /l /#####/81/siebsrvr/log/ddlsync/output/ddlsync.log

Different Files and their usage in Siebel

There are number of files that we come across in Siebel and we don't have idea about their usage and role in our application.
Here in this post we will discuss about all the important files.

• Siebel_sia.srf
• eapps.cfg
• eapps_sia.cfg
• gateway.cfg
• diccache.dat
• Enterprise_server.shm file
• application.cfg
• lbconfig.txt
• Siebns.dat

Siebel_sia.srf

Siebel SRF file also known as Siebel Repository File (SRF) is a compressed, read only file that contains compiled version of Siebel repository. So all the object definitions and scripts that are defined in Siebel Tools are compiled into one single file which is will be used by Siebel Application at run time.

This SRF file is normally at "\root\siebsrvr\objects\enu” with the file extension srf. It is very important that the active Siebel Repository should always be in sync with the SRF.

Please do not get confuse between Siebel repository and Srf file.

The main difference between Repository and SRF is that Repository is the collection of all Siebel Object Definitions in a user readable/editable form. It is stored as database records in one or more Repository tables (S_Repository). Now when these object definitions are compiled through Siebel Tools, the resultant file is the SRF.Now this also contains all the object definitions but as a flat file which will be read at run time.

 eApps.cfg

eapps.cfg is one of the most important file used in Siebel Application.Here we discuss different section contained in eapps.cfg file and what effect they can make in siebel application.
The eapps.cfg file is located in SWSE_ROOT\bin, where SWSE_ROOT is the SWSE installation directory.

[swe]
Language      = ENU
Log           = errors
LogDirectory  = E:\sba81\SWEApp\log
ClientRootDir = E:\sba81\SWEApp
SessionMonitor  = False
AllowStats      = true
LogSegmentSize  = 0
LogMaxSegments  = 0
DisableNagle    = False

Log
Log parameter defines the detail in which we can generate log related to swe error.It can have other values such as Details.e.g. Log = Detail.
LogDirectory
This parameter defines the location of the log directory, whose default location is \SWEApp\LOG (WINDOWS)
ClientRootDirectory
This is the location of SWSE plug-in installation, whose default location is SWEAPP_ROOT.
SessionMonitor
Use this parameter to determine whether to gather statistics on all current sessions and report them in the SWSE stats page. To enable session monitoring, set SessionMonitor to TRUE.
We can view stats page in url by appending _stats.swe
http://url/app_enu/_stats.swe
LogSegmentSize
This parameter determines how large a segment of the log file is in kilobytes. If you set this parameter to 5, the log segment will be 5 KB in size. A value of 0 turns off segmentation.

[ConnMgmt]
EnableVirtualHosts = true
VirtualHostsFile   = E:\sba81\SWEApp\admin\lbconfig.txt

Enable Virtual Hosts = True makes load balancing true for the application.
VirtualHostsFile describes the location of the lbconfig.txt file which have the configuration of load balanced servers.

[defaults]
EncryptedPassword = True
AnonUserName  = GUESTERM
AnonPassword  = #######################
StatsPage     = _stats.swe
HTTPPort      = 80
HTTPSPort     = 443
EnableFQDN          = TRUE
FQDN                = ################################
TrustToken          = 
DoCompression       = true
GuestSessionTimeout = 300
SessionTimeout      = 3420

This section is most important section of this file.
EncryptedPassword 
If the parameter is TRUE, then the password parameter values must be encrypted, and if the parameter is FALSE, then the passwords must not be encrypted.

if the EncryptedPassword parameter does not exist in the eapps.cfg file, then the default behavior is the same as if EncryptedPassword is set to FALSE.

encryptstring.exe utility is use to encrypt the plain text which is available at /siebsrvr/bin.
AnonUserName
This parameter specifies the user name required for anonymous browsing and initial access to the login pages. The user name selected should have access to views intended for anonymous browsing.
AnonPassword 
This parameter specifies the user name password required for anonymous browsing and initial access to the login pages. 
When user first enters the URL of siebel Application,Login page comes only after the authentication of AnonUserName otherwise Server busy error will come.
HTTPPort 
The HTTP port used for Web browser communications. The default setting is the standard port of the Web server in use (80).
HTTPSPort
The HTTPS port used for secure Web browser connections. The default setting is the standard port of the Web server in use (443).
FQDN
Stands for Fully Qualified Domain Name. An example of a fully qualified domain name would be http://oradev.oracle.com.If the Web server receives a request for a URL that does not contain the full domain name, the FQDN setting causes the browser to reissue the request and to add the domain name.
For example,If we hit the URL with IP name http://10.1X.XXX.XX9/app_enu and Enable FQDN =True then it will convert URL to one specified with FQDN parameter.
DoCompression
Specifies whether the SWSE will compress HTTP traffic.Compressing HTTP traffic, where it is feasible to do so, substantially reduces bandwidth consumption.
GuestSessionTimeout
The time, in seconds, that a connection open for anonymous browsing can remain idle before it times out. The default is 300 seconds (5 minutes).Guest sessions are used for anonymous browsing. They permit users to navigate portions of the site without logging in. In contrast to anonymous sessions, guest sessions are associated with an individual Siebel Web Client. These sessions are opened when an unregistered user starts navigating the site, and they remain open until the Web client logs out or times out due to inactivity.
SessionTimeout
The time, in seconds, from the user's last browser request until the user's connection times out. The default is 900 seconds (15 minutes).Standard sessions are those where users log in using their registered user name and password.

eApps_sia.cfg

The file eapps_sia.cfg is included by eapps.cfg, and extends its functionality by specifying connectivity information for AOMs.

[/app_enu]
ConnectString = siebel.transport.encryption.compression:\\server:server_port\enterprise\AppObjMgr
WebPublicRootDir = E:\sba81\SWEApp\public\enu
SiebEntSecToken = P94################
where ConnectString has format

transport = Networking transport protocol such as TCPIP
encryption = Encryption type such as RSA
compression = Data compression method.
server = IP address or hostname of the Siebel Server (or in the load-balanced case, the virtual IP address as VirtualServer).
server_port = Port number on which the Siebel Connection Broker component (alias SCBroker) runs.By Default it is 2321.


SiebEntSecToken
This is the password used by the Siebel Administrator to refresh application images from the Siebel Server on the Web server without restarting.
gateway.cfg

The gateway.cfg file contains the configuration parameters that determine how access to the
Gateway Name Server is authenticated.

[DataSources]

ServerDataSrc       = ServerServerDataSrc(The data source used when database authentication is enabled)
LDAPSecAdpt        = LDAP(The data source used when LDAP authentication is enabled)

[ServerDataSrc]
Docked                   = TRUE
ConnectString            = Enterprise_DSN
TableOwner               = SIEBEL
DLL                      = sscdo90
SqlStyle                 = OracleCBO
MaxCachedCursors         = 16
MaxCachedDataSets        = 16
ReverseFillThreshold     = 100
FileSystem               = /siebelfs
GatewayAddress           = ############
EnterpriseServer         = Enterprise Name

Introduction to Siebel Architecture

Siebel Application Architecture consists of following elements displayed in given diagram

Siebel Application Architecture Dig.

(taken from bookshelf)

Web Client

There are number of web clients type which we can use for Siebel Application

• Siebel Web Client
• Siebel Mobile Web Client 
• Siebel Developer Web Client (limited support)
• Siebel Wireless Client 
• Siebel Handheld Client

Siebel Web Clients running in high interactivity mode use ActiveX controls and JavaScript,

and require Sun JRE. These items can be downloaded to the browser automatically.

Siebel Web Client

Siebel Web Client runs in a standard browser on the end user’s client computer. The browser connect through a Web server to the Siebel Server, which executes business logic and accesses data from the Siebel Database. Only the user interface layer of the Siebel Business Applications architecture resides on the user’s computer.

Siebel Mobile Web Client

Windows-based software containing Siebel applications and related services is installed on each client. The client also requires a Web browser.A local database and local Siebel File System are installed on each client.Applications access the local database.Users periodically synchronize the local database and Siebel File System with a remote Siebel Database and Siebel File System. Users synchronize data using Siebel Remote components of the Siebel Server. Mobile users synchronize with the remote Siebel Database and Siebel File System without going through the Web server or any other Siebel Server component.

Siebel Developer Web Client

Windows-based software containing Siebel applications and related services is installed on each client. The client also requires a Web browser.A direct connection is required to the Siebel Database. Appropriate

database client software must be installed on the client. This client can connect directly to the Siebel File System or connect through the File System Manager server component.

Siebel Wireless Client
The Siebel Wireless Client is a modified Siebel Web Client that runs on a mobile device. Users can view, edit, and create records in the Siebel Database through a wireless connection between a mobile device and a Web server. An Internet-enabled mobile phone, personal digital assistant, or other wireless device communicates with a wireless gateway server, which translates messages for display in a browser on the device.

Siebel Handheld Client
The Siebel Handheld Client is a streamlined version of the Mobile Web Client that runs on a handheld device. It includes only the functionality required by field technician end users. The Siebel Handheld Client supports the same data relationships, the same configuration in Siebel Tools, and much of the same functionality as the Siebel Mobile Web Client. Siebel Handheld runs on devices that support the Windows CE operating system.

Deployment Modes for Siebel Web Clients

There are two fundamental modes of deployment for a Siebel Web client:

• Standard interactivity
• High interactivity

The user interface characteristics of Siebel Business Applications, and the experience of your end

users, depends greatly on the interactivity mode in which you deploy your applications.Each Siebel application is preconfigured to use one of these deployment modes.

Standard Interactivity

The standard-interactivity client provides users of Siebel applications with a user experience similar

to that for users of traditional Web applications for customer applications, such as those for

consumers. The usability characteristics of this deployment mode are familiar to users of typical

consumer Web sites,such as eBay, Amazon, Flipkart.

Most user interactions in standard-interactivity deployment mode result in a page refresh. When

creating a new record, the user clicks the New button (which refreshes the page as the application

displays a new entry form), enters the relevant data, then clicks the Save or Submit button (which

again refreshes the page as the application re displays the original page). Similarly, when a user

browses through a list of records, the page refreshes each time a new record is selected.

High Interactivity

The high-interactivity client is designed to provide users of Siebel applications with a user experience similar to that for users of traditional GUI-based client applications, such as for Microsoft Windows.High interactivity reduces the number of page refreshes, compared to standard interactivity—when interacting with the application, browsing through records, and so on. This is made possible by making data-only updates from the Siebel Server, optimizing use of network bandwidth.

For example, a high-interactivity client does not require a page refresh for creating a new record. A user creates a new record by clicking the New button. A new row is created in a list dynamically, without a page refresh. The user enters the relevant data, then clicks outside of the record (“steps off of the record”) to implicitly commit the change—again, without a page refresh.

The high-interactivity framework provides performance and usability enhancements by taking advantage of capabilities supported by Microsoft Internet Explorer browsers. These capabilities include Document Object Model (DOM), Java, and ActiveX controls.

Siebel high-interactivity clients use a Siebel-specific remote procedure call (RPC) though HTTP or HTTPS, which is the fundamental communications channel for the client. The Siebel RPC sends and retrieves data over HTTP or HTTPS to and from the Siebel Server. There are no other communication channels in the Siebel high-interactivity client.

Web server

Client Web browsers connect to Web servers to access Siebel Business Applications.Supported Web servers and operating systems include:

•  Microsoft IIS (on Microsoft Windows)
•  IBM HTTP Server (on AIX and supported Linux operating systems)
•  HP Apache Web Server (on HP-UX)
•  Oracle HTTP Server (on supported Linux operating systems)
•  Sun Java System Web Server (on Sun Solaris)

Siebel Web Server Extension (SWSE)

The Siebel Web Server Extension (SWSE) is a plug-in for supported third-party Web servers. It

identifies requests for Siebel application data coming from Web clients and flags these requests for

routing to a Siebel Server. When information is sent from the Siebel Server back to the Web client,

the SWSE helps complete the composition of the Web page for forwarding to the client.

The SWSE includes the Siebel native load balancing module. This module provides round-robin load

balancing for routing requests to Application Object Manager components running on Siebel Servers.