Let us start our course with the most important thing in Siebel CRM. Whether you are Siebel Configuration, Siebel Administrator, Siebel EAI , EIM or Siebel Project Manager it is of utmost important that you have a proper understanding of Siebel Architecture thoroughly.
In this session we will discuss step by step what happens inside Siebel and how Siebel interprets and recognizes external requests and their flow inside Siebel right from user entering Siebel request in Login page in his browser to the response received back from Siebel.
A Siebel Enterprise application is a collection of Siebel Servers(Load balancing) grouped into an logical Enterprise Server, a Gateway Name Server,Siebel Web Server Extention, a WebServer and a Relational Database Server.
Let us assume a user following URL in address field of his browser.
Where HTTP stands for Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web.
TESTWebServer is the name of the WebServer you have installed at the time of installing siebel.
fins_enu refers to the Application Object Manager. By entering fins_enu you let WebServer know that a Siebel request has come which is trying to access Object Manager for Siebel Finalcial Services.
SWE stands for Siebel Web Engine and Start.SWE tells WebServer to start a SWE session.
ENU is the language. For multilingual implementation this url might change as per the language and might look like as following.
Now let us come back to what we were discussing.
Follow the picture as we discuss about the Siebel architecture. This picture is taken from Siebel Bookshelf.
Let us think Mr. John enters the following URL in his local browser to access his customer’s details from Siebel.
1. The request goes to Webserver TESTWebServer over http. Webserver interprets that request and if it observes that it is a Siebel request it passes that request to SWSE inside Webserver.
SWSE stands for Siebel Webserver Extensions – a Siebel Component that is installed inside Webserver.
2. Webserver has virtual directories which will have entries against all of the application object manager.
Go to Control Panel –>Administrative Tools -> Internet Information Service (IIS) Manager , open it and locate fins_enu.
You will observer IIS(WebServer) having other virtual directories against other object managers.
If you go to Custom Errors tab you will observe HTTP error like
Which is not in scope of our discussion and there could be a complete blog all together to discuss different HTTP error that may come and how to nail them.
Enough of virtual directories let us come back to the actual flow of Siebel request
3. As soon as a virtual directory finds the object manager the request passes to eapps.cfg file which resides in SWSE and it contains the parameter which controls the information of which request should point to which object manager in turn this configuration file contains the parameters that controls the integration between SWE and SWSE.
4. There is a common myth that Gateway Name Server is responsible for Intra-server load balancing, this is totally wrong. You can bring down the gateway server and still you can login to Siebel and carry out your normal transactions however you can’t navigate to Administration – Server Configuration or Administration Server Management screen as these screens pull their information from Siebns.dat file residing in Gateway Name server. The point to be noted here Gateway Name server is configured as Named Subsystem aka Profile Configuration and its information is stored in sibens.dat file. Gateway name server is connected as a GatewaydataSrc named subsystem.
5. Siebel Connection Broker (SCBrocker) is responsible for intra-server load balancing. It is a server component.` Whenever eapps.cfg receives the request it locates he corresponding object manager in eapps.cfg file and once found it calls SCBrocker Server component and SCBrocker forwards the request to the AOM which has got least number of tasks running on that object manager at that particular time, thereafter SCBrocker forwards all the Siebel request to that object manager for that particular session unless otherwise explicitly asked by Siebel for another object manager like in the case of Server Request or Workflow Policy. We will discuss them in a separate note.
6. AOM receives the request and finds the data source corresponding to the object manager and it could be located under Component parameters ODBC Data Source and makes the connection with the database.
7. For the initial request without username and password, AOM could not figure out the username and password of the request and hence treats the user as guest user and SWE creates guest login page and forwards the request to SWSE.
8. Webserver sends back the results to the user who initiated the request and now he sees a login page as shown follow.
10. Data manager validates the login against database and the connection is established by Application Object Manager Parameter ‘ODBC Data Source’ and passes the results back to AOM. AOM retrieves the Responsibilities and views of the users and establishes the homepage as startup page.
How can you configure which page will by default be the landing page or startup page for a particular application.
11. SWE creates the pages and sends them back to webserver from where users get the home page.
13. In all the subsequent interaction Business Object layer constructs the business logic of the operations requested by users,
14. Data Manager constructs the SQL against that request , forwards that request to database layer (Relational RDBMS) and sends back the results to business object layer. Business Object Layer contacts SWE and SWE constructs the WebPages with the result set which then goes to SWSE to Web server and finally user retrieves them in his local machine.