Applies to:

Siebel System Software - Version 7.7.1 [18306] and later
Information in this document applies to any platform.
Error Message Area:Server Request Broker - SRB
Version:Siebel 7.7

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-SRB-00061: Process %1 on Siebel Server %2 terminated

Scope

This document is informational and intended for any user.

Details

Explanation

The process named in the error must have been shutdown on the server mentioned and could not route the message to the particular process.

Corrective Action

Check to make the named process is still running on the server mentioned. If not, start the component.

Applies to:

Siebel Sales Volume Planning - Version: 7.7.2.2 SIA [18356] to 7.8.2 SIA [19213] - Release: V7 to V7
Siebel Consumer Goods - Version: 7.7.2.2 SIA [18356] to 7.8.2 SIA [19213]   [Release: V7 to V7]
Siebel CRM - Version: 7.7.2.2 SIA [18356] to 7.8.2 SIA [19213]   [Release: V7 to V7]
Information in this document applies to any platform.
Product Release: V7 (Enterprise)
Version: 7.7.2.2 [18356] QF0212 - Cons Goods

This document was previously published as Siebel SR 38-2032520391.

Symptoms

This customer has added customizations on top of the out-of-the-box CG SVP Process, which include a custom business service that automates the creation of 8 concurrent workflow process tasks, executed through the Sales Volume Planning administration view:

1) The customer has a SVP master workflow process ("GIL ENA SVP Master Workflow") that calls two sub processes "GIL ENA SVP Invoke Preagregation Actions" and "GIL ENA SVP Aggregate Baseline". This executes the Pre Aggregate and the Aggregate Tasks. The Aggregation of Baseline is carried from Level 3 and above.

2) The customer has another Interface that calls the Stored Procedure to rollup the Baseline Units from Level 5 to Level 3. So the customer has all the Baseline Units at Level 3. The SVP Aggregate task rolls up these Baseline Numbers from Level 3 to above the Hierarchy.

The SVP master workflow process is scheduled to run every night in parallel with other process that execute every night. The customer has a Repeating Component Request that is running this workflow process daily.

A new Patch was applied to the Siebel 7.7.2.2 Cons Goods installation: Siebel Quick Fix version 7.7.2.2 QF0212. After this quick fix installation the customer faced a crash in the Consumer Sector BuildTree method. When running their master workflow process, it completed the Pre Aggregate Actions (1st Sub Process in the Master Workflow) but when it created the Action for Aggregation of Baseline (2nd Sub Process in the Master Workflow), the Workflow exited with error:
"SBL-SRB-00061: Process WfProcMgr on Siebel Server gbo6016d terminated".
The Task State shows that the process exited with the following error:
"Process exited because it received signal SIGABRT."

Cause

Siebel Quick Fix version 7.7.2.2 QF0212 incorporated changes from Bug 10479739: cannot copy one product into a new product by executing a SVP copy action.
The fix for this bug changed the forward fetch parameter from False to True in the Execute call to the Account business component.

The following Bug was logged for the crashes observed with this quick fix:
Bug 10498681: [CR#12-10085D4][FR#12-1042O3Y] SVP WF crash after installing QF0212
It is related the following Bug:
Bug 10484347: [CR#12-REJ4Y3][FR#12-1049CQ4] ACR218:SVP Baseline Aggregation deleting/zeroing out Baseline

Solution

Engineering investigation found that rolling back the change for the forward fetch parameter allowed the customer workflow process to complete successfully.

This has been fixed in the following Siebel versions:
Quick Fix 7.7.2.2 [18356] QF0238
Fix Pack 7.8.2.1 [19214]
Release 8.0 and above

The customer confirmed that the new SVP Patch (QF0238) fixed their issue and allowed the SVP Master Workflow to complete the Baseline and the Shipment aggregation actions.

Applies to:

Siebel CTI - Version 7.5.3.11 [16199] and later
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.11 [16199] DEU
Database: Oracle 9.2.0.6
Application Server OS: Sun Solaris 2.8
Database Server OS: Sun Solaris 2.8

This document was previously published as Siebel SR 38-2938316347.
***Reviewed for Relevance 11-Nov-2012***

Symptoms

We get Errors when we connect to Siebel-CTI with the CTI Toolbar. Sometimes it works, but sometimes (ca. 10%) not.

GenericLog    GenericError    1    2006-03-01 08:49:52    (srbroute.cpp 52(6729) err=5700061 sys=0) Prozess CommSessionMgr auf Siebel Server dab-cti01 beendet
GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp 2(2976) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel Server (null) beendet
GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp 2(2630) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel Server (null) beendet
GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp 2(2244) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel Server (null) beendet

I looked for the Task ID of the crashed Communications Session Managers (Error code SBL-GEN-00003) in order to check out the Logfiles at the CTI Server Machine, but there are no logfiles for the specified Task ID at the CTI Server! Nor for this one Crashed Task, eihter for the other crashed tasks.

Cause

Customer had set a higher value (greater than 1) to MaxMTServer and MinMTServer parameters for the Communication Session Manager component. They were encountering the behaviour where when the agent logs into the Application with Communication Toolbar enabled, it would throw error. This was intermittent. Customer was using the Aspect CTI Driver.

Solution

The Aspect driver can not handle more than one process. Expert Services suggested the customer to set MaxMTServer = 1, MinMTServer =1 and MaxTasks = 200. Once after re-setting these parameters on the Communication Session Manager component, the error was resolved.

Applies to:

Siebel Remote Server - Version 7.5.3.4 [16180] to 8.1 [21039] [Release V7 to V8]
Information in this document applies to any platform.
Product Release: V8 (Enterprise)
Version: 8.0 [20405]
Database: Oracle 10.2.0.2
Application Server OS: Red Hat Linux Advanced Server 2.1
Database Server OS: Red Hat Linux Advanced Server 2.1

This document was previously published as Siebel SR 38-3462177683.


Checked for relevance 10-02-2013

Symptoms

SBL-GEN-00255
The Generate New Database server task failed with the following error message:
[SBL-SRB-00061: Process GenNewDb on Siebel Server srvr1 terminated]

The Siebel Remote Component Group was running, and the [Generate New Database] was online.
There was only one Server [srvr1], in the Enterprise Server [ENT]. The [Siebel Remote] component group was Assigned to the Server [srvr1]. Both the [Assigned?] & [Enabled on Server?] were checked.

Looking at the log file, the following message was found:
[GenNewDb     1851 SBL-GEN-00255   Process 1851 exited with error - Internal: Error during exec()]
Complaining about the component or Object manager is not available. Both [Siebel Remote] and UCM Object Manager were running.

The original log files are attached for your reference.

Could you please give us a way forward.

Cause

Invalid ODBC configuration

Solution

For the benefit of other readers.

The customer was running the Generate New Database component and it failed. The error returned was:-

[SBL-SRB-00061: Process GenNewDb on Siebel Server srvr1 terminated]

The GenNewDB.log file showed that the process was stopping as it connected to the Local DSN. Manually connecting to the local DSN showed that this also failed.

It was then discovered that it was looking for a library that was not in the LD_LIBRARY_PATH. After modifying the LD_LIBRARY_PATH to re-include the SQLANY/lib everything worked.

Applies to:

Siebel Loyalty Engine - Version 8.1.1.1 [21211] to 8.1.1.8 SIA [23012] [Release V8]
Information in this document applies to any platform.

Symptoms

Loyalty, the Real Time Loyalty engine crashes while processing buckets with the following error:
SBL-SRB-00061: Process LoyEngineRealtime on Siebel Server clslyd1 terminated.

Steps to reproduce:
The issue can be reproduced at will with the following steps:
1. Go to Loyalty Member > Promotion Attribute View
2. Select a bucket and select Process button
3. The error SBL-SRB-00061 occurs  as the Loyalty RealTime Engine is crashing with the following call stack:

Cause

If the Bucket Promotion has no partner associated, then, the LoyEngineRealTime crashes while processing Buckets.

Based on tests in standard environment 8.1.1.1, while attempting to process Buckets using real time engine, the component LoyEngineRealtime:
1) crashes, if there is no Partner defined at the promotion level
2) executes correctly, if there is a Partner defined at promotion level.

Solution

On researching the issue, the engineering has confirmed that, for bucket processing, the user is required to associate a partner at the promotion header level. This is required for bucket processing because, unlike a transaction processing (where the partner is available on transaction) bucket will not get the partner information if the partner is not mentioned on the promotion header.

Applies to:

Siebel Assignment Manager - Version: 7.7.2 SIA [18325] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2 [18325] Com/Med
Database: Oracle 9.2.0.4
Application Server OS: Sun Solaris 9
Database Server OS: Sun Solaris 9

This document was previously published as Siebel SR 38-1622315561.

Symptoms

SBL-OSD-02011, SBL-SRB-00061 Hi,

We are currently running batch assignments on our test environment.

We are finding that batch assignment jobs without a 'object where' clause fail, but those with a where clause are successful.

This only seems to occur for the 'Order (Sales Credit Assignment)' assignment object (have tried with other objects like Contacts and the jobs run successfully).

The Batch job details are:

Assignment Object Name = Order (Sales Credit Assignment)
Replace Team Members   = FALSE

The job generates the following error in the completion information field of the jobs screen:

SBL-SRB-00061: Process AsgnBatch on Siebel Server siebsrvr1 terminated

The associated task has the following error in the status field:

Process exited because of a segment violation (SIGSEGV)

We have turned up event logging for the Batch Assignment component and have attached the task log to this service request. The log doesn't show any errors relating to assignment manager (i.e. invalid rule/object configuration).

Thanks,

Cause

For the benefits of the other user, it was found out that the default assignment object for the Order workflow policy object was copied and modified for the customer by changing the position table from S_ORD_CRDT_ASGN to S_ORDER_POSTN. However, not all the default 'Assignment User Prop' were disabled (they are not required).

Solution

After disabling one copied 'Assignment User Prop'  the crashes have not occurred anymore and allowed Order assignments to work as expected.

Applies to:

Siebel Enterprise Integration Manager - Version 8.0.0.3 [20416] and later
Information in this document applies to any platform.
***Checked for relevance on 12-Feb-2013***

Symptoms

Creating a custom Foreign Key column in the S_ORG_EXT table which has the S_ADDR_ORG table as the Foreign Key table leads to the following behaviour when running the EIM task (and after the custom FK column has been mapped to the EIM_ACCOUNT Interface table using the EIM Table Mapping Wizard which ran successfully):

The EIM task is terminated. The following error messages is seen in the Enterprise log file:

EIM 292668 SBL-OSD-01000 Process 292668 exited with error - Internal: The process attempted to read from or write to a virtual address for which it does not have the appropriate access.

Additional error message:

SBL-SRB-00061: Process EIM on Siebel Server <Siebel_server_name>terminated

Cause

Bug 10559179 has been logged to address the matter.

Solution

The current workaround is to update the custom Foreign Key column in S_ORG_EXT (pointing to S_ADDR_ORG) via Siebel Scripting.

Applies to:

Siebel Workflow - Version 7.5.2.214 SIA [16066] and later
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.2.214 [16066] Fin Svcs
Database: Oracle 8.1.7.4
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

This is only applicable to 7.5 version.
This document was previously published as Siebel SR 38-1020223111.
Checked for relevance as on 15-July-2012.

Symptoms

SBL-OSD-02006, SBL-SRB-00061
We have a workflow process that is causing the Workflow Process Manager to become "unavailable". This occurs when the Workflow Process attempts to resume from a Wait Step. The error reported in the Component Request view and the Server Tasks view is as below:

Component Request Details
--------------------------------
Component: Workflow Process Manager
Mode: Asynchronous
Status: Error
Completion Code: 5700061
Completion Information: SRB-00061: process WfProcMgr on Siebel Server test terminated

Task Details
--------------
Component: Workflow Process Manager
Task State: Exited
Status: Process exited because it received signal SIGABRT

I have followed the steps outlined in FAQ 1482 to trace the process (attached), however this does not reveal any additional useful information. All that it shows is the final step before the error.

Cause

business service are customized and is designed to perform complex computation including invocation of Incentive Compensation, ICM Calc Engine task.

Solution

Message 1

For the benefit of the other users, the customer encounter the following error on the component request status when invoking workflow process manager component :

Process exited because it received signal SIGABRT

This workflow process involves mainly business service and wait steps. These business service are customized and is designed to perform complex computation including invocation of Incentive Compensation, ICM Calc Engine task. Whereas, the wait step is incorporated to monitor the status of the ICM Calc Engine task. The above error occurs when the subsequent workflow process manager task are spawned off by the server request broker, to resume the processing.

Do note the above error is not reproducible while running on the standard application.

This error could only be reproduced with the customer database set up in-house. Change request# 10465646 was logged to address this and it is only for 7.5 version, CR status is inactive now.

Applies to:

Siebel Remote - Version 7.5.3.4 [16180] and later
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.4 [16180]
Database: Oracle 8.1.7.4
Application Server OS: IBM AIX 5L 5.1
Database Server OS: IBM AIX 5L 5.1

This document was previously published as Siebel SR 38-1923792601.


***Checked for relevance on 29-Nov-2012***

Symptoms

SBL-GDB-00004, SBL-SMI-00024, SBL-SRB-00061, SBL-GEN-09103
Hi,

I am running "GenNewDb" and immediately, I got this following error.

srvrmgr:srvr007tst> start task for component GenNewDb

start task for component GenNewDb
SBL-NET-01034: The SISNAPI connection was closed by the peer

When I checked the "GenNewDb_xxxx.log",I can see the following error message.

ContextInit   ContextInit   0   2005-04-18 23:15:50   SIEBEL_ASSERT_MODE = 0
GenericLog    GenericWarn   2   2005-04-18 23:15:50   (smisched.cpp 17(266) err=9103 sys=0) SBL-GEN-09103: Parameter value was never set (i.e. is null)
GenericLog    GenericWarn   2   2005-04-18 23:15:50   (smisched.cpp 17(269) err=9103 sys=0) SBL-GEN-09103: Parameter value was never set (i.e. is null)
GenericLog    GenericError  1   2005-04-18 23:15:50   (smisched.cpp 17(285) err=2100024 sys=0) SBL-SMI-00024: Unable to load gennewdb

Please look into this ASAP as we need to provide the extract to TAM for review.

Thanks & Regards

Cause

Missing Siebel server files:

a) \siebsrvr\lib\libgennewdb.so
b) \siebsrvr\dbtempl\sse_utf8.dbf

Solution

Message 1

