Tag Archives: siebel

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.

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 – abc.xyz.com – 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.

FDR Analysis on Siebel


FDR stands for Flight Data Recorder and is a framework in the Siebel Server infrastructure that collects data about the running Siebel application in a circular buffer. In the event of a crash, the data is written in binary format to a file in the application /bin subdirectory. The file that is written has the .fdr extension and can be post-processed into human readable format using the sarmanalyzer.exe utility. The data in the output can help show what was happening immediately prior to the crash in different application subsystems.

NOTE: The application may not generate an FDR file when there is a “soft” crash meaning that the server process exits but is not recognized by the Siebel crash handler. This can happen when one of the following occurs:

  • The Siebel crash handler is disabled (should only happen under the supervision of Technical Support).
  • When the process exits, it does not go through the internal code path that executes the Siebel crash handler logic and none of the related crash output for example the crash.txt file or FDR file is created.


This document is informational and intended for any user.


Here are the high level sections that are covered in this document. Click on any of the items below to jumplink to that section:

  • How to Identify the Correct FDR file When a Crash Occurs
  • How to Process Binary .fdr File into .csv Format and Identify the Crashing Thread
  • How to Flush FDR Output
  • How to Review Entries Prior to Crashing Thread to Understand What Happened Immediately Prior to the Crash
    • Example Case
    • Diagram of Interaction between Elements Involved in Crash Scenario
    • Analysis of the FDR output:
  • Where to go for more information

How to Identify the Correct FDR file When a Crash Occurs

Finding the correct output file can be done by using the information in the .fdr file name. The file name includes a timestamp and the process id that crashed and is written in the format:

T<YYYYMMDDHHMM>_P<process id value>.fdr

For example:


Is a file name that is based on a component that was started on March 18, 2005 at 4:01 PM where the process id value was 1376.

NOTE: Bug 10509303 has been logged to address the documentation defect with how the file format is documented in the System Monitoring and Diagnostics Guide for Siebel Business Applications.

If the process id is known, then look at the second part of the file name to find the correct file, otherwise, use the timestamp in the first part as the guide. NOTE: If a crash_xxxx.txt file is available, convert the hexadecimal process id found in that file to a decimal value to identify the appropriate process id value that should appear in the .fdr output file name. The example below shows a crash.txt file generated in the Microsoft Windows environment.

NOTE: On HP-UX, the crash.txt file that is created in Siebel version 7.7 is a single file that gets appended. The process id is displayed in Decimal format as shown below:

How to Process Binary .fdr File into .csv Format and Identify the Crashing Thread

Here are the steps to follow to post process the raw .fdr file:

  1. Identify the appropriate .fdr file to process using process suggested above.NOTE: On UNIX platforms only, source the shell environment variables, before running the sarmanalyzer utility.
    To do this from the $SIEBEL_ROOT/siebsrvr directory, run the following shell command:

. ./siebenv.sh

  1. Use the sarmanalyzer.exe command line utility and issue the following command:

sarmanalyzer -o <output_csv_file> -x -f <fdr_file>

For example:

sarmanalyzer -o T200503181601_P001376.csv -x -f T200503181601_P001376.fdr

The output .csv file will be written to the SIEBSRVR_ROOT\bin directory unless redirected to a different directory.

NOTE: While you can specific any file name for the .csv file, it is good practice to keep the same file name. This will maintain the date and time stamp as well as the crashing PID designations in the name of the file. This is useful when there are multiple FDR files generated and will provide reference points should these files need to be supplied to Technical Support.

  1. A best practice is to open the output .csv file using a spreadsheet application like Microsoft Excel so that you can easily filter the data.
  1. To do this in Excel you simply open the .csv file, use the Data menu item and select Filter > Auto Filter sub menu items.
    1. Next, to see the entries related to only the crashing thread, filter the SubAreaDesc column by the value ** CRASHING THREAD **.
    1. Select the ThreadID column and filter on the value (in this example, the value is 4068) that appears there for the record.
    1. And then unset the filter on the SubAreaDesc column. This should cause all records with the same thread id as the crashing thread to be displayed. These are the relevant records to review when analyzing FDR output. Please note that several threads may crash before the process is terminated by the operating system, in which case you may find several such FDR records.
    1. Please note that the .csv file created by sarmanalyzer.exe is not sorted. An important step is to sort the file in chronological order. For performance reasons, the FDR file does not contain timestamps. However, you can sort on the FdrID column in ascending order to rearrange the data in chronological order.

How to Flush FDR Output

Besides automatically creating the .fdr output file when a process crashes, it is possible to force the file to be flushed (written to disk) on command. The Siebel Server task id needs to be provided as an argument. The following information describes the steps to force the .fdr file to be flushed.

To cause the FDR buffer for a component process to be written to disk follow these steps:

  1. Identify the task you want to generate the dump for. This can be done by using the srvrmgr.exe command line utility and the list tasks command or navigating to the Administration – Server Management > Server > Tasks view from the Site Map in the Siebel application. For example:

srvrmgr> list tasks

  1. Identify the task id value for the component task that you want to generate the dump for and note it.
  1. Flush the FDR buffer to disk. Using the srvrmgr.exe command line utility and execute the command:

srvrmgr> flush FDR for task <task_id> (for version 7.7. and 7.8)

