Siebel Administration >  SBL-NET-01034: The SISNAPI connection was closed by the peer

SBL-NET-01034: The SISNAPI connection was closed by the peer
SBL-SVR-01015: Internal: Could not send a SISNAPI message: (null)

The above error message is reported when an established connection/session between 2 entities (user-component, component-component) is terminated, or if a server component is shutdown. The SVR error is usually reported alongside it.

Cause

The connection could have been lost due to several reasons such as:

Closed due to inactivity (similar to idle connection time out)

On account of network connectivity issues (in which case it would be an abrupt drop of the connection)

(Or) simply because the component being contacted is/was shut down and hence is not responding back.

Diagnostic Steps

Identify the component that is reporting this error, and if applicable, also identify the component it was attempting to contact.

Identify if the close of connection is due to inactivity (Try to identify when the last communication was established and if users can identify a pattern in these disconnects)

Identify if the component being contacted is up and running and has not been shut down/terminated.

Solution

There are several places where time outs of connections can be specified, check if any of the ones that are listed below is responsible for this loss of connection.

Within the Siebel application

At the Siebel enterprise server level, Siebel server level, and server component level, look to see if users have recently altered any of the following parameters pertaining to time outs at any of these levels.
ConnIdleTime = [SISNAPI connection maximum idle time, default=-1, which disables this feature]
SCBTimeout = [Timeout for the Resonate CDAction command to execute (in seconds), default=600(10 mins.), applicable if users are using Resonate Central Dispatch Load Balancing]
The easiest way to identify if such a change was indeed made is by enlisting the parameters at each level and checking to see if it is set to anything other than the above defaults. Invoke asrvrmgrsession (do not specify the/sor-sswitch to connect to a specific Siebel server - this way users are connected to the enterprise as a whole - for example:

To list enterprise parameters -list enterprise parameter
To list server parameters -list parameter for server <Siebel_server_name>
To list component parameters -list parameter for component <component_name> for server <Siebel_server_name>
At the Siebel Web Server extension level (SWSE) (in the eapps.cfg file) look to see if users have recently altered any of the parameters pertaining to time outs.

Outside of the Siebel application

Database level for example, dead connection detection within Oracle. Check with the Database Administrator to assist with this step.

Network level to handle network inactivity. Check with the Network Administrator to assist with this step.