1 of 2

For the benefit of other readers, the issue and resolution are as follows.

Issue Description:
----------------------
When the GenNewDB was run either from UI or from server manager, an error occurred almost immediately. In this case, customer ran from the server manager prompt as follows and encountered errors as described below.

srvrmgr:srvr007tst> start task for component GenNewDb

start task for component GenNewDb
SBL-NET-01034: The SISNAPI connection was closed by the peer

In GenNewDb_*.log, one could see the following error messages:

ContextInit   ContextInit   0   2005-04-18 23:15:50   SIEBEL_ASSERT_MODE = 0
GenericLog    GenericWarn   2   2005-04-18 23:15:50   (smisched.cpp 17(266) err=9103 sys=0) SBL-GEN-09103: Parameter value was never set (i.e. is null)
GenericLog    GenericWarn   2   2005-04-18 23:15:50   (smisched.cpp 17(269) err=9103 sys=0) SBL-GEN-09103: Parameter value was never set (i.e. is null)
GenericLog    GenericError  1   2005-04-18 23:15:50   (smisched.cpp 17(285) err=2100024 sys=0) SBL-SMI-00024: Unable to load gennewdb

Resolution:
--------------
After detailed analysis, Siebel Technical Support discovered the following.

1. That Siebel server environment was missing the following files

a) \siebsrvr\lib\libgennewdb.so
b) \siebsrvr\dbtempl\sse_utf8.dbf

Contd...

Message 2

2 of 2 - Contd from previous..

Customer had another environment similar to this one (with exact same Siebel version and QuickFixes installed), where everything was working. Since this non working environment was a Test environment and not a Production environment, Siebel Technical Support recommended copying the missing library \siebsrvr\lib\libgennewdb.so and file \siebsrvr\DBTEMPL\sse_utf8.dbf from the working environment.

After the copy was done, the Siebel Gateway and Server were restarted and GenNewDB worked successfully.

Recommendations:
-----------------------
Other recommendations made to the customer were as follows

1. Refer to "Maintenance Level Update Recommended for AIX 5L v5.1 (Document 477432.1)" (formerly Alert 899).

According to that Alert, which refers "Fileset Update Required for C++ Runtime Libraries on AIX (Document 477396.1)" (former Alert 851), customers have to ensure Siebel deployment is running the latest C++ runtime libraries (6.0.0.12) or later, if they are on AIX 5L v5.1

2. Other recommendation made was to not copy missing files, if the environment would be a Production one. If missing files would be noticed in Production, then for long term stability, customers should  consider reinstalling the affected Siebel server.









 

Applies to:

Siebel System Software - Version: 8.1 [21039] and later   [Release: V8 and later ]
Information in this document applies to any platform.
Error Message Area:Server Request Broker - SRB
Version:Siebel 8.1

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-SRB-00051: Could not find connection to the component.

Scope

This document is informational and intended for any user.

SBL-SRB-00051: Could not find connection to the component.

Explanation

There is no connection to the component. The component may be down.

Corrective Action

Check to make sure that:

1. SRBoker is still running.
2. Batch mode components are still active.
3. Try restarting the component to re-establish the connection.

Applies to:

Product Release: V7 (Enterprise)
Version: 7.8.2 [19213] Pub Sect
Database: IBM DB2 for zOS and OS/390 v8
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM zOS

This document was previously published as Siebel SR 38-3307425821.

Symptoms

SBL-SRB-00051When we are running a workflow process, we do external web service call to an external system. if this is running one occurrence it runs fine, however if we run 15 concurrently we get the following error.

SBL-SRB-00051: no connection for the component


I have attached the logs for you info.

Solution

Message 1

Customer was testing "EAI HTTP Transport" connecting to an SSL enabled webserver.
Numerous hangs were encountered when doing performance/stress testing.
This only occured when the webserver was using SSL.

Using the "pstack.sh" script(available Troubleshooting Steps 30) against the hung process
it could be seen that a thread was actually crashing, but had caused a hang.

Following stack was seen:

in pth_spinlock._global_lock_common [/usr/lib/libpthread.a] at 0xd011029c ($t94)
0xd011029c (_global_lock_common+0x35c) 80410014        lwz   r2,0x14(r1)
pth_spinlock._global_lock_common(??, ??, ??) at 0xd011029c
malloc_common.__malloc_prefork_lock_common() at 0xd02f7df0
malloc_common.__malloc_prefork_lock() at 0xd02f7208
fork.f_fork() at 0xd033ec90
mwsystem__FPCc() at 0xd934a940
system_append__FPcP4FILET1() at 0xd934b184
MwPrintProcOSInfo__Fi() at 0xd934afc4
MwPrintCurProcOsInfo__Fv() at 0xd934af0c
MwPrintProcInfo__FiPc() at 0xd934ab64
MwAbort() at 0xd928ae98
InvokeUnhandledExceptionFilter(SEH_THREAD_BLOCK*)() at


This turned out to be the behaviour described in "Alert 1198: Object Manager Hang Behaviors on UNIX Platforms Due to Calls to Malloc Memory Management Function in the Crash Handler Code "

The actual "fork" statment is generating the malloc, CR #10642640 was raised to track this.

[cont]

Message 2

This hanging behaviour means that memory corruption has taken place.
When setting the MWNO_SIGNAL_CATCHING=TRUE, the processes started to crash.
The callstacks were random , but always ended in a memory management statement such as malloc.


This was reproduced in Oracle Technical Support and Change Request 10521329
was logged to address this product defect.

Applies to:

Siebel Workflow - Version: 7.7.2.5 [18368] to 8.1.1 [21112] - Release: V7 to V8
Information in this document applies to any platform.
This document was previously published as Siebel SR 38-3070028991.

Symptoms

Customer has several custom workflow monitor agent components created. These work fine until the last few days where the agents fail with the following logs:
SrmLayerLog    Error    1    0    2006-06-19 16:51:28    (srbroute.cpp(2052) err=5700035 sys=0) no other server

SrmLayerLog    Error    1    0    2006-06-19 16:51:28    (srbmsgfn.cpp(387) err=5700047 sys=0) Could not route message to WfProcMgr with registered key (null)

GenericLog    GenericError    1    0    2006-06-19 16:51:28    (srmconn.cpp (3049) err=5700047 sys=126) SBL-SRB-00047: Could not route message to WfProcMgr with registered key (null)

GenericLog    GenericError    1    0    2006-06-19 16:51:28    (srmconn.cpp (2703) err=5700047 sys=0) SBL-SRB-00047: Could not route message to WfProcMgr with registered key (null)

GenericLog    GenericError    1    0    2006-06-19 16:51:28    (srmconn.cpp (2303) err=5700047 sys=0) SBL-SRB-00047: Could not route message to WfProcMgr with registered key (null)

Cause

The workmon is not able to communicate to wfprocmgr because this component is currently unavailable.

Solution

After Reviewing  Siebns.dat, it was observed that the wfprocmgr had a status of Offline a for the particular server. When a component is in a Offline status, it is not automatically started when the Siebel Server is bounced.

Following steps to set the component online that helped resolve the issue :

(1) Navigate to the Administration - Server Management > Enterprise. In this view, select the appropriate enterprise on the first applet (Enterprise). On the same view for the second applet (Server) select the appropriate server. On the same view again for the third applet (Component) select the appropriate component (wfprocmgr).

