Deployment Planning Guide > Load Balancing and Resilient Processing Planning >

About SISNAPI

Siebel Internet Session Network API (SISNAPI) is a Siebel proprietary message-body format running on top of TCP/IP. SISNAPI is used to communicate between the Web server, Siebel Gateway Name Server, and Siebel Servers. When a client request comes to the Web server, the Siebel Web Server Extension (SWSE) intercepts the request and forwards it in SISNAPI 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.