The Three main pillars of Siebel Architecutre

e following 3 components are the three main pillars in the siebel architecture:

  1. SCBroker
  2. SRBroker
  3. SRProc

I will explain these 3 siebel components one by one as most people do not have a clear understanding of the same.

SCBroker  or Siebel Connection Broker– The main purpose of this component is to listen to port 2321 for user requests (Users log in to the application) on the servers hosting the Object Manager Component and forward it to Object Manager. But does it all end here? Is it all that it does?

The answer is NO – It does one more work and that’s why I call it as an intelligent component. SCBroker accepts the incoming user requests and after accepting the user requests assigns it to the Process from the Object Manager that has the least Load. How does it do this? Well the answer is – it reads the shm file on the server. The shm file has a section for the processes running on the server – which tells the SCBroker about the load on different Processes for the Object Manager running on the server.Thus SCBroker does load balancing amongst Object Manager Processes in siebel

There is normally only one task running for SCBroker on a server. There can be multiple instances of SCBroker on the same server however each will listen to the same port -2321.

SRBroker  or Server Request Broker – SRBroker does the same work as of a broker in a real world. It is used for inter-server and intra-server communication. Let’s see this with an example.

Let’s say we have File System Manager (FSM) Component running on an server along with Object Manager. Now suppose the Object Manager needs to access some attachment from the file system. How will the Object Manager do this? The Object Manager will give a call to the FSM But through SRBroker – this is the case of inter server communication.

Let’s say after sometime the Object Manager needs to access another attachment from the filesystem but this time the FSM component is down on the server for some reason. Under this scenario as the request from the Object Manager to the File System Manager is going through SRBroker – SRBroker will sense that Filesystem Manager on the local server is not running and will forward the request to the next server for FSM component on that server to get the request processed – through SRBroker on that server– this is the case of intra server communication.

SRBroker maintains a consistent connection with all the components on the local server plus with all the SRBroker components in the enterprise.

The number of tasks for SRBroker is generally kept as the sum of the count of  components on the local server and the number of servers in the enterprise Plus 20.

SRProc  or Server Request Processor– SRProc is responsible for processing asynchronous requests. It picks the requests from S_SRM_REQUEST Table for the components that are hosted on the server on which particular SRProc is running. SRProc works in conjunction with SRBroker meaning that – once SRProc picks up the requests from S_SRM_REQUEST Table for the components on that server – it will pass on the requests to the destined components through SRBroker.

The number of running tasks for SRProc on the server should be 3 while in actual it is 4. There is one hidden task. One SRProc maintains consistent connection with the SRBroker on the server. So if the SRBroker is down on the server for some reason and you try to bring up SRProc it will not start – you first need to start SRBroker.



Main Points:

  • Understand How Buffer Cache Works
  • Measure Buffer Cache Performance
  • Improve Buffer Performance

Why use Buffer Cache

• Data accessed from Memory is faster than data accessed from disk.

Understand Buffer Cache Working
• What is in buffer cache
o Blocks for – Tables, Indexes, Clusters,
o Blocks for – LOB Segments, LOB Indexes
o Blocks for – Rollback Segments (UNDO)
o Blocks for – Temporary Space

Different types of Block
Free – block not currently used
Pinned – block currently used by server process
Clean – block that was just used and now is ready to be re-used
Dirty – block that needs to be written to disk because it contains committed data

•  LRU list
Data blocks from data files are put on the MRU side of the LRU list (exception is FTS)
•  Dirty List
Keeps track of dirty blocks
•  User Server Processes (Shared Server Processes)
First check if the data requested by user is already in the buffer cache If not, it searches LRU list to find out free blocks. (Statistics: “Free Buffer Inspected”). Reads data from data file into free blocks in buffer cache
•  DBWR process
Moves dirty blocks from LRU list to Dirty list.Write dirty blocks to Data file

Measure Buffer Cache Performance

