Siebel Error: "SBL-SCM-00028: Key not found"

This error will occur when there are corrupt Enterprise entries in the siebns.dat file.






Please follow the below steps to remove the corrupt entries from the gateway name server configuration and thus from the siebns.dat file. Do not directly modify the siebns.dat file.

1. Stop all web servers.
2. Stop all Siebel servers.
3. Use the Enterprise configuration wizard to remove the corrupt enterprise.
4. Restart the gateway name server.
5. Start the Siebel servers.
6. Start the web servers.

Siebel Error: "SBL-DBC-00105: An error has occurred executing a Sql statement"

This error occurs mostly in 2 scenarios:

1. When a user navigates to a View and executes a query in an Applet.
2. When a Business components has 2 fields mapped to the same column.

This error is generated when an SQL SELECT statement fails to execute against the database.

In Order to troubleshoot this error, we need to capture the SQL which can be done in below ways:

• spool the sql using the /s option, if the error is reproducible in the mobile client or dedicated client.This spools all the SQL's generated into a log file by the application and allows to identify the problematic SQL.
• If the error is reproducible only in the thin client, then we need to raise the log level for the Application Object Manager component and identify the sql from the resultant logs.

The error can be encountered due to various reasons. Below are some of them:

1. Logical and Physical schema are not in sync.
2. A field without mapping to a column.
3. A field with a calculated value without the calculated value set to True.
4. A field on link is defined as a calculated field
5. A join specification field based on a calculated field.
6. Incorrect permissions are set on the table at the database level.
7. A join in the select statement is specified more than once.
8. There is a difference in the field type and length at the business component field definition versus the table column definition.

Siebel SCBroker Error: "SBL-SCB-00011: Failed to connect to pipe (SEBL_0_pid) on process pid"

The Siebel Connection Broker (SCBroker) is a server component that provides intraserver load balancing. SCBroker distributes session login requests across multiple instances of Application Object Managers (AOMs) running on a Siebel Server. SCBroker logic will always route the request to the AOM process that has the least number of running tasks.
Under certain scenarios, an AOM process can be in a hanging state and is not able to acknowledge connection requests from the SCBroker anymore. If this hanging AOM process happens to have the least number of running tasks, SCB will attempt to route new session requests to this AOM process repeatedly. This results in blockage of all new login requests on that Siebel Server.






The scenario that SCBroker can not connect a new session to an existing object manager process because this process itself is hanging, can usually be determined by the following entry in the swse log file:

[SWSE] Open Session failed after 60.1958 seconds.
[SWSE] Failed to obtain a session ID. Login failed attempting to connect to %1
[SWSE] Set Error Response (Session: Error: 10879185 Message: Login failed attempting to connect to siebel.TCPIP.None.None://hostname:2361/enterprise/SCCObjMgr_enu)
[SWSE] Login failed.
SBL-SSM-00005: Timeout occurred while opening SISNAPI connection.
Login failed for Login name : SADMIN
[SWSE] Open Session failed (0xa600d1) after 60.0111 seconds.

Note the last line where we see a connection timeout of 60 seconds displayed.
This is the built in timeout of 60 seconds after which a request from SWSE plugin to the SCBroker is cancelled.
From that message we can conclude that SCBroker was not able to transfer a login request to a working object manager on node 'hostname'
We can also conclude that the object manager process is still running since it is still in SCBrokers routing table, however it does not accept new connections.

This is usually caused by an MT process hang scenario.




The following criteria also should be met to confirm a deadlock behaviour:

1. Every login attempt to a certain AOM on the affected Siebel Server is prompted with the message: "SBL-SWP-00121: The server you are trying to access is either busy or experiencing difficulties. Please close the Web browser, open a new browser window, and try logging in again."
2. It takes approximately 60 seconds until the server busy message appears.
3. AOM tasks might be staying in the state “Handling Logon” or ”Relogin”.
4. The SCBroker log is continuously logging the following error message: "SBL-SCB-00011: Failed to connect to pipe (SEBL_0_pid) on process pid". where pid is the process id of the corresponding object manager process. This process id can be found in the enterprise log to associate it with a certain AOM.

The workaround to get the SCBroker process operative again is to terminate the hanging AOM process manually. This can be done using the kill command on UNIX or the Task Manager on Windows. 

Once the offending process has been terminated, SCBroker will continue normal distribution of new session requests across the remaining AOM processes.

To help us in this situation there is a new SCBroker parameter "ConnForwardAlgorithm" or "Connection Forward algorithm for SCBroker".

This is a hidden parameter.

This parameter determines which algorithm is used to forward incoming login requests to MT server processes. There are two possible methods:

a) Least Loaded "LL", the default 

and 

b) Round Robin "RR"

Note that this parameter is an advanced parameter as can be seen in following srvrmgr example:

srvrmgr> list advanced param ConnForwardAlgorithm for comp SCBroker show PA_ALIAS, PA_VALUE, PA_NAME

Although LL is advisable in terms of performance, in case of a SCBroker hang this is causing unwanted behavior: once SCBroker has identified the least loaded process, it will reconnect to this particular pid until next session is established. Now in the case that the supposed to be least loaded process is hanging, SCBroker will try that process again and again and we might see stalling logins on all web servers.

In this situation, the algorithm should be changed to "RR".

This has two advantages:

1) The hanging process will only be contacted once. Next attempt is going to next available pid as described in the routing table. The effect will be that only one login is affected, and the consecutive logins will be successful until the hanging process is revisited. In that way, all requests will be distributed among the remaining, non-hanging processes and end users should get server busy message only once and a retry should them connect to a working process.

2) By monitoring the task distribution you can identify the process id that is not getting additional hits.

This process id is very likely the culprit.

The following srvrmgr command can be used in order to switch the forwarding mode:

Using srvrmgr with the /s switch, connect to the siebel server corresponding to the hostname as identified by the hostname in the swse error message.

Then change the parameter:

change param ConnForwardAlgorithm=RR for comp SCBroker

Now restart SCBroker component:

shutdown fast comp SCBroker

startup comp SCBroker

Now you can monitor for which particular process id the number of running tasks value is not increasing anymore:

list procs for comp <interactive_comp_name> show TK_PID,TK_NUM_NORMAL_TASKS

If you encounter hanging processes on multiple server nodes, then you need to change the parameter value to RR on all of these nodes.

Please note that the SCBroker forwarding mode is local to each siebel server in the enterprise, so you can have mixed LL and RR configuration within an enterprise.

It should also be mentioned that existing, established sessions are not affected by the SCBroker component  bounce.

Established session will continue to work even when the SCBroker is temporarily unavailable.

By running the round robin scheduler mode  of versions as stated above, it is possible to distribute incoming login requests to all processes that in this moment are still able to process requests.

Siebel Error: "The server you are trying to access is either busy or experiencing difficulties."

Below is the full error message when user tries to login to the thin client using URL:

"The server you are trying to access is either busy or experiencing difficulties. Please close the Web browser, open a new browser window, and try logging in again. [hh:mm:ss]"






Below are some high level steps to troubleshoot and narrow down the issue:

• Bounce the whole Environment
• Stop the Web Server, Siebel server and the Gateway server in the same order.
• Restart the Siebel Gateway server, Siebel server and the Web server.
• wait for 3 to 5 minutes to give time for the Object manager to load and then try to open the URL.

• Is the Gateway server and the Siebel are up and running
• In Windows open the services.msc from the Start>Run command and check if the services for the Gateway server and Siebel server are running.

• Can we connect to Web server
• try to hit the below URL mentioning the address of the webserver             http://webserver
• This should open the web server default page or else it is a problem with the web server.

• Is the web server recognizing the Siebel request for SWE plugin
• Hit the below URL                                                                   http://webserver/emedia_enu
• This should automatically append the start.swe and should look like http://webserver/emedia_enu/start.swe
• If you do not see this, then the web engine is not properly configured.

• Can you load the Stats Page
• Hit the below URL and check if the Stats page is loading http://webserver/emedia_enu/_stats.swe
• If this does not show the statistics, then either the web server or the SWE eplugin are mis configured.

• Verify theSWEApp logs for the specific time frame you got the error message when you login

• Check the eapps.cfg file to see if the web server can route to a Siebel server
• Check the "ConnectString" parameter for the exact path to the Siebel server.
• try to do a continuous ping to the Siebel server, Gateway server from the web server and reverse too.

• Anonymous User information
• Check for the Anonymous user credentials in the [Default] Section of the eapps.cfg file.

