siebel: SBL-SRB-*****

‏הצגת רשומות עם תוויות SBL-SRB-*****. הצג את כל הרשומות

יום רביעי, 3 באפריל 2013

SBL-SRB-00061: Process %1 on Siebel Server %2

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:

/applic/siebel/siebsrvr/lib/libsslcshar.so(SSstring::operator=(SSstring const&)+0x22)[0x556e2d62]

/applic/siebel/siebsrvr/lib/libsssalysv.so(CSSLOYEvaluateAssignPoints::Evaluate(CSSLOYObjectProcessor*,
CSSLOYAction*, CSSLOYPromoResult*)+0x225f)[0x6a46d9cf]

/applic/siebel/siebsrvr/lib/libsssalysv.so(CSSLOYObjectProcessor::GeneratePromoResults()+0x38b)[0x6a45b91b]

/applic/siebel/siebsrvr/lib/libsssalysv.so(CSSLOYObjectProcessor::DoProcessObject(CSSLOYCacheMgr*,
CSSLOYWorkObject*)+0x20c)[0x6a45a5cc]

/applic/siebel/siebsrvr/lib/libsssalysv.so(CSSLOYObjectProcessor::ProcessObject(CSSLOYCacheMgr*,
CSSLOYWorkObject*)+0x30)[0x6a4598a0]

/applic/siebel/siebsrvr/lib/libsssalysv.so(CSSLOYProcService::DoProcessObject(CSSLOYWorkObject*)+0x821)[0x6a43be81]

/applic/siebel/siebsrvr/lib/libsssalysv.so(CSSLOYProcService::ProcessObject(CCFPropertySet
const&, CCFPropertySet&)+0x593)[0x6a438fb3]

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.

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

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:

SRBoker is still running.

Batch mode components are still active.

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.

SBL-SRB-00047: Could not route message

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.

SBL-SRB-00041: Could not send a SISNAPI hello message after connecting to the component

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.

SBL-SRB-00040: Cannot open asynchronous SISNAPI connection

Applies to:

Symptoms

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

SBL-DAT-00173: An invalid key was entered.

SBL-NET-01218: The connection was refused by server %1. No component is listening on port %2.

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

SBL-GEN-05009: Unable to connect to the gateway server.

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

SBL-SRB-00032

Applies to:

Symptoms

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].

SBL-SRB-00005

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:

Symptoms

Cause

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