srvrmgr> flush FDR for process <process_id> (for version 8)

Where task_id in the statement is replaced with the value identified in step 1a.

  1. The FDR file will be written to the SIEBSRVR_ROOT\bin directory with the naming convention:


An example of this is:


This evaluates to an FDR file for process id 2576 where the process was started at approximately 1:23pm on March 12, 2004.

  1. Identify the correct OS thread id for your task. Within the FDR file, each entry includes the OS thread id related to the operation captured, not the task id. To find the relevant OS thread id used by the component task, use the following command on the srvrmgr.exe command line utility:

srvrmgr> list tasks show CC_ALIAS, TK_TASKID, TK_TID, TK_PID

This will generate a list of tasks and include the component alias (CC_ALIAS), the task id (TK_TASKID), the OS thread id (TK_TID), and OS process id (TK_PID).

Note the TK_TID and TK_PID values for the appropriate task id that you have flushed the FDR buffer for. This will help you find the appropriate FDR file described in 2a (the last part of the file name should map to the TK_PID value), and after decoding the file, will help you identify the entries relevant to the task id you are interested in. Each entry should have a ThreadID value equal to the TK_TID value. This is especially important when considering that a single process may have many threads.

How to Review Entries Prior to Crashing Thread to Understand What Happened Immediately Prior to the Crash

General structure of FDR entries includes the following columns:



FdrID The id assigned to a particular FDR entry. Each entry has a different id value.
ThreadID The Operating System thread id. Each entry is associated with a thread, some entries may have the same or different thread id depending on whether the process is multi-threaded or not, and whether more than one thread is in use at the time of a crash.
AreaSymbol Categorization for a particular subsystem so all entries can be grouped together.
AreaDesc Descriptive text of what product area each entry is associated with.
SubAreaSymbol Similar to the area symbol, used to assign a unique categorization within a particular area for different functionality.
UserInt1, UserInt2 Integer values assigned by internal instrumentation that may store values like internal pointer references; this is normally only useful to Oracle Engineering.
UserStr1, UserStr2 These columns provide contextual information that is germane to understanding the significance of each entry and that may store object names, parameter values, row_ids or other messages that help indicate some context within the area and sub-area.

Example Case

A custom DLL has been developed that can be called when string transformations are necessary. The DLL is called from a business service that includes custom eScript code to pass a parameter to the DLL and receive the output from it. In a particular implementation, eScript code on the Account business component WriteRecord event calls a workflow process that uses the business service. The script passes the location value of the account to the workflow, the workflow process passes the value as a process property to the business service, and that value is in turn passed to the DLL for processing.

In this scenario the DLL is incorrectly implemented in a way that causes the DLL to exit unexpectedly, and this in turn will cause the OM process hosting the user session that invokes the DLL to crash. The FDR output can be examined to show what the user session was doing prior to the crash and what happened in the different internal subsystems the object manager, scripting, and the workflow manager to track down the point of failure to the workflow process and to the step that calls the DLL.

Diagram of Interaction between Elements Involved in Crash Scenario

Steps to cause the failure:

  1. Login to the Siebel application and navigate to the Account List View.
  1. Create a new Account with a location value of New York and step off the record to commit it.
  1. Because the DLL will fail when the location value is set to TT, set the location of the record to TT and step off the record to commit it.
  1. Step #3 will cause the Object Manager process to crash, and an FDR file will be written to disk at SIEBSRVR_ROOT/bin. The web client behavior will be to display an error indicating that the Server is busy, and the client will need to initiate a new session if they want to continue using the application.
  1. The .fdr file will need to be post-processed using the sarmanalyzer.exe utility to determine what happened before the crash.

Analysis of the FDR output:

See the section above called “How to process binary .fdr file into .csv format and identify the crashing thread” for details on how to post-process the binary .fdr file and get the .csv file into the proper order showing the records of the session relevant to the crash.

After sorting the content of the .csv file by the FdrID column, scroll down to the bottom of the list and work up to see the last few entries prior to the record showing the crashing thread. The entries prior to the last one show what happened prior to the crash.

The output will help to show things like:

  1. The SWE command executed in the client to navigate to the Account List View.
  1. The applet where the account record is written.
  1. The business component and script event that is executed.
  1. The different methods that are invoked by the BusComp_WriteRecord event and what script language is used.
  1. The call in the script to invoke a workflow, and its execution by the workflow subsystem.
  1. The invocation of the business service and method from within the workflow and by the object manager.
  1. The execution of the script methods in the Service_PreInvokeMethod event.
  1. The last successful operation is the GetProperty(WF_LOC) call in the AA business service so it can be deduced that the next call in the business service  SElib.dynamicLink(“revstr.dll”, “_BlockRev@4”, CDECL,myloc); – is the point of failure. In fact, when reviewing the DLL code, it can be determined that the point of failure occurs when the DLL receives a value of TT and the file object is never initialized prior to an attempt to write to it.
  1. Finally the crashing thread.

In this case, analyzing the FDR output quickly shows:

  • the interaction of several subsystems in the product,
  • helps deconstruct how each one is utilized prior to a crash, and
  • assists in pinpointing the last several operations prior to the failure.

Given this information it is possible to reconstruct what led to the failure, the likely cause, and the areas to focus diagnostic and recovery efforts.