• Hit Related Stats (V$SYSSTAT)
o Buffer Cache Hit Ratio (should be > 95% for OLTP)
Physical Reads
Physical Reads Direct
Physical Reads Direct(LOB)
Session Logical Reads

• Non-hit related Stats (V$SYSTEM_EVENT & V$SYSSTST)
o Free buffers inspected (v$sysstat)
o Free buffer wait (v$system_event)
o Buffer Busy Wait (v$system_event)

What is stored in V$SYSSTAT
All system wide events and their cumulative values from the last instance startup
• STATISTIC# –  Statistics ID
• NAME  – The name of the statistic
• CLASS –  Category the statistic falls into
o 1 User
o 2 Redo
o 4 Enqueue
o 8 Cache
o 16 Operating System
o 32 Real Application Cluster
o 64 SQL
o 128 Debug
• VALUE Current value of statistic

There are over 200 different statistics tracked by the V$SYSSTAT view. However, only four of these are used when
calculating the performance of the Database Buffer Cache which are as follows:

Hit Related Stats (Increase hit ratio)

•  Physical Reads: This statistic indicates the number of data blocks (i.e. tables, indexes, and rollback segments) read from disk into the Buffer Cache since instance startup.

•  Physical Reads Direct This statistic indicates the number of reads that bypassed the Buffer Cache because the data blocks were read directly from disk instead. Because direct physical reads are done intentionally by Oracle when using certain features like export or Parallel Query.

•  Physical Reads Direct (LOB): This statistic indicates the number of reads that bypassed the Buffer Cache because the data blocks were associated with a Large Object (LOB) datatype

•  Session Logical Reads: This statistic indicates total number of reads requested for data. This value includes requests satisfied by access to buffers in memory and requests that caused physical I/O

Non-hit related stats (Minimize them) 

• Free Buffer Inspected: Number of Buffer Cache buffers inspected by user Server Processes before finding a
free buffer.

SELECT name, value
FROM v$sysstat
WHERE name IN (’free buffer inspected’)

• Free Buffer Waits: These waits occur whenever the Server Process had to wait for Database Writer to
write a dirty buffer to disk (DBWR)

SELECT event, total_waits
FROM v$system_event
WHERE event = ’free buffer waits’

• Buffer Busy Waits :These waits occur whenever a buffer requested by user Server Processes is already in memory, but is in use by another process. These waits  can occur for rollback segment buffers as well as data and index buffers (DBWR)

SELECT event, total_waits, average_wait
FROM v$system_event
WHERE event = ’buffer busy waits’


SQL>SELECT name,value,
3 WHERE name IN (‘free buffer inspected’)
5 SELECT event,total_waits
7 WHERE event in (‘free buffer waits’,’buffer busy waits’);

————— —–
buffer busy waits 170
free buffer inspected 0

High or steadily increasing values for any of these statistics indicate that User server processes are spending too much time
searching for and waiting for access to free buffers in the Database Buffer Cache

User Request flow in siebel

How does a User Request flow in siebel?

Sample URL to be used throughout:

When a user hits this url – – this part of the URL gets resolved to the IP Address Of the Load Balancer which is used for load balancing the Siebel Webservers. Depending on the type of the routing rule configured at the Load Balancer – mostly the round robin is used – the requests are forwarded to the webservres.

What Happens  at the Webserver Level:

Webservers – To accept and forward user request. Following things happen at the webserver level:

  • Virtual to physical directory conversion. This is required for security purpose and to keep the users unaffected even if there is a change in the physical paths on the server for some reason.
  • After the Virtual to Physical conversion the request is picked up by the SWSE – which is a plug in for Siebel on webserver.
  • SWSE reads the URL and tries to locate the section present in the URL and searches for the same in the Eapps.cfg file.

For example in the sample url – the SWSE will look for the string /crm  in the eapps.cfg file – which will be present in the eapps.cfg as shown below:


ConnectString = siebel.TCPIP.None.None://VS_eCommunication/enterprise1/eCommunications_enu

WebPublicRootDir = d:sea78SWEApppublicenu

WebUpdatePassword = RhirdYbPrARxuzwfy2zwtwEdxrYo

  • Once the section with the portion of the URL in the eapps.cfg (in this case /crm) is located the instructions within the section are followed – which normally gives a call to the Lbconfig.txt file –  VS_eCommunication  – in the section shown in point 3 is present in the lbconfig.txt file which is shown below:

VS_eCommunications =1:abc:2321;2:def:2321;3:ghi:2321

Once the pool is located in the lbconfig.txt SWSE picks up the hostname and port number (2321 –SCBrokerPort) on  a round robin fashion from the list of servers in the pool and throws the request on port 2321 of the selected hostname. Thus SWSE uses lbconfig.txt to retrieve the hostname and port number to send the request Plus performs load balancing for a pool of Object Manager servers as well.

What  Happens at the Application and Database Server:

  • The request thrown on port 2321 from the webserver  is received by SCBroker .
  • SCBroker  looks at the process section of the shm file and determines which process has the least load and forwards it to the process with the least load( this happens after Siebel 7.5)
  • The process starts a task for the request – which in turn creates a DB session – authenticates the user at DB level (here we are just using the case of DB Authentication)
  • Once the user is authenticated the task takes care of building the session and page for the user by pulling the data for the user form the database and filling it in Web Template.

One point worth mentioning here is that the login page is presented to the user only when the anonymous user mentioned in the eapps.cfg file at the webserver  is verified at the Database level.(If we are using DB Authentication).

Siebel CTI

What is CTI:

  • CTI stands for Computer Telephony Integration
  • This is basically the controlling of your Teleset/Turret/Telephone through the Application and hence the name Computer Telephony Intergration
  • It can be considered as a separate Application embedded within Siebel

Why CTI is used :

  • The motive of using CTI is to
  1. Reduce the call handling time. How that will be explained in the later section
  2. Route the calls effectively based on Individuals skills

How CTI works:



1 – 2 User’s Login Request Path

1(Ret) – 2 (Ret) – User’s Login Response Path

A – D – How an Incoming call is routed


There are 2 different scenarios that can be considered:

1. When the Advisor logins to CTI :

First we will consider the parameters that are required and then we will go ahead with the login process

When the Advisor login to CTI following parameters are required:

  1. PIN for the Advisor – This is required to uniquely identify the Advisor based on his skills at Genesys End. There can be 2 scenarios possible with the PIN:
    • If the Advisor has his PIN configured on Siebel then when the advisor presses the login to CTI button his request is auto taken care of that is without asking for the PIN to be entered
    • If the PIN is not configured for the advisor then the advisor is requested for the PIN upon pressing of the login to CTI button.
  2. Barcode for the Advisor – This is an environmental variable at the local Machine level (Computer). This is required as the Teleset details are mapped to the Barcode at the table level in Siebel and Siebel internally queries against the barcode to get the teleset and teleset extensions (Explained in the Next point) for the Desk Position.
  3. Teleset Extensions: There are basically 2 types of extensions associated with a Teleset:

A. A Type Extension: This is basically the Extension that is recognized by Genesys and used in their queues for their call routing purpose

B. S Type Extension: This extension is used when the Advisor makes an      outbound call that is a call made to the customer or the external world

What Happens when the Advisor logins to CTI:

1.When the Advisor clicks on the Login to CTI Button a request is sent to Genesys with the PIN for the Advisor and his/her teleset extensions(Of course these extensions are taken as a result of the query that Siebel Application runs internally on the barcode to get these teleset details ).

2. Genesys checks whether the parameters sent in Step1 (PIN  and Teleset Extensions) are configured at its end. If yes then a positive response is sent to Siebel Application invoking a Business service which causes the CTI Toolbar to be enabled. If NO then Genesys throws an Error that is presented to the Advisor.