• Check if the Siebel server and OM are in running status
• connect to srvrmgr and issue the below command to check the status of the Siebel server. It should be in "Running" status.                                                                            srvrmgr>list server
• Check the status of the OM component.It should be in "Running" status.                       srvrmgr>list comp <OM Alias>                                                                              svrrmgr> list comp <object manager alias> show CC_ALIAS, CP_DISP_RUN_STATE  
• Check for the tasks for the component on the Siebel server                                     srvrmgr> list tasks for comp <OM Alias>                                                            srvrmgr> list tasks for comp <OM Alias> show TK_TASKID, TK_DISP_RUNSTATE, TK_LABEL 
• If there are more than 1 tasks running then the request has successfully routed from web server to the Siebel server and to the OM component.
• If not, then check for the connectivity b/w web server, Siebel server and Gateway server.

• Check Database connectivity and able to login with SADMIN
• Issue the below command in srvrmgr                                                                     srvrmgr> List param DSConnectString for named subsystem ServerDataSrc show PA_ALIAS, PA_VALUE
• The results should show the PA_ALIAS as DSConnectString and PA_VALUE as the name of the connection entries above, Net Service Name for Oracle, DB2 Database entry for DB2 and System Data Source for Microsoft SQL Server.
• If this value is incorrect, then change it to the correct value as below:                  srvrmgr> change param DSConnectString="<connectstring value>" for named subsystem ServerDataSrc

• License Keys
• Check if the correct license keys are entered.

Siebel genbscript Error: "Couldn't enumerate buscomps "

This Error "Couldn't enumerate buscomps <Initial>" might occur when you try to generate Browser Scripts using genbscript utility in Siebel.
Below is a screenshot of the same error:

The Error usually occurs when you get a fully compiled srf from one environment and try to use it in a different environment.

The error occurs due to missing [DataSources] definition for EBC's defined in the source environment.






Normally, DataSources are defined in the application cfg file in a local db while the same are defined in Administration - Server Configuration > Enterprise Profile Configuration view in the server.

To find the exact missing DataSource, we have to capture the logs for the session running the genbscript.exe

Steps to Increase Log level & find the DataSource name:

1. Create an Environment variable on the machine where you are running the utility SIEBEL_LOG_EVENTS = 5
2. Run the genbscript utility to get the error message.
3. Open siebel.log in the [Siebel root]\client\log directory.
4. Go to the line for the same error and then navigate to the steps prior to the error message.
5. You will find the name of the missing DataSource definition.

Next, you need to create a dummy DataSource definition in the application cfg file like below:

Add under [DataSources]

TESTSOURCE = TESTSOURCE (where TESTSOURCE is the name of the missing DataSource from the log file)

Add after [ServerDataSrc]

[TESTSOURCE ]

Now, try running the genbscript utility using the same cfg file where you added the DataSource and it should run fine without any errors.

Siebel: Troubleshoot Siebel eMail Response

Communications Inbound Receiver (CommInboundRcvr) and Communications Outbound Receiver (CommOutboundRcvr) Server components are used to process incoming emails and outgoing emails.
Below are the basic diagnostics steps performed to collect the necessary logs for further troubleshooting:

• Increase logging for Communications Inbound Receiver (CommInboundRcvr) component:

1. Login to the Siebel application as SADMIN.
2. Navigate to "Administration - server configuration>Components view.
3. Query and select "Communications Inbound Receiver" component.
4. Increase the log level in the events tab.
5. Bounce the Siebel server.
6. The Communications Inbound Receiver tasks starts automatically and process incoming emails for the active Response groups.
7. Logs are generated in SIEBEL_ROOT\siebsrvr\log directory.

• Capture the Inbound Emails:
1. Login to the Siebel application as SADMIN.
2. Navigate to Communications Administration > Communications Drivers and Profiles view.
3. Select the Internet SMTP/POP3 server communications driver.
4. In the "Drivers parameters" applet, set the below parameter:
• Delete Processed Messages = "FALSE"
5. Bounce the "Communications Inbound Receiver" component.
6. Successfully processed email messages are stored in SIEBEL_ROOT\SiebSrvr\bin\processed directory.
7. Failed emails are stored in SIEBEL_ROOT\SiebSrvr\bin\failed directory.

• Capture SMTP/POP3 protocol:
1. Login to the Siebel application as SADMIN.
2. Navigate to Communications Administration > Communications Drivers and Profiles view.
3. Select the Internet SMTP/POP3 server communications driver.
4. In the "Drivers parameters" applet, set the below parameter:
• LogDebug = "TRUE"
5. logs are generated at SIEBEL_ROOT\SiebSrvr\log directory. check for POP3SMTP*.log file or IMAPSMTP*.log.

