Siebel Performance Tuning Guide > Siebel Architecture and Infrastructure >

About Siebel User Request Flow

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

Figure 2. Generic User Request Flow in Siebel Business Applications

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 request is generated by the Web browser and Siebel Web Client framework.
2. The request goes through the network, using an existing or new HTTP connection. The request might go through a network router, proxy server, cache engine, or other mechanism.
3. If present, Web server load balancing software evaluates the request and determines the best Web server to forward the request to. It then forwards the request to a Web server.
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) installed on the Web server.
5. The SWSE parses the HTTP message and generates a Siebel Internet Session Network Application Programming Interface (SISNAPI) message, based on the content of the HTTP message. SWSE also parses the incoming cookie or URL to obtain the user session ID.
   • If you are using Siebel load balancing, then SWSE forwards the request to a Siebel Server in round-robin fashion.
   • If you are using a third-party HTTP load balancer, then SWSE forwards the request to the load balancer. The load balancer uses user-configured routing rules to forward the request to a Siebel Server.

     SISNAPI is a messaging format that runs on top of the TCP/IP protocol. It is used for network communication between Siebel Servers and SWSE.

6. On the Siebel Server, the SCBroker component receives the initial request for a session and forwards it to a Siebel Application Object Manager process. Subsequent communication for the session does not use SCBroker. For more information, see Siebel Application Object Manager Infrastructure and related topics.
7. The Siebel Application Object Manager receives and processes the SISNAPI message sent from SWSE.

   If a database query is needed to retrieve the information, then the Siebel Application Object Manager formulates the SQL statement and sends the request to the Siebel Database over a database connection. The database request goes through the database connection, using a protocol format that is specific to the database connector.

8. The database executes the SQL statement and returns data back to the Siebel Application Object Manager. The Siebel Application Object Manager forwards the message to the Web server that originated it. If using a third-party HTTP load balancer, then the message might go through the load balancer before reaching the Web server.
9. The SWSE on the Web server receives the SISNAPI message, and translates it back to HTTP. It then forwards the HTTP message to the Web server. The message is now in the form of Web page content.
10. The Web server load balancer, if present, then forwards the Web page content through the original HTTP connection to the end user's Web browser.
11. The Web browser and the Siebel Web Client framework process and display the return message.