(2) Then click the 'Startup' button. Refresh the list applet and again for the same component you need to click 'Online' button. Each time you click the button you need to give it a minute for the compont to startup or online but keep trying this until you see the component is 'Online'.

(3) Navigate to the Administration - Server Configuration > Enterprises > Synchronization, to synchronize your batch components.

It is also suggested can create a new custom workmon, You can refer following document.

How Do You Start a Workflow Monitor Agent in Siebel Version 7.x? (Doc ID 476425.1)

This document directs that how to create a new component , but it is always recommended making a copy of the vanilla workmon component and then setting the new component names according to the above document. The workmon component parameters should be set as per following.

Group Name <name of policy group>
Default Tasks=1
Max Tasks = 1

Applies to:

Siebel System Software - Version 7.5.1 SIA [15026] to 8.1.1.8 SIA [23012] [Release V7 to V8]
Information in this document applies to any platform.
Version:Siebel 7.5/7.7.x/ 7.8.x and Siebel 8.1and later

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-SRB-00047: Could not route message to %1 with registered key %2.

Scope

This document is informational and intended for any user.

Details

Explanation

Possible causes are 1) SRB is not ready to accept messages from SRProc if this message is in the SRProc log file, or 2) The component to be notified may not be running if this exists in the SRB log file.

Corrective Action

Check to make sure that: 1) SRB is running, 2) The components that sent the request are still running to accept notifications.

Applies to:

Siebel Workflow - Version: 7.7.2.4 SIA [18365] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.4 [18365] Auto
Database: Oracle 9.2.0.7
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM AIX 5L 5.2

This document was previously published as Siebel SR 38-3011977185.

Symptoms

We are trying to Integrate QAS with Siebel, and are experienceing some difficulties.

We have a picklist that uses a virtual Business component which is populated with data from the PAF file via the QAS DLLs.

The script calls a workflow process located on the windows server, but seems to fail each time and outputs a msg to our error handling tables:

Error: SiebelError: Could not route message to NWfProcMgr with registered key (null)
no more remote SRB instance
Error near no filename:189 [InvokeMethod()].
      from no filename:189 [Query()]
      from no filename:283 [Service_PreInvokeMethod()]
     
Error: SiebelError: Could not route message to NWfProcMgr with registered key (null)
Cannot open asynchronous SISNAPI connection.
Internal: unknown hostname
Error near no filename:189 [InvokeMethod()].
      from no filename:189 [Query()]
      from no filename:283 [Service_PreInvokeMethod()]     
     
The error is reported from the attached scripts - The preinvoke method script calls the query fucntion.

Within the Query function a call is made to run a named process via the named process manager, and this is where it is falling over.
A server request for a custom wfprocmgr component on a separate (Windows) server was being made from a unix machine.

It was confirmed that the custom wfprocmgr component was online on the Windows server, the components had been synchronized, and the Siebel Servers had been re-started.

Cause

The cause of the error was found to be that the unix server did not have host name of target server in the /etc/hosts file.

Solution

After adding the required entry to this file on the unix server, the problem was resolved.

Applies to:

Siebel Territory Management - Version 8.0.0.3 SIA [20416] and later
Information in this document applies to any platform.

Symptoms

Attempted to run a simple Major Alignment after setting up Territory Management in Dev environment. I had to apply the Configuration Instructions for FR 12-1GCZKV9. I'm now seeing the following error on step 'Remove Assignment Results' possibly due to the datatype (string) of the property 'Alignment Id':

StpExec End 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Stopping step instance of 'Post TOS Process' with a 'Completed' status.
StpExec Create 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Instantiating step definition 'Remove Assignment Results'.
PrcExec PropSet 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Getting runtime value of property 'Namespace: 'USER' Name: 'Alignment Id' Datatype: 'String''.
StpExec Task 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Invoking method 'Remove Assignment Results' on business service 'Alignment Management Service'.
StpExec TaskArg 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Input: @0*0*1*0*0*0*12*Alignment Id7*1-QAV7R
SrmLayerLog Error 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srbroute.cpp(2130) err=3735555 sys=0) Cannot find the entry in routing table.
SrmLayerLog Error 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srbmsgfn.cpp(389) err=3735599 sys=0) Could not route message to RTIBatch with registered key (null)
GenericLog GenericError 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srmconn.cpp (3090) err=3735599 sys=0) SBL-SRB-00047: Could not route message to RTIBatch with registered key (null)
GenericLog GenericError 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srmconn.cpp (2744) err=3735599 sys=0) SBL-SRB-00047: Could not route message to RTIBatch with registered key (null)
GenericLog GenericError 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srmconn.cpp (2321) err=3735599 sys=0) SBL-SRB-00047: Could not route message to RTIBatch with registered key (null)
ObjMgrLog Error 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (stepexec.cpp (1540)) SBL-BPR-00162: Error invoking service 'Alignment Management Service', method 'Remove Assignment Results' at step 'Remove Assignment Results'.

Is this a known issue?

Cause

The error could not route can mean the 'RTI Batch' (RITBatch) component is not available. First you need to check if the RTIBatch is online in Administration - Server Management > Servers > Component Groups, there should be a component group named "Siebel RTI" which has only one component named 'RTI Batch".

In this case, the RTIBatch component was not enabled, the request could not be routed to it thus failed with the error.

Solution

Customer enabled the component group "Siebel RTI", Synchronize the components, and restart Siebel Server service.   This resolved the error.

The revelent documentation is in the following Bookshelf:

Siebel Territory Management Guide > Setting Up Siebel Territory Management > Process of Setting Up Siebel Territory Management

Siebel Territory Management Guide > Setting Up Siebel Territory Management > Process of Setting Up Siebel Territory Management >
Enabling Component Groups for Siebel Territory Management

Applies to:

Siebel Scheduling - Version: 8.1.1.5 [21229] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

====Issue Clarification====
When attempting to book Appointment ,
the following error occurs.

ERROR
-----------------------
Siebel
---------------------------
SrmLayerLog Error 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (smiworkq.cpp(1577) err=1376472 sys=0) Internal: Not an error, all the threads are busy

SrmLayerLog Error 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srbroute.cpp(2148) err=3735587 sys=0) No server available to service this request.

SrmLayerLog Error 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srbmsgfn.cpp(389) err=3735599 sys=0) Could not route message to ApptBook with registered key 1-NZU2ZD.

GenericLog GenericError 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srmconn.cpp (3090) err=3735599 sys=0) SBL-SRB-00047: Could not route message to ApptBook with registered key 1-NZU2ZD.

GenericLog GenericError 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srmconn.cpp (2744) err=3735599 sys=0) SBL-SRB-00047: Could not route message to ApptBook with registered key 1-NZU2ZD.

GenericLog GenericError 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srmconn.cpp (2321) err=3735599 sys=0) SBL-SRB-00047: Could not route message to ApptBook with registered key 1-NZU2ZD.

ObjMgrBusServiceLog InvokeMethod 4 0002078c4ecb02d3:0 2011-11-24 14:25:42 Business Service 'Server Requests' invoke method 'SubmitRequest' Execute Time: 0.058 seconds.

ObjMgrBusServiceLog InvokeMethod 4 0002078c4ecb02d3:0 2011-11-24 14:25:42 End: Business Service 'Server Requests' invoke method: 'SubmitRequest' at 174303b8