• Event Fields files
• As the Siebel eMail response downloads the email messages from the monitored mailbox, the Internet SMTP/POP3 server component driver parses them and generated EventFields file for each inbound email message. They are temporarily stored in SIEBEL_ROOT\SiebSrvr\bin\queued\<eMail Response group name> directory. These are passed to the workflow process to handle the incoming message.

• Capture the Outbound Emails:
1. Login to the Siebel application as SADMIN.
2. Navigate to Communications Administration > Communications Drivers and Profiles view.
3. Select the Internet SMTP/POP3 server communications driver.
4. In the "Drivers parameters" applet, set the below parameter:
• Save Sent Messages = "FALSE"
5. Failed emails are stored in SIEBEL_ROOT\SiebSrvr\bin\sent directory.

Siebel Synchronous and Asynchronous Server Requests

Requests are tasks processed by the batch components. SRBroker and SRProc components are responsible for routing the requests from the requestor to the target component.

SRBroker (Server Request Broker)

SRBroker routes requests to target components based on the information in the request. At least one instance of SRBroker component should be running on each Siebel server. SRBroker caches information from the Gateway name server and knows which component is running in which Siebel server. It also caches information from the shared memory and knows which component is running in the local Siebel server. Each instance of SRBroker communicates with other SRBroker components running on the same Siebel server or other different Siebel servers to route requests in the same Enterprise. 

For more details regarding SRBroker, click here

SRProc (Server Request Processor)

SRProc processes server requests that are stored in the Siebel database. SRProc has connection information to the Siebel database and it stores and retrieves information from the S_SRM_REQUEST table. SRProc communicates with only the SRBroker component running on the same Siebel server. Every SRBroker will connect to SRProc in the same Siebel server to send requests for storing them in the database. SRProc will connect to one of the SRBroker components in the same Siebel server to forward requests for processing. Successfully completed requests are removed from the S_SRM_REQUEST table by the component "Server Tables Cleanup" (SvrTblCleanup).

For more information regarding SRProc, click here

There are 2 different types of server requests:

1. Synchronous: The requests are send to the target component and the requestor waits for a response.
2. Asynchronous: The requests are send to the target component and the requestor does not wait for a response. The requestor also does not trigger any callback after it gets a response. We can also schedule a start time while submitting requests.

Server Requests - Routing logic

If the target component is running on the same Siebel server as the requestor, SRBroker will always route the request to the instance of the component running on the  same Siebel server. SRBroker will never route requests to other Siebel servers, if the component is running in the local Siebel server.

If the target component is not running on the same Siebel server, then SRBroker routes the request to other Siebel server where the component is running. If the target component is running on multiple Siebel servers, then it uses Round Robin fashion to route subsequent requests among the Siebel servers.

Routing logic - Same Siebel server

• Synchronous Request: SRBroker will route the request to the target component if it has already established a Siebel Internet Session API (SISNAPI) connection. If there is no connection, SRBroker will establish one upon getting the first request for the component. Once the component finishes processing the request, it sends the response to SRBroker. SRBroker then sends back the response to the requestor.
• Asynchronous Request (DirectDb Mode): Any requests from the requestor will be written to the S_SRM_REQUEST table first. Any SRProc component can pickup the request as long as the target component is running on the same Siebel server.
• Asynchronous Request (Asynch Mode): If the target component is running on the same Siebel server, then routing is same as synchronous mode without any response.
• Scheduled Asynchronous Request: SRBroker on the local server of the requestor will send the request to SRProc, which first writes the request to the S_SRM_REQUEST table. When the scheduled start time is current, any SRProc from any Siebel server can pickup the request from the database and send it to the SRBroker on the same Siebel server, which in turn routes it to the target component.After the component finishes processing the request, it sends response to SRBroker. SRBroker sends the response to SRProc. SRProc will update the record for the request in the database with the response.

Routing logic - Multiple Siebel servers