Steps to check the configuration for the advisor will be covered in a separate section

2.When there is an incoming call for the Advisor:

When there is a call made to the service provider on the common number provided by service provider, it comes through IVR (As per my understanding). The information gathered is passed to DMS Switch which in turn passes the same to Genesys so that the call can be destined based on the Skill. Genesys responds to switch with the details of the Advisor (Teleset Details) whom the call is to be directed(This decision is made based on the skills of the Advisor enrolled at Genesys End). Then the Switch takes care of routing business by passing the request to the PBX

Siebel Gateway Server – All about it

What is Siebel Gateway Server and what does it do?

A Siebel Enterprise may consist of multiple servers – which in turn may have multiple components. Now these components will have different parameters. In order to easily manage and maintain all the information for the enterprise – Siebel Gateway was developed. Siebel Gateway is a service or daemon process that maintains the enterprise configuration in a text file called – siebns.dat. As siebns.dat contains all the details for the enterprise – this file is often called as Enterprise Configuration File.

How to check if Siebns.dat file is corrupt:

1. Server Configuration and Management screens will not be accessible and will give an error – An Error has occurred creating business component ‘Server Server’ used by business object ‘Server Admin’. Please ask your system s administrator to check your application configuration. (SBL-DAT-00222)SBL-SCM-00028: Key Not Found.You will also encounter this error – if the siebns.dat file is deleted by mistake.

2. When you try to check the status of the Siebel Service on the Gateway server using the list_ns command – you will see some junk characters rather than the normal service status and its startup time.
3. The size of your latest siebns.dat file will be less than the size of the latest siebns.dat backup file.

Different ways to manually backup siebns.dat file:

Although the Siebel Gateway Service frequently backs up the siebns.dat and keeps the latest five versions of it – we can manually backup the siebns.dat file
1. The siebns.dat file can be backed up from Sitemap->Server Configuration->Enterprise Explorer ->Backup Enterprise Button – this will create the backup for the siebns.dat file in the Admin Folder( on Windows Platform) OR Sys Folder ( on Unix Platform) of the siebel Gateway’s installation Directory. The file created will have a suffix with the timestamp of the file creation.
2. Use the following command from server manager.
backup nameserver file_name

If a file name is not specified, the backup file is named with the date and time in the format siebns.dat_yyyymmdd_hhmmss. This file is stored in the Administration directory of the Siebel Server root directory on Windows and the Sys directory of the Siebel Server root directory on UNIX.

How to increase the log levels for siebel Gateway:

At times I have seen most of the administrators struggling while debugging issues related to Siebel Gateway – as they cannot generate extended or detailed logs for siebel gateway – its very simple:
Under Windows Platform – change the value of the environment variable – SIEBEL_LOG_EVENTS to 4 or 5 to get the detailed logs. The same holds true for Unix Platform. Once the change in the environment variable has taken effect – you can see detailed or extended logs getting written in the nameserver log file.

How to Change the Siebel Gateway Hostname:

Below are the steps that need to be followed when you want to change the Siebel Gateway hostname:
1. Make changes to the .profile file – change the SIEBEL_GATEWAY parameter to reflect the new gateway hostname
2. Change the parameter DSConnectString for the named subsystem GatewayDataSrc by issuing the following command at the ENTERPRISE LEVEL – No need to set or connect to any specific server
Change param DSConnectString=:2320 for named subsystem GatewayDataSrc
3. Change the parameter Host for the gateway siebel server by issuing the following command:
Change param Host= for server
4. Regenerate the svc file by issuing the following command from the $siebel_root/bin directory from each siebel application server:
siebctl -S siebsrvr -i EnterpriseName:SiebsrvrName -a -g “-g NEWGatewayServerHostName:gtwyport -e EnterpriseName -s SiebsrvrName -u sadmin” – e Password -L ENU
5. Restart the Siebel Gateway server
6. Restart ALL the siebel application servers.