ObjMgrBusCompLog Error 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (basesch.cpp (475)) SBL-DAT-00472: Generic SSA NOTOK error message.


STEPS
-----------------------
Check of the ApptBook job. If it’s queued status – restart the Siebel Server

- Create an activity with the same plan start/ end, earliest start and end dt. goto Schedule view. Unlock the assignment and associated to the service region define above.

- Click the Book Appt button.

- system popup message : Generic SSA NOTOK error message

- goto administration - User. Select an employee and associate the schedule and service region to him

- Goto Administration - Scheduling. Click Load ABS.

- Go back to the Activity. Click the Book Appt.

The same problem persists.

Cause

The upgrade process caused the truncation of the S_SRM_ACTION table. This results in the system unable to route the request to the ApptBook component.

Due to the missing data in S_SRM_ACTION table, the Server Key Mapping on the UI is incomplete.

Solution

Complete the data entry in the Server Key Mapping view. Customer resolved the error after performing this.

Note : to help diagnose the problem, customer were asked to run the following syntax at Siebel Server commandline :

run task for comp ApptBook with method='ReloadServiceRegion',SvcRegnId='1-REU0NA'
run task for comp ApptBook with method='Getappointment',SvcRegnId='1-REU0NA',ActId='1-242U83N'

Trace the apptbook log to verify if the above runs without error. If no error exists, do review the setup like Server Key Mapping, the availability of SRBroker.

Applies to:

Siebel System Software - Version 7.7.2.6 SIA [18372] to 8.1.1.8 [23012] [Release V7 to V8]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.6 [18372] Life Sci
Database: Oracle 9.2.0.4
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

This document was previously published as Siebel SR 38-3307344231.

""""Checked for relevance on 28-Apr-2010""""
"Checked for relevance on 11-Oct-2012"

Symptoms

SBL-UIF-00230, SBL-SRB-00047, SBL-NET-01020
We are not able to generate correspondence from our document server (which runs on a Win2000 SP 4) box. The actual siebel server and gateway runs on a solaris box. We are not seeing siebel.html being generated in the \reports folder of the doc server. I have added all the files from the log folder of this .doc server including a .saf which the log says does not exist in the file system. Please assign some body as soon as possible as we are not seeing this issue in any other environments, but the testers are waiting to test this particular functionality.

Thanks

Cause

Solution

Message 1

For the benefit of other readers:

Correspondence requests for the Document Server were failing as it was not able to reach templates stored in the File System. Further review of Siebel log files uncovered the following errors:

** From DocServer log files:

SBL-SRB-00047: Could not route message to FSMSrvr with registered key (null)
SBL-UIF-00230: The file 'Shipment Confirmation.doc' could not be found on any specified file system.

** From SRBroker log file:

SBL-NET-01020: Internal: unknown hostname

The customer implemented Siebel File System on a Unix box where another Siebel server was installed. When the template file is requested by Document Server, this requisition goes through SRBroker component to be routed to a File System Manager instance. Since the local File System Manager is disabled – and this is the correct configuration for heterogeneous environments –, SRBroker will try to route it to the active File System Manager running on Unix server. As the Unix hostname cannot be resolved on the Document Server machine, the request fails and the merge process is aborted.

The issue was resolved after fixing the DNS settings on the Document Server machine to correctly resolve the Unix hostname.

Applies to:

Siebel System Software - Version 7.5.2.100 SIA [15252] to 8.1.1.4 SIA [21225] [Release V7 to V8]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.2.100 [15252] Life Sci
Database: Oracle 8.1.7
Application Server OS: Microsoft Windows 2000 Advanced Server SP 2
Database Server OS: Microsoft Windows 2000 Advanced Server SP 2

This document was previously published as Siebel SR 38-1020255192.

CHECKED FOR RELEVANCE ON 1-FEB-2013

Symptoms

SBL-SMI-00033, SBL-SRB-00041, SBL-NET-01034

Typical error is as follows:

2021 2003-06-04 00:30:05 2003-06-04 00:30:05 +0100 00000042 001 ffff 0001 09 SRBroker 36931 548 592 E:\sea752\siebsrvr\log\SRBroker_36931.log 7.5.2.102 [15255] ENUENU
GenericLog    GenericError    1    2003-06-04 00:30:05    (smimtses.cpp 18(352) err=2100033 sys=0) SMI-00033: The client exited without closing the SISNAPI connection
TaskCfgExit    TaskParamsAtExit    1    2003-06-04 00:30:05    ***********Dumping Parameters for the current task because of errors**********

In addition to this SRBroker error:

2021 2003-05-29 14:46:49 2003-05-29 14:46:49 +0100 00000046 001 ffff 0001 09 SRBroker 20550 2484 2508 E:\sea752\siebsrvr\log\SRBroker_20550.log 7.5.2.102 [15255] ENUENU
GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp 44(2445) err=1801033 sys=0) NET-01033: The SISNAPI handshake timed out, the Siebel Service may not be running
GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp 44(2445) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp 44(2766) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp 44(1444) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog    GenericError    1    2003-05-29 14:46:49    (smimtsh.cpp 25(307) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
TaskCfgExit    TaskParamsAtExit    1    2003-05-29 14:46:49    ***********Dumping Parameters for the current task because of errors**********

Cause

Not an issue.

Solution

For the benefit of reader,

Customer has seen the following intermittent error messages in their SRBroker log files:

GenericLog    GenericError    1    2003-06-04 00:30:05    (smimtses.cpp 18(352) err=2100033 sys=0) SMI-00033: The client exited without closing the SISNAPI connection
GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp 44(2445) err=1801033 sys=0) NET-01033: The SISNAPI handshake timed out, the Siebel Service may not be running
GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp 44(2445) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp 44(2766) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog    GenericError    1    2003-05-29 14:46:49    (srbthrd.cpp 44(1444) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake
GenericLog    GenericError    1    2003-05-29 14:46:49    (smimtsh.cpp 25(307) err=5700041 sys=0) SRB-00041: can't do SISNAPI handshake

After increasing the logging event for SRBroker, we have figured out that these errors resulted from server shuting down, and can be ignored. In customer's environment, they have three siebel servers.

Because SRB communicates to all other SRBs on other servers, and communicates to SRP on the same server, when one of the SRB exits, the up SRB will normally log the corresponding SISNAPI errors. In the same way, If on the same server, when SRP exits before SRB , such as server shuting down, SRB also logs the corresponding SISNAPI error.

Search Keyword: SRBroker, SISNAPI.

Applies to:

Siebel Financial Services CRM - Version 7.8.2.6 SIA [19230] and later
HP-UX PA-RISC (32-bit)
HP-UX PA-RISC (64-bit)
HP-UX Itanium
HP-UX Itanium (32-bit)
One or more Siebel components become unavailable, even if their logs show they are running

SRBRoker log shows errors like
SBL-SRB-00041: Could not send a SISNAPI hello message

Symptoms

In this particular case, the FSMSrvr component registered with port 49179 when the Siebel Server started up
netstat -an | grep 49179
showed

tcp        0      0  127.0.0.1.49179        *.*                     LISTEN tcp        0      0  *.49179                *.*                     LISTEN tcp        0      0  127.0.0.1.49179        127.0.0.1.924           ESTABLISHED tcp        0      0  127.0.0.1.924          127.0.0.1.49179         ESTABLISHED

The Siebel component binds with * (bold),
the binds to localhost (127.0.0.1) are from other software using the same port - in this case, HP Open View.
SRBroker requests don't reach the Siebel component, in this case FSMSrvr.

Note that this is not limited to any specific component name - it can affect any Siebel Component whose port number from the enterprise log is used by a different process; another customer for example reported the same problem for WfProcBatchMgr that suddenly stopped processing (repeating component) requests.

Cause

HP Open View and also HP WBEM services are using ports already in use by the Siebel Server, leading to a port conflict.
With the Itanium release of HP-UX there was a management utility introduced called
HP-UX Web-Based Enterprise Management (WBEM) Services. This tool is allocating ports in the same range as the siebel processes, starting at port 49152. However they bind these daemon processes
named "cimprovagt" only to the loopback adapter which is causing the collision.
Siebel Applications use
SO_REUSEADDR
when opening ports - this is done on purpose to avoid long delays waiting for a timeout when stopping and starting the Siebel Server
This allows HP Open View binding with localhost (even though the Siebel Port is already opened and used by the Siebel Application)
and the use of the same port (for different purposes) by two different applications causes the Siebel component no longer to get its requests.

Solution

As a quick workaround (that needs to be repeated after every re-boot)

1. Run netstat -an and identify which root processes are blocking the siebel component ports as described in the "Symptoms" section.

2. Also execute lsof -i tcp |grep <port number> to identify more root processes blocking siebel component ports as above.

3. Kill the root processes identified this way.
For a permanent solution,

please invoke HP-UX / Open View support,
asking them how Open View or WBEM can be configured to use a port range that does not conflict with the Siebel Server (which starts using ports from 49152),
e.g. 49300 and above.
http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1216221381645+28353475&threadId=646982
has more information, put assistance how to configure this would need to come from HP-UX support
HP-UX uses the "ndd" utility program to change tunable IP stack parameters.  The ephemeral ports on HP-UX can be tuned individually for both TCP and UDP, so there are really two separate ephemeral port ranges.  HP-UX also provides options to change the privileged port range (ports only processes running with superuser privileges can use).
The good news is that HP-UX uses our recommended port range (49152 through 65535) so it is unlikely you will need to change the range from the default values.
The example below shows how to query the existing values for the TCP ephemeral ports, and change the range to 50001 through 61000:
# /usr/bin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port
49152
65535
# /usr/bin/ndd -set /dev/tcp tcp_smallest_anon_port 50001
# /usr/bin/ndd -set /dev/tcp tcp_largest_anon_port 61000
# /usr/bin/ndd /dev/tcp tcp_smallest_anon_port tcp_largest_anon_port
50001
61000
Note that if you change the range values, you must do it each time the system boots."

If this cannot be done on the Open View Side,
you may choose to set static ports for every single Siebel Component to avoid port conflicts here.

Keywords (desperate attempt to show this document before the many MR release notes in the knowledge search):

HP-UX port blocked HP-UX PORT USED
hp-ux blocked port
hp-ux blocked port
'hp-ux blocked port'
"hp-ux blocked port"
hp-ux blocked port Siebel
hp-ux blocked port
hp-ux blocked port
'hp-ux blocked port'
"hp-ux blocked port"
hp-ux blocked port Siebel

Applies to:

Siebel System Software - Version 7.8.2 [19213] to 8.2.2.2 SIA[23016] [Release V7 to V8]
Information in this document applies to any platform.
Error Message Area:Server Request Broker - SRB
Version:Siebel 7.8
***Checked for relevance on 27-Feb-2013***

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-SRB-00041: Could not send a SISNAPI hello message after connecting to the component.

Scope

This document is informational and intended for any user.

Details

Explanation

Could not send hello message to a remote SRB or local batch mode components or local SRProc.
The components may not have been running after the connection was instantiated.

Corrective Action

Check to make sure that:
1) Remote SRB is still running,
2) Batch mode components are still active,
3) Local SRProc is still running.

Applies to:

Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
Information in this document applies to any platform.
Error Message Area:Server Request Broker - SRB
Version:Siebel 7.5.3

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-SRB-00041: can't do SISNAPI handshake

Scope

This document is informational and intended for any user.

SBL-SRB-00041: can't do SISNAPI handshake

Explanation

Could not send hello message to a remote SRB or local batch mode components or local SRProc.
The components may not have been running after the connection was instantiated.

Corrective Action

Check to make sure that:
1) Remote SRB is still running,
2) Batch mode components are still active,
3) Local SRProc is still running.

Applies to:

Siebel Workflow - Version: 7.7.2.4 SIA [18365] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.4 [18365] Auto
Database: Oracle 9.2.0.7
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM AIX 5L 5.2

This document was previously published as Siebel SR 38-3011977185.

Symptoms

We are trying to Integrate QAS with Siebel, and are experienceing some difficulties.

We have a picklist that uses a virtual Business component which is populated with data from the PAF file via the QAS DLLs.

The script calls a workflow process located on the windows server, but seems to fail each time and outputs a msg to our error handling tables:

Error: SiebelError: Could not route message to NWfProcMgr with registered key (null)
no more remote SRB instance
Error near no filename:189 [InvokeMethod()].
      from no filename:189 [Query()]
      from no filename:283 [Service_PreInvokeMethod()]
     
Error: SiebelError: Could not route message to NWfProcMgr with registered key (null)
Cannot open asynchronous SISNAPI connection.
Internal: unknown hostname
Error near no filename:189 [InvokeMethod()].
      from no filename:189 [Query()]
      from no filename:283 [Service_PreInvokeMethod()]     
     
The error is reported from the attached scripts - The preinvoke method script calls the query fucntion.

Within the Query function a call is made to run a named process via the named process manager, and this is where it is falling over.
A server request for a custom wfprocmgr component on a separate (Windows) server was being made from a unix machine.

It was confirmed that the custom wfprocmgr component was online on the Windows server, the components had been synchronized, and the Siebel Servers had been re-started.

Cause

The cause of the error was found to be that the unix server did not have host name of target server in the /etc/hosts file.

Solution

After adding the required entry to this file on the unix server, the problem was resolved.

Applies to:

Siebel System Software - Version: 7.7.1 [18306] and later   [Release: V7 and later ]
Information in this document applies to any platform.
Error Message Area:Server Request Broker - SRB
Version:Siebel 7.7

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-SRB-00040: Cannot open asynchronous SISNAPI connection.

Scope

This document is informational and intended for any user.

SBL-SRB-00040: Cannot open asynchronous SISNAPI connection.

Explanation

Could not open SISNAPI connection to a remote SRB or local batch mode component or local SRP to send a message.
The components may not have been running when the connection was instantiated.

Corrective Action

Check to make sure that:
1) Remote SRB is still running.
2) Batch mode components are still active.
3) Local SRP is still running.

Applies to:

Siebel System Software - Version 7.5.2.7 SIA [15058] and later
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.2.7 [15058] Com/Med
Database: Oracle 8.1.7
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

Symptoms

SBL-SRB-00040, SBL-NET-01020
While installing production environment, with many Siebel Servers on solaris machine(s)
Some errors appear in the Gateway and SRBroker logs. See attached.
Symptoms:
- When connecting via Dedicated Web Client it is not possible to view the Servers in the Server Admin screens- error message is "No connections found to any active servers".
- When connecting via command line srvrmgr from one of the Siebel Server boxes it shows all Servers up, running and all Components healthy.
- When connecting via Web Client (this is possible via the PRMManager OM) it shows only two Siebel Servers: the SRVREAI1. The other ones are listed but all fields (Status, etc.) read blank.
- When doing all the steps above against Dportal (another environment) everything looks fine.

Cause

Configuration/ Setup

Solution

Message 1

The Server Request Broker (SRBroker) log showed the error message:

GenericLog      GenericError    1       2003-05-23 14:35:28     (srbthrd.cpp 44(2431) err=1801020 sys=0) NET-01020: Internal: unknown hostname
GenericLog      GenericError    1       2003-05-23 14:35:28     (srbthrd.cpp 44(2431) err=5700040 sys=1) SRB-00040: can't open asynchronous SISNAPI connection

Resolution:
The /etc/hosts file of siebel Server(s) did not report the host name(s) related to ip addresses.
Adding the host names to the /etc/hosts resolved the reported behavior.


Keywords: name resolution, SRBroker, log file, hostname, host, unix, solaris

Applies to:

Siebel System Software - Version 7.5.3.4 [16180] to 7.5.3.17 [16285] [Release V7]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.4 [16180]
Database: Oracle 9i
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

This document was previously published as Siebel SR 38-1215157231.

Symptoms

Customer installing a testing environment composed on 5 servers solaris (SUN FIRE V240 with Solaris 5.8):

1: web server
2: gateway server
3: application server
4: database server

Two application servers are balanced by Resonate. Customer installed the resonate agents on two servers. Customer has following problems:
1. Able to connect using a thin client to application and application reporting a timeout error on logs (appear the usual page 'Server Busy....')
2. If eapps_sia.cfg file gets changed for not to use the VIP Resonate (Customer uses the gateway hostname and the siebel server name) the thin client connection works
3. using the dedicated client customer can see all component up.

The problem seem to be related to Resonate-Web-Application chain.

Cause

Configuration/ Setup

Solution

The on-board NIC for Broadcom is supported (below), however Resonate 3.x does not support IPMP (Internet Protocol Network Multipathing).

This is defined on the Sun Microsystems Website.

http://www.sun.com/solutions/blueprints/1102/806-7230.pdf

Central Dispatch version: 3.2.2e
OS and SP level: SunOS 5.8 Generic_108528-27
NIC manufacturer: Sun Microsystems
NIC model bge (BCM570x)
NIC driver version bge (BCM570x driver v0.22)
Teaming capabilities ? Not in use
Machine make/model: Sun-Fire-V240 (in produzione Sun-Fire-V480)

The Siebel log files showed errors the following when IPMP was enabled.

SBL-GEN-09103: Parameter value was never set (i.e. is null)
SBL-OSD-00204:    Internal waitpid() failed with error 0
SBL-GEN-00000: (listener.cpp 21: 0) error code = 0, system error = 2123331884, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)
SBL-SRB-00053: time out in connecting to SRProc, will try to connect again after SRProc starts completely
SBL-SRB-00040: can't open asynchronous SISNAPI connection
SBL-GEN-03006: Error calling function: DICFindTable m_pReqTbl
SBL-OSD-00001: Internal: Function call timed out (0)
SBL-NET-01023: Peer disconnected
SBL-SSM-00003: Error opening SISNAPI connection
SBL-NET-01201: Internal: connect() failed: Connection timed out
The system works (disabling both IPMP and the other NIC which was also onboard) otherwise a kernel panic is experienced.

panic string: BAD TRAP: type=31 rp=2a1000bd6b0 addr=28 mmu_fsr=0 occurred in
module "rxp" due to a NULL pointer dereference ==== panic kernel thread:
0x2a1000bdd20 pid: 0 on cpu: 28 ==== cmd: sched

Applies to:

Siebel CTI - Version 7.5.2.214 SIA [16066] and later
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.2.214 [16066] Pub Sect
Database: Oracle 9.2.0.2
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

This document was previously published as Siebel SR 38-1402862871.
**Reviewed for Relevance on 07-Oct-2012***

Symptoms

SBL-SRB-00040, SBL-SRB-00005, SBL-NET-01218
We have set up Siebel/Avaya integration (Avaya Version 6.1.3). Trying to logon with an agent CTI toolbar doesn't become active.

We gave a look into log file and we found out the following message:
"Connection refused by server 127.0.0.1, nothing listening on port 49180"

For further information you can see the logs attached (in italian).

Please help us.

Cause

The customer had installed Avaya software using root solaris user. The Avaya folders had a different owner than that of the Siebel folders.

Solution

After changing the ownership of Avaya folders to the owner of Siebel folders, the problem was resolved.

As a future reference, Avaya Support was requested to add this information to the installation pre-requisites of the CTI Driver manuals.

Applies to:

Siebel CRM - Version: 8.1.1 SIA [21111] and later   [Release: V8 and later ]
Information in this document applies to any platform.
***Checked for relevance on 17-Feb-2012***

Symptoms

The Gateway daemon for Siebel Industry Applications version 8.1.1 running on IBM AIX 5.3 against Oracle 11g shows high CPU. This can be observed after starting a Siebel server, which has a duration of 2-3 minutes. After the Siebel server has started the CPU of the Gateway daemon reduces and stabilizes, however the Siebel Workflow components fail after startup. If these failed components are restarted manually via Siebel Server Manager then the CPU increases on the Gateway as before.

ERROR MESSAGES

1. SBL-DAT-00173: An invalid key was entered.
2. SBL-NET-01218: The connection was refused by server %1. No component is listening on port %2.
3. SBL-SRB-00040: Cannot open asynchronous SISNAPI connection.
4. SBL-GEN-05009: Unable to connect to the gateway server.
5. SBL-SVR-00052: Internal: Invalid proc handle

Cause

Issue caused by extremely large SIEBNS.DAT which can be seen by the high CPU in the gateway process originating from the reads performed by the NSClient.

Bug 10643323 has been logged to address a Product Enhancement Request so that the size of the SIEBNS.DAT does not grow excessively and if it does then to provide means to reduce the size - in particular removing event log level entries.

The large amounts of reads being performed by the NSClient are directly related to the high CPU observed on the gateway

Solution

To reduce the size of the SIEBNS.DAT, the following can be employed to resolve the issue:
1. Restore backup of SIEBNS.DAT after changing event log levels for large amount of server components
2. Remove unnessary component definitions

Applies to:

Siebel Workflow - Version: 7.7.2.4 SIA [18365] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.4 [18365] Auto
Database: Oracle 9.2.0.7
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM AIX 5L 5.2

This document was previously published as Siebel SR 38-3011977185.

Symptoms

We are trying to Integrate QAS with Siebel, and are experienceing some difficulties.

We have a picklist that uses a virtual Business component which is populated with data from the PAF file via the QAS DLLs.

The script calls a workflow process located on the windows server, but seems to fail each time and outputs a msg to our error handling tables:

Error: SiebelError: Could not route message to NWfProcMgr with registered key (null)
no more remote SRB instance
Error near no filename:189 [InvokeMethod()].
      from no filename:189 [Query()]
      from no filename:283 [Service_PreInvokeMethod()]
     
Error: SiebelError: Could not route message to NWfProcMgr with registered key (null)
Cannot open asynchronous SISNAPI connection.
Internal: unknown hostname
Error near no filename:189 [InvokeMethod()].
      from no filename:189 [Query()]
      from no filename:283 [Service_PreInvokeMethod()]     
     
The error is reported from the attached scripts - The preinvoke method script calls the query fucntion.

Within the Query function a call is made to run a named process via the named process manager, and this is where it is falling over.
A server request for a custom wfprocmgr component on a separate (Windows) server was being made from a unix machine.

It was confirmed that the custom wfprocmgr component was online on the Windows server, the components had been synchronized, and the Siebel Servers had been re-started.

Cause

The cause of the error was found to be that the unix server did not have host name of target server in the /etc/hosts file.

Solution

After adding the required entry to this file on the unix server, the problem was resolved.

Applies to:

Siebel Workflow - Version: 7.5.2.100 [15252] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.2.100 [15252]
Database: Oracle 8.1.7.4
Application Server OS: Microsoft Windows 2000 Server SP 2
Database Server OS: Microsoft Windows 2000 Server SP 2

””Checked for Relevance on 11-01-2012””

This document was previously published as Siebel SR 38-1176637726.

Symptoms

SBL-OMS-00203, SBL-SRB-00047, SBL-SRB-00032We created a workflow process that invokes Assignment Manager using the Synchronous Assignment Manager Requests business service.

We had to restart the Siebel Services this morning and, after we did, the FJS Assignment
Monitor failed when trying to run the assignment for a contact.   I've attached the log file for the failing Workflow task.    It seems to be following the correct, new Workflow Process but failing when trying to call the Assignment task.  

The Assignment Manager task is still running.

I'd be grateful if you take a quick look at the log file and advise.

Cause

Expected behavior

Solution

Message 1

For the benefit of other users, the customer had a Workflow Monitor Agent (WMA) that invoked a workflow process which, in turn, invoked Assignment Manager (AM). The WMA was configured so that a task was started automatically when the component was started. When the siebel server was stopped and started a Workflow Process Manager (WPM) task failed with the following error:

Object manager error: ([0] AsgnSrvr with key [(null)] is not available (0x7031)) Object manager error: ([1] no more remote SRB instance (0x7031)) Object manager error: ([2] Error invoking service 'Synchronous Assignment Manager Requests', method 'Assign' at step 'Business Service'. (0x813f))
When the WMA was started again the same request was correctly processed. This strongly suggested that the reported behavior occurred because the WPM had submitted the request before AM had come up after the Siebel Server was restarted.

Change request 12-JMAGIJ has been raised to look into the reported behavior and consider implementing some sort of solution. For example, users could be given the ability to specify dependencies between components and as a result the application could start up components that are invoked by other components first. Please note that all requests are reviewed and prioritized for possible inclusion in a future release.

Continued in next entry.

Message 2

Continued from previous entry.

Using the Number of Restarts and Minimum Up Time parameters for the WMA the customer addressed the behavior by configuring the application so that if the WMA task fails another task will be automatically started until AM starts up and can process the request from the WPM.

For more information on these parameters please refer to Technical Note 259: [Component Automatic Restart & Component Database Error Recoverability] on SupportWeb. For more information on this possible solution please refer to Service Request #: 38-895759251 [Workflow/Assignment Manager Failures - Production Issue].

Applies to:

Siebel CTI - Version: 7.5.3.8 [16192] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3.8 [16192]
Database: Oracle 9.2.0.4
Application Server OS: Microsoft Windows 2000 Advanced Server SP 3
Database Server OS: Sun Solaris 8

This document was previously published as Siebel SR 38-2239792261.

Symptoms

During a recent deployment of Siebel 7.5.3.8/Genesys Voice Adapter 6.5.201.13, we encountered a "Call Stack" on the dedicated Siebel Communications Server. These Call Stacks were associated with 1) Problems with CTI Toolbar 2) Agents being logged out of tool bar 3) Agent calls being dropped. Some of the text below is:

- CALL STACK -
<invalid> 0x5dda484
GenModel +0x5b594
GenModel +0x10f20 = ReleaseTeleset() +0x1e70
<invalid> 0x868b57f1

This Call Stack occured 5 times during our initial deployment and subsequently was associated with these errors in the Siebel Communications Manager Logs:

1) GenericLog    GenericError    1    2005-05-31 10:53:58    (sissrvr.cpp 47(3069) err=2000028 sys=0) SBL-SVR-00028: No more tasks available for this component

2) CommSessionMgr 59455     SBL-OSD-01000   Process exited with error - Internal: The process attempted to read from or write to a virtual address for which it does not have the appropriate access

3) GenericLog    GenericError    1    2005-05-31 11:08:51    (srbqueue.cpp 6(918) err=5700005 sys=0) SBL-SRB-00005: no element in the queue

4) SComm[05/31/2005 10:24:23:555]:FATAL:SRM session handle is NULL in DoInvokeMethod() for user(BENNETS6), key(1328|429c71f8|248466b0).
SComm[05/31/2005 10:24:23:555]:ERROR:Unable to identify driver for action, profile ID=, channel string=, media type=, command=Ready, event=
SComm[05/31/2005 10:24:23:555]:ERROR:Error on invoke media manager method(InvokeCommand), input args={
DataSet = 2#18#1#13#AgentWorkMode5#1#1#1
DeviceCommand = Ready
Child property set, type = DataSet {
AgentWorkMode = 1
}
}, error=?), msg='Unable to identify driver command(Ready) among all loaded drivers.(SBL-CSR-00504)'

Our frustration is occurring because we are not able to re-create this error in our load testing environment. Since this error was associated with CTI Toolbar connectivity issues (i.e.: agents being logged out of the toolbar) and other CTI issues, we remain concerned.

Cause

After researching and checking the call Stack:
- CALL STACK -
<invalid> 0x5dda484
GenModel +0x5b594
GenModel +0x10f20 = ReleaseTeleset() +0x1e70

We could identify that the crash was happening while CSM was calling method on Genesys Gplus Driver libraries.

The customer engaged Genesys Support who has confirmed that this is a known issue.

Solution

Genesys confirmed that the issue  has been fixed in Genesys  Gplus Driver 7.x code stream and the fix was replicated into 6.5 stream.

The recommendation is to deploy the latest version (6.5.201.20). Note that the customer was using 6.5.201.13 version of the driver.

Customer worked with Genesys to get the latest Gplus Driver hot fixes.

Applies to:

Siebel CTI - Version 7.5.2.214 SIA [16066] and later
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.2.214 [16066] Pub Sect
Database: Oracle 9.2.0.2
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

This document was previously published as Siebel SR 38-1402862871.
**Reviewed for Relevance on 07-Oct-2012***

Symptoms

SBL-SRB-00040, SBL-SRB-00005, SBL-NET-01218
We have set up Siebel/Avaya integration (Avaya Version 6.1.3). Trying to logon with an agent CTI toolbar doesn't become active.

We gave a look into log file and we found out the following message:
"Connection refused by server 127.0.0.1, nothing listening on port 49180"

For further information you can see the logs attached (in italian).

Please help us.

Cause

The customer had installed Avaya software using root solaris user. The Avaya folders had a different owner than that of the Siebel folders.

Solution

After changing the ownership of Avaya folders to the owner of Siebel folders, the problem was resolved.

As a future reference, Avaya Support was requested to add this information to the installation pre-requisites of the CTI Driver manuals.