SISNAPI

Siebel Internet Session Network API (SISNAPI) is a proprietary (originally Siebel, now Oracle) message format protocol running over HTTP. SISNAPI is used for communications between various Siebel components such as Web server, Gateway server, and Siebel application server.SISNAPI (Siebel Internet Session application programming interface), a messaging format that runson top of the TCP/IP protocol, is used for network communication between AOM and Siebel WebServer Extension (SWSE), installed on the Web server. SISNAPI connections can be configured to useencryption and authentication based on Secure Sockets Layer (SSL).Each multithreaded process for an AOM component uses a pool of SISNAPI connections managed bythe 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 ofconnections defined by the value of the parameter SessPerSisnConn have been created. Subsequentrequests are then multiplexed over the existing pooled connections. SISNAPI connections persistuntil 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 reachedFor more information on this parameter, see Siebel System Administration Guide.■ Your firewall times out the connectionMultiplexing traffic over a set of SISNAPI connections helps to reduce the number of open networkconnections.

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.