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