Siebel Architecture Roundup

Though we treat Siebel Architecture knowledge as the very basis on which we build more knowledge, it is surprising to find many people tongue-tied when answering specific questions about it. Here is my way of doing a roundup on the Siebel architecture which actually implies that it is simplistic, useless other than to understand what goes on at a high level and ignores all complexities. This overview is a top-down look at what happens where. The highlight of this post may be this badly prepared diagram.

Core Components
First, a look at the various components involved. To start with, consider the most prominent client of them all a PC web browser accessing the Siebel application server situated remotely. Web server Siebel application, in its present form, is nothing but an application server with add-on components to provide access, report & interact with other applications. Any application server needs a web server, which is the one that frontlines user fury. Siebel application is accessed by typing an URL in the browser. The URL (for e.g.: "http://crm.myorg.com/callcenter_enu"), consists of two parts - the IP/domain name for web server itself and the Siebel Web Server Extension (SWSE) instruction. SWSE is a component installed on the web server, which is responsible for identifying Siebel requests and forwarding it to the application server. In our case, SWSE will see the user request for the call centre application and forwards it to Siebel. The Object Manager will return HTML content, which is promptly routed to the browser through web server. Important components here are:
y eapps.cfg Configuration file that informs SWSE where to find the Siebel server and parameters like anonymous user details (required to display the login page), session time out parameters and the like y Virtual directories Located in SWSE logical profile directory, these folders store files required by the various Siebel applications y lbconfig.txt Siebel native load balancer uses this file to recognize the various Siebel servers available and the components available on them

Aside:
y Web servers can be load balanced using hardware or software load balancers available in the market. The load balancing architecture also can be different from installation to installation. For a Siebel application developer, this is transparent y Siebel itself can use native load balancing (version 7.7 onwards) or third party load balancing. While the former uses the lbconfig.txt directly, we can use the lbconfig information to write rules in case of load balancing using third party tools y Take a look at the web server logs, it lists lot of URLs that let us understand how requests fly back & forth. All user requests are captured here y Since SWSE is the gatekeeper for all user requests, it is the right place to go if we want to see the application performance in the last mile. In fact, SWSE provides a summary web page that lists the worst performing responses

Siebel Gateway (aka Name Server) Any request forwarded by the SWSE to Siebel will pass through Siebel Gateway, which routes requests to various Siebel servers in the enterprise. A single gateway can serve multiple enterprises. Gateway keeps a tab on various Siebel servers in the enterprise and components available on the servers. This information is available in a volatile store depending on the status of various components. Requests for service will be routed to different servers based on which components are required to serve that request and where those components are able to take requests at that instant. Important components here are:
y siebns.dat All configuration information of Siebel servers is stored here. Siebel servers use this file at the time of start-up to find which components they have. Periodically the non-persistent information in the volatile store is dumped to this file

Aside:
y Gateway, though crucial, is not resource hungry y When Gateway goes down, users are not kicked-out but no new logins are allowed. The existing users will not be able to start any new processes that have dependency on an external component y siebns.dat file is notorious for data corruption, periodic backups as well as taking backups before enterprise changes will ensure a more peaceful IT team y Though it looks like a bunch of text, manually editing siebns.dat is not supported. If there are no backups to fall back on, "Go Tech Support!" y High availability is supported through resource clustering

Siebel Enterprise Server A logical grouping of Siebel servers, Enterprise Server is not a physical entity. An enterprise server will function using a single instance of database. It is most useful to push common parameters across to various components on different Siebel servers. Remember that Gateway sends the requests to servers depending on component availability? - well, then we dont have anything more to deal with here.

Siebel Server This is our guy in the group. Siebel server (more specifically one or the other Object Manager) receives user requests, pulls in data from database/from other sources, applies business logic, builds UI, merges data & UI and sends back information to requestor whew! Siebel server processes can be executed in interactive, background or batch mode and can be single or multithreaded. Siebel Object Manager is a component that resides in Siebel server that does most of the work. Different verticals & horizontals provided by Siebel CRM use different Object Managers, for example Call Centre OM, Sales, eService OM, etc, with each language having its own OM. That is the reason we have a "sales_enu" and a "sales_egb". Apart from this, we have OMs for external facing functions like Enterprise Application Integration (EAI). Object Managers in turn use other components in the server do execute various tasks. "Data Manager" worries about database interactions, "Assignment Manager" takes care of task allocation and so on. Components also work independent of user interactions - "Workflow Process Manager" takes care of validations & automations, "Transaction Router" & "Transaction Processor" manage remote clients and "Enterprise Integration Manager" (EIM) enables loading of external data in Siebel application. Other Important components here are:
y Server Request Broker (SR Broker) and Server Request Processor (SR Proc) facilitate calls between different entities in the Siebel server. SR Broker handles synchronous requests, while SR Proc handles (server initiated) asynchronous requests. Both components are capable of utilising components within the server or those on other servers. This is termed as "resilient processing" y Server Connection Broker is the intra-server load balancer, and manages spawning of tasks and threads of each component

Aside:
y Calls between different entities in the Siebel server is facilitated by Server Request Broker and Server Request Processor through Gateway. All communications within Siebel space use SISNAPI or Siebel Internet Session Network API y Reports are not actually taken care in Siebel, rather those requests are passed on to "Actuate" reporting application. Actuate is tightly integrated to recognize Siebel data model, interact with database and produce reports y Interactions with Oracle Business Intelligence happen through an interface, a welldefined one at that

CLIENTS
The common web client defined above can also be of two types:
y High Interactivity Client Installs and uses ActiveX controls on the client machine. Obviously, it requires Internet Explorer with suitable patches for IE and the operating system itself. Safe to consider it when the web clients reside on desktops under some degree of control y Standard Interactivity Client Zero footprint, works on more browsers but UI is nothing to write about

Web clients can bypass server in a dedicated client mode. This mode uses Siebel Repository File (SRF) on the client machine and connects directly to the Siebel database. Web clients also can function in a disconnected mode for that we extract data for the user from the Siebel server and provide a copy of SRF on the client machine. The data in local database then needs to be periodically synchronised with the Server. Other than web clients, there is Siebel Handheld for phones coming under the PDA bracket. Siebel is installed on the phone device and provides field force with a way to manage Siebel data. Handheld devices can be used in a disconnected mode and later synchronised with the Siebel server directly using http/https requests or using a PC as intermediary. Technically, any phone with a browser can be used to connect with Siebel applications, but one look at the way the application looks on the tiny screen should put such considerations to rest.

DEAL WITH OUTSIDE WORLD

Lot of integration gurus have a lot to say about how enterprises need to build their processes. To simplify overtly, I tend to think of all integrations as passing through the service bus. All interactions with the external systems, maybe for provisioning, billing, supply chain management etc. will involve one or the other requests flying into or out of Siebel applications through the Service Bus - out into the big bad world. Havent heard of Service Bus? Relax, here it just refers to any standard middleware application like Oracle Fusion, IBM Websphere and the like