Performance Tuning Guide > Siebel Architecture and Infrastructure >

About Siebel User Request Flow

Figure 2 illustrates how a user request is processed within the Siebel eBusiness Applications architecture and infrastructure (generically presented), and shows potential areas for performance tuning. For a description of each portion of this data flow, refer to Siebel Server Administration Guide and other relevant documents on the Siebel Bookshelf.

Figure 2.  Generic User Request Flow in Siebel eBusiness Applications
Click for full size image

A typical Siebel client request flows from the user's Siebel Web Client through the system, and back again, following the general flow outlined below.

  1. A user performs an action that initiates a request. For example, the user clicks a link in the Site Map to navigate to a particular view. The Web browser and Siebel Web Client framework initiate the HTTP request containing the request as the body of the message.
  2. The HTTP request goes through the networking infrastructure, using an existing or new HTTP connection. At this point, the request may go through a network router, proxy server, cache engine, or other mechanism.
  3. If applicable, the Web Server load balancer evaluates the request and determines the best Web server to forward the request to. The request is then forwarded by the Web server load balancer through the network.
  4. The Web Server receives the HTTP request, determines that it is a Siebel application request, and forwards the request to the Siebel Web Server Extension (SWSE), which is installed on the Web server.
  5. SWSE parses the HTTP message and generates a SISNAPI message, based on the content of the HTTP message. SWSE also parses the incoming cookie or URL to obtain the user session ID.

    SISNAPI (Siebel Internet Session application programming interface), a messaging format that runs on top of the TCP/IP protocol, is used for network communication between AOM and SWSE.

  6. SWSE forwards the request to the Siebel Server hosting the user session. The message either goes through an existing SISNAPI connection or SWSE opens a new SISNAPI connection to the server.

    Typically, the TCP/IP packets carrying the SISNAPI message have a virtual IP address and port as the destination. The message may also be passed through a DMZ firewall.

  7. The SISNAPI message is received by the primary scheduler using either a new TCP/IP (SISNAPI) connection or an existing connection.
    • For a new TCP/IP connection request, the scheduler forwards the connection to one of the Siebel Servers.
      • If this request is a new login request, the scheduler routes it to the least-loaded server.
      • If the request is from an existing session, the scheduler routes it to the server hosting that user session.
    • For an existing TCP/IP connection, the scheduler forwards the request to the server currently hosting this TCP/IP connection.
  8. The request goes through the back-end TCP/IP connection of the scheduler to the Siebel Server.
  9. On the Siebel Server, the AOM component receives and processes the SISNAPI message. If a database query is needed to retrieve the information, the AOM formulates the SQL statement and sends the request to the Siebel Database over a database connection.
  10. The database request goes through the database connection, using a protocol format that is specific to the database connector.
  11. The database executes the SQL statement and returns data back to the AOM.
  12. The data is forwarded back to the AOM.
  13. Through a Central Dispatch network driver on the Siebel Server, the returning SISNAPI message bypasses the scheduler and goes directly to the Web server.
  14. The SWSE receives the SISNAPI message, and translates it back to HTTP. It then forwards the returning HTTP message to the Web server.
  15. The Web server load balancer then forwards this request through the original HTTP connection. The message is forwarded back through the networking infrastructure to the end user's Web browser.
  16. The Web browser and the Siebel Web Client framework process the return message and update the user's application accordingly. The user now sees the requested information displayed on the screen.

 Performance Tuning Guide 
 Published: 24 October 2003