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

SBL-SRB-00040: Cannot open asynchronous SISNAPI connection



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



אין תגובות:

הוסף רשומת תגובה