• Synchronous Request: If the target component is not available on the local Siebel server as the requestor, then the SRBroker in the local Siebel server will send the request to another SRBroker on the first Siebel server where the component is enabled and online. If the request's target component is running on that Siebel server, SRBroker on that server will route the request to the component. Once the SRBroker receives response from the component it will send the response back to the original SRBroker, which in turn sends the response back to the requestor. If the target component is not running on the first Siebel server, the SRBroker on the local Siebel server will try the next Siebel server that has the target component running. If the component is unavailable in any of the servers, then the request fails.
• Asynchronous Request (DirectDb Mode): Any requests from the requestor will be written to the S_SRM_REQUEST table first. Any SRProc component can pickup the request as long as the target component is running on the same Siebel server.
• Asynchronous Request (Asynch Mode): If the target component is running on the same Siebel server, then routing is same as synchronous mode without any response.
• Scheduled Asynchronous Request: SRBroker on the local server of the requestor will send the request to SRProc, which first writes the request to the S_SRM_REQUEST table. When the scheduled start time is current, any SRProc from any Siebel server can pickup the request from the database and send it to the SRBroker on the same Siebel server, which in turn routes it to the target component.After the component finishes processing the request, it sends response to SRBroker. SRBroker sends the response to SRProc. SRProc will update the record for the request in the database with the response.

Load balancing

1. If there are more than one instance of the target component are running on the local Siebel server as the requestor, SRBroker will use Round Robin logic to route the requests among the components.
2. If and only if the target component is not available on the local Siebel server as the requestor, SRBroker on the local Siebel server will send the request to other SRBroker on other Siebel servers on a Round Robin fashion.

Siebel: Increase Tracing for Workflow Process Manager and Workflow Process Batch Manager

Workflows in Siebel can be run in the below ways:

• Server Component: Workflow Policy, Repeating component request, srvrmgr, submitting a task for the component, eScript (submitting request for the component), Runtime events (submitting request for the component). In all the above ways, the request for the Workflow process execution is done by the Workflow Process Manager component (WfProcMgr) or the Workflow Process Batch Manager (WfProcBatchMgr) component.
• Application Object Manager:  Runtime event, Scripting and simulation in the Thin Client.
• Client: Runtime event, Scripting and simulation in the mobile web Client or the Dedicated Client.

Tracing on Server:

Increase the Log level for the below events for the Workflow Process Manager component (WfProcMgr) or the Workflow Process Batch Manager (WfProcBatchMgr) component.

Event Type	Log Level
Task Configuration	5
Object Manager SQL Log	5
Workflow Definition Loading	5
Workflow Engine Invoked	5
Workflow Process Execution	5
Workflow Step Execution	5
Object Manager Business Component Operation and SetErrorMsg Log	5
Object Manager Extension Language SetErrorMsg Log	5
Object Manager Business Service Operation and SetErrorMsg Log	5
SQL Tracing	5

The changes will take effect immediately and does not need a server bounce.The Workflow Process Batch Manager log file (WfProcBatchMgr_xxx.log) and the Workflow Process Manager log file (WfProcMgr_xxx.log) are located in the SIEBSRVR_ROOT\log directory.

Tracing on the Application Object Manager:

Increase the log level for the below for the Application Object Manager component like the Callcenter Object Manager.

Event Type	Log Level
Task Configuration	5
Object Manager SQL Log	5
Workflow Definition Loading	5
Workflow Engine Invoked	5
Workflow Process Execution	5
Workflow Step Execution	5
Object Manager Business Component Operation and SetErrorMsg Log	5
Object Manager Extension Language SetErrorMsg Log	5
Object Manager Business Service Operation and SetErrorMsg Log	5
SQL Tracing	5

The changes do not need a server bounce and the log for the application Object manager is generated at SIEBSRVR_ROOT\log directory.

Tracing on the Client:

Set the below environment variable and the siebel.log will be generated in <ClientRootDir>\log directory

SIEBEL_LOG_EVENTS = 5

Siebel: How to manage the size of Siebel Log Files

2 Siebel component parameters will help us in managing the size of the logs and also to restrict the amount of disk space that is used.

• LogSegmentSize

This parameter defines the size of each segment of the log file. If we give the value as 128, then each segment will be of 128 kilo bytes. A value of  '0' turns off segmenting.

• LogMaxSegments

This parameter defines the maximum number of  segments that are kept. when it reaches the maximum value, it overwrites the segments. A value of '0' turns off segmentation.

Configuring Log Segments on the Siebel Server

 Run the below commands from the server manager command line interface (SIEBEL_HOME\siebsrvr\BIN\srvrmgr.exe):

change param LogSegmentSize=<value> for comp <comp name>

change param LogMaxSegments=<value> for comp <comp name>

Restart the component for the changes to take effect.

Configuring Log Segments on Siebel Web Server Extension

We set the parameters "LogSegmentSize" and "LogMaxSegments" in the eapps.cfg file.

The eapps.cfg file is located in the SIEBEL_HOME\SWEApp\BIN directory.

Bounce the web server for the changes to take effect.

To set the parameters back to default, set them to '0'.

Siebel: How to Analyze FDR output in Siebel

FDR or Flight Data Recorder is a Siebel server framework which collects the data about the siebel application in a buffer and flusher the data into a binary file with .fdr extension in the event of a crash. The file is located in the /bin directory. This binary .fdr file can be processed into a readable csv file to help us analyze and understand the exact prior steps before the crash has happened.

Identifying the correct FDR file when a crash occurs

We can use the information in the file name of the .fdr file to identify the correct file.

The file name has the timestamp and the process id that crashed in the below format:

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

for example:

T201503130749_P017144.fdr 

Is a file name that is based on a component that was started on March 13, 2015 at 7:49 AM where the process id value was 17144.

If we know the process id that has crashed, we can find the file by it or else we can look at the files at with the timestamp.

If we have the crash_***.txt , we can convert the hexa decimal process id found in the file to a decimal value and then find the correct fdr file.

Process Binary .fdr file to .csv file

• In UNIX environment, run the environment variables before running the sarmanalyzer.  run the below command from the $SIEBEL_ROOT/siebsrvr directory:
• . ./siebenv.sh
• Run the sarmanalyzer by issuing the below command:

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

                       For example:

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

 The output .csv file will be written to the SIEBSRVR_ROOT\bin directory.

Analyze output of fdr file

1. Open the csv file using microsoft excel and add custom filters to the top column as below
   
2. Filter the SubAreaDesc column by the value ** CRASHING THREAD **.
   
3. Note down the value in the "ThreadID" column. in this case it is 163. This is the crashing process Id.
   
4. Now, remove the filter for the "SubAreaDesc" column and filter the "ThreadID" column with the earlier noted down Process Id (pid) which is 163 in this case like below
   
5. Now navigate to the end of the document to reach the crashing thread and then we can see the steps that got executed just before the process crashed. you can get more details from SubAreaDesc, UserInt1, UserInt2, UserStr1, UserStr2 columns
   
6. The fdr output file created by sarmanalyzer.exe is not sorted in chronological order fro performance reasons. we can sort the csv file on the "FdrID" column to sort in reverse chronological order.
   

Siebel: Testing Siebel Inbound Web Service on a Mobile Web Client

Siebel Mobile Web Client can serve the same web services that are deployed on the Siebel server.
This helps developers in testing their Inbound Web Services without going through installing the whole Siebel enterprise.

The Web service functionality is an extension of the Siebel mobile web client and is processed by a second siebel.exe process. As soon as the siebel mobile client is started, this second siebel.exe process also starts and listens on a specific port which we define in the client's .cfg file. The child process exits once we logoff the mobile web client.






This setup supports authentication in URL format, SOAP headers, WS-Security headers.
It does not support Single sign-on,  stateful and stateless.

We need to add the below 2 parameters in the client's .cfg file to enable Web services on mobile web client.

• set the following parameters in the [siebel] section of the client's .cfg file:
• EnableWebServices = TRUE
• WebServicesPort = port number to lister (default is 2330)

After this, once the siebel mobile web client starts, you can see 2 siebel.exe processes, one if which will accept and process web service requests.

We can also start the siebel.exe process which will support the web services without starting the siebel mobile web client by running the below command:

• SIEBEL_CLIENT_ROOT\bin\siebel.exe /l <language_code> /c <configuration_file> /u <username> /p <password> /d <datasource_in_cfg> /webservice <port_number>

• for example:  C:\Siebel\8118\client1\bin\siebel.exe /l enu /c enu\uagent.cfg /u SADMIN /p SADMIN /d Sample /webservice 2330
• To stop the process, you have to manually end the process from Task manager.

You can use the netstat utility from the DOS prompt to determine if the siebel.exe process is listening to accept and process requests:

• From the DOS prompt, give the below command:
• netstat -a -p TCP
• examine the output for the port number and it should be "LISTENING"

Now, we can invoke Web services on the Siebel mobile web client by passing credentials in the URL, in the SOAP header, or in the WS-Security header.

Example of Passing User Credentials in the URL

The URL format is:

http://<host>:<port>?SWEExtSource=WebService&Username=<username>&Password=<password>

For example:

http://localhost:2330?SWEExtSource=WebService&Username=<username>&Password=<password>

The following is an example of a request:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header/>

  <soapenv:Body>

<asi:SiebelContactQueryById>

<PrimaryRowId>1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById >

  </soapenv:Body>

</soapenv:Envelope>

Example of Passing User Credentials in the SOAP Header

The URL format is:

http://<host>:<port>?SWEExtSource=WebService&WSSOAP=1

For example:

http://localhost:2330?SWEExtSource=WebService&WSSOAP=1

The following is an example of a request:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header>

<UsernameToken xmlns="http://siebel.com/webservices">SADMIN</UsernameToken>

<PasswordText xmlns="http://siebel.com/webservices">SADMIN</PasswordText>

<SessionType xmlns="http://siebel.com/webservices">None</SessionType>

  </soapenv:Header>

  <soapenv:Body>

<asi:SiebelContactQueryById >

<PrimaryRowId>1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById >

  </soapenv:Body>

</soapenv:Envelope>

Example of Passing User Credentials in the WS-Security Header

The URL format is:

http://<host>:<port>?SWEExtSource=SecureWebService&WSSOAP=1

For example:

http://localhost:2330?SWEExtSource=SecureWebService&WSSOAP=1

The following is an example of a request:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header>

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<wsse:UsernameToken xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">

<wsse:Username>SADMIN</wsse:Username>

<wsse:Password Type="wsse:PasswordText">SADMIN</wsse:Password>

</wsse:UsernameToken>

</wsse:Security>

  </soapenv:Header>

  <soapenv:Body>

<asi:SiebelContactQueryById soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<PrimaryRowId xsi:type="xsd:string">1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById>

  </soapenv:Body>

</soapenv:Envelope>

Siebel: Server Request Processor (SRProc)

Server Request Processor (SRProc) component processes asynchronous server requests.
Asynchronous server requests are those requests from the originating component for another destination component, which the originating component doesn't wait for the request to be processed.
Once an asynchronous server request is generated, a record in inserted into S_SRM_REQUEST table.




SRProc component periodically checks the table for any eligible records to be processed based on the below 3 conditions:

• The request is in "Queued" state.
• The start time for the request has elapsed.
• The target siebel server is not specified while submitting the request or the component which can process the request is running on the specified siebel server.

If a server request satisfies all the above 3 conditions then the SRProc component forwards the request to SRBroker to run the request.

By default SRProc runs on all the siebel servers and asynchronous requests can be read by any SRProc component from any Siebel server as long as the target siebel server is not specified, in which case the SRProc on the specified siebel server has to process the asynchronous request.

Siebel: Server Request Broker (SRBroker)

The Server Request Broker (SRBroker) component routes and processes both synchronous and asynchronous server requests from the application object manager to a batch component or between 2 batch components.

• Synchronous server requests are those requests from the source component which waits till the request gets processed.
• asynchronous server requests are those requests from the source component which does not wait for the requests to get completed.

Any server requests that are originating from the Application Object manager always go to the SRBroker component which further routes the request to the appropriate server component for further processing.

SRBroker determines what to do with the request based on the below logic:

• If the destination component which can process the request from the application object manager is in the same Siebel server, then SRBroker routes the request to the component. If there are multiple instances of the same component enabled and running on the same siebel server, it routes the request on a Round robin fashion.
• If the destination component is not available on the same server where the request was originated from the application object manager, then SRBroker will route the request to SRBroker on another siebel server where the destination component is available. If the destination component is enabled and running on multiple other siebel servers, then SRBroker will route the request to SRBroker on another siebel server on a round robin fashion.
• If the destination component which is needed to process the originating request from the application object manager is not available in any of the servers, then the request will fail.

SRBroker performance tuning

MaxTasks, MaxMTServers and MinMTServers component parameters of the SRBroker component determine the performance of it.

MaxTasks by default is set to '100'

You can adjust the value of MaxTasks by using the below formula:

MaxTasks=number_of_batch_components_in_siebel_server + number_of_siebel_servers + 10 (buffer)

By default MaxMTServers and MinMTServers are set to '1'. Increasing the value will not have any performance improvement.

Siebel Connection Broker (SCBroker)

SCBroker is a background mode server componet which provides intra server load balancing by routing the incoming login requests to the MT processes of the application Object manager.
SCBroker serves the new login requests from the web server by listening to a static, configurable port 2321 which is set by the parameter "Static Port Number" (alias portnumber). once SCBroker receives request from the web server, it forwards the request to the processes in the application object manager running on the Siebel server.




