Siebel Deployment Planning Guide > Siebel Architecture Overview >

Example of User Request Flow in a Siebel Deployment

Figure 3 illustrates how a user request is processed within the Siebel Business Applications architecture. In the diagram, there are two types of load balancing:

  • Web server load balancing. Web client requests are forwarded through a load balancer to multiple Web servers.
  • Siebel Server load balancing. Web servers forward user requests to a third-party HTTP load balancer for distribution to Siebel Servers. If Siebel native load balancing is used, a request is forwarded directly to a Siebel Server.
Figure 3. 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 may go through a network router, proxy server, cache engine, or other mechanism.
  3. If present, Web server load balancing software evaluates the request, determines the best Web server to receive the request, and 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 Siebel Web Server Extension 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. For Siebel Server load balancing:
    • If you are using Siebel native load balancing, SWSE forwards the request to a Siebel Server in round-robin fashion.
    • If you are using a third-party HTTP load balancer, SWSE forwards the request to the load balancer. The load balancer uses user-configured routing rules to forward the request to a Siebel Server.
  6. On the Siebel Server, an AOM 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.

    The database request uses a protocol format that is specific to the database connector.

  7. The database executes the SQL statement and returns data back to the AOM. The AOM forwards the message to the Web server that originated it. If you are using a third-party HTTP load balancer, the message may go through the load balancer before reaching the Web server.
  8. 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.
  9. 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.
  10. The Web browser and the Siebel Web Client framework process the return message and display it to the end user.

Siebel Deployment Planning Guide Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices.