Siebel Internet Session Network Application Programming Interface (SISNAPI) is a proprietary (originally Siebel Systems

Siebel Systems

Siebel CRM Systems, Inc. was a software company principally engaged in the design, development, marketing, and support of customer relationship management applications. The company was founded by Thomas Siebel in 1993. At first known mainly for its sales force automation products, the company...

, now Oracle

Oracle Corporation

Oracle Corporation is an American multinational computer technology corporation that specializes in developing and marketing hardware systems and enterprise software products – particularly database management systems...

) message format protocol used for communications between various Siebel application components. SISNAPI runs over HTTP and can be configured to use encryption and authentication based on Secure Sockets Layer (SSL).

Functional Overview

SISNAPI is used for network communication between AOM and Siebel Web Server Extension (SWSE) components used by the Siebel applications. Each multithreaded process for an AOM component uses a pool of SISNAPI connections managed by the SWSE. The process multiplexes (shares) many client sessions over each connection. Each client session request opens a new connection and adds it to the pool, until the number of connections defined by the value of the parameter SessPerSisnConn have been created. Subsequent requests are then multiplexed over the existing pooled connections. SISNAPI connections persist
until one of the following events occur:

• Web server process terminates
• AOM component terminates
• Value of the parameter SISNAPI Connection Maximum Idle Time (alias ConnIdleTime) is reached

For more information on this parameter, see Siebel System Administration Guide.

• Your firewall times out the connection

Multiplexing traffic over a set of SISNAPI connections helps to reduce the number of open network
connections.

Message Format

The SISNAPI message-body format has the following parts:

• HTTP header
• Object Manager method name
• Method arguments as key-value pairs

HTTP Header

When the Siebel Web Server Extension (SWSE) requests a new connection, the initial packets of the first SISNAPI message contain an HTTP header. This header includes a Uniform Resource Locator (URL) that provides routing information to the Siebel Enterprise Server, Siebel Server, and server component. Third-party HTTP load balancers use routing rules to parse the URL and route the message to the correct Siebel Server.

Connection Multiplexing

SISNAPI TCP/IP connections are specific to an Application Object Manager on one Siebel Server. Before opening new connections, the system checks to see if an existing connection is available. If so, the system uses the existing connection. Once the connection is established, it remains open for use by subsequent messages in the session or to be reused by other sessions.

User Request Types

The Siebel Web Server Extension (SWSE) generates three types of user requests. Each causes a new connection to a Siebel Server through the load balancer: initial request, retry request, and reconnect request. The Siebel load balancing module in the SWSE, recognizes these requests types and automatically routes them correctly. If you use a third-party HTTP load balancer, you must configure routing rules to handle these requests:

• Initial request. The SWSE generates this request to start a new user session as follows:
• The SWSE receives the request to start a user session.
• The SWSE creates the SISNAPI message. The HTTP header in message specifies the Siebel Enterprise Server and desired server component. The message does not specify a Siebel Server name. The SWSE forwards the message to a third-party HTTP load balancer, if installed.
• The load balancer parses the URL and compares it to routing rules that have been entered in the load balancer.
• The load balancer uses these routing rules to route the message to a Siebel Server specified in the routing rule. If no SISNAPI connection exists to the Siebel Server, a new one is created.

The Siebel Server receives the message and creates a new user session. The Siebel Server forwards address information back to the Web server.

• The Web Server creates a cookie containing the address information. The Web Server receives the cookie information in subsequent session requests. SWSE includes this information in the SISNAPI HTTP header.

The load balancer receives subsequent messages and forwards them directly to the specified Siebel Server and server component through the open SISNAPI connection.

• Retry request. If a server rejects an initial request, the request is routed back to the SWSE and the following occurs:
• The SWSE modifies the URL contained in the HTTP header by appending the letters RR to it.
• The SWSE forwards the message to the load balancer, if installed.
• The load balancer applies the routing rule that has been entered for RR messages. Typically, this is a round-robin routing rule that forwards the message to another Siebel Server.

• Reconnect request. The SWSE generates a reconnect request when it receives a user request for an existing user session that does not have a SISNAPI connection. The SWSE uses the session cookie information to include the server address in the SISNAPI HTTP header.

The reconnect request opens a new SISNAPI connection. Reconnect requests can occur for several reasons:

• The SISNAPI connection was opened by Web Server 1, but a Web server load balancer routes subsequent session messages to Web Server 2, which does not have an existing connection.
• The SISNAPI connection time-out is exceeded and the connection is closed.

The network environment closes the connection, for example due to a firewall time-out.