SCBroker uses a connection forwarding algorithm to forward the requests to the processes depending on the value set in the hidden parameter "Connection Forward algorithm" (alias ConnForwardAlgorithm). This parameter has 2 possible values:

• LL (Least Load)
• RR (Round robin)

LL is the default value. This identifies the process which has the lowest number of tasks/threads running in the application object manager and assigns the request to the process. The RR algorithm distributes the request to the next process running in the application object manager in a round robin fashion.

LL is advisable interms of performance. Although LL is recommended it is sometimes necessary to change to RR to troubleshoot SCBroker Hangs where the least loaded Process (pid) has hanged.

In this case, SC Broker will try to repeatedly send new login requests from the web server to the least loaded MT server (pid), but the process has already hanged and we see a server busy message on the UI.

changing the parameter to "ConnForwardAlgorithm" to "RR"  has got the below advantages:

1. The hanging process(pid) will be contacted by the SCBroker only once and the next request is routes to another process. Thus the user gets error on UI only once until it comes back to the hanging thread again in round robin fashion.
2. By monitoring how the new tasks are getting created on the MT processes (pid), we can narrow down to the process (pid) that has hanged and further troubleshoot by taking userdump and pstack for the single process and then bounce it.

SCBroker forwarding mode is specific to each siebel server and thus we can have a mix of LL and RR setup in the siebel enterprise.

We need to bounce the component when we change the parameter. existing users are not affected by this bounce.

Note:  You can stop routing requests from the web server to a specific Siebel server by temporarily shutting down the SCBroker component.

Siebel: MaxTasks, MaxMTServers, MinMTServers

The values of these 3 Application Object Manager component parameters are set to guide the performance of the Application.
Setting the values of these 3 parameters determine how good the system behaves during user load.
These parameters control the capacity of each server and indirectly control the performance of the whole enterprise.


MaxTasks (Maximum Tasks): This Specifies the total number concurrent threads/tasks that can be run by the Application Object Manager (AOM). Beyond this limit, the AOM will not process any new requests or it will not create any new tasks/threads.

MaxMTServers (Maximum MT Servers): The AOM is a multithreaded process and this parameter specifies the maximum number of multithreaded processes that can concurrently run on this AOM.
After the threshold limit is reached, no more multithreaded processes are generated on the AOM.

MinMTServers (Minumum MT Servers): This parameter specifies the default number of multithreaded processes that are started on the AOM when the parent process is started.The parent AOM process can be started manually from server manager or automatically when the Siebel server starts. The AOM can be disabled by setting this parameter to '0'.
As more number of users start to login to the application, new MT processes are started to serve the additional tasks until the threshold of MaxMTServers is reached.

• Ideally both MaxMTServers and MinMTServers are set to the same value. Doing this will avoid the performance impact to the user, whose login creates a new MT Process. MaxMTServers value should be greater than or equal to MinMTServers.
• The ratio of MaxTasks/MaxMTServers defines the Maximum number of tasks each MT Process can handle.

Let us try to better understand with an example:

If MaxTasks = '300' and MaxMTServers = '3', then MaxTasks/MaxMTServers= 100. This means each MT Server can handle 100 tasks each on the AOM.
Ideally we set both MinMTServer and MaxMTServers to the same value. But let us assume the MinMTServers is set to '2'.
In this case:

• When the Application Object Manager is started, it starts 2 multithreaded processes which can serve 200 tasks/threads.
• As the number of users logging in rises but remain below 200, they are all processed by the 2 MT processes. The requests are distributed evenly between the 2 processes. This is Intra server load balancing which is done by the SC Broker.
• If the number of tasks/threads reach 200 and then a new user request is received, then Siebel starts a new MT process to serve the 201th request. Now, the AOM distributes the tasks among the 3 MT processes.
• If the AOM reaches 300 tasks/threads and a new request comes in, then the AOM cannot handle the request and is termed as "maxed out".

Formulas for calculating the parameter values

• MaxTasks = total_number_users + anon_users
• MaxMTServers = MaxTasks/100
• MinMTServers <= MaxMTServers

The value of 100 in the MaxMTServers formula is taken as a rule of thumb for the AOM.

For special OM's like the eCommunications OM and eProduct Configurator OM, the value is generally 20.

total_number_users is the total number of users the AOM will support.

anon_users is the number of anonymous browser users. HI applications does not support anon users.

for SI application, it would be around 25% of the total_number_users.