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.