Oracle Siebel CRM architecture is similar to the the standard 3-tier architecture employed for web applications and is straight-forward to understand. Though the concepts are well known, developers new to Siebel often do not articulate how the various pieces of puzzle come together.

Siebel architecture overview outlined here is an attempt to simplify concepts and provide a depiction of the components that power Siebel CRM applications. The architecture described here holds good for Siebel v8.1.x.

What is so special about Siebel Architecture? #

Well, nothing really.

Siebel is atypical of many n-tiered application architectures. What started as a client-server model (circa Siebel 6) transitioned to web-focused architecture (Siebel 7+). We clearly see that struggle to get the rich client functionalities right in its use of ActiveX controls - the only useful UI experience in Siebel for 5+ years. Siebel Open UI is a more mature, modern way to take that experience into the future.

Siebel application is made up of both Siebel and third party components. Siebel provides the core components, while relies on third parties for web server, database, and so forth. As with any enterprise software this can be as complex as they come.

The architecture diagram below shows how the components are stacked up against each other, and the associated description gives a brief on what the components do.

Details follow..

Access channels #

Users typically connect to the Siebel application through the intranet or internet, using a supported web browser. This kind of access, known as the access through ‘Siebel Web Client’, puts the user in touch with the web server over HTTP or HTTPS protocols.

Siebel applications can work in three interaction modes:

1. Siebel High Interactivity (HI): Uses ActiveX controls to enhance UI for offline/online clients. Typically used in almost all Siebel deployments, and it is fairly normal to address this as ‘standard Siebel’. This mode is deployed to organization’s employees or partners, but not for external users.
   Siebel HI is supported on Internet Explorer 6, 7 or 8. Unofficially the application works on IE9 and IE10 as well (try compatibility mode in case of issues), but that may not be a good idea to deploy in production.
2. Siebel Open UI: Introduced in version 8.1 (IP 2013), Open UI is fast becoming the default deployment for clients. Open UI incorporates modern web application standards to support application access across multiple browsers and devices.
3. Siebel Standard Interactivity (SI): SI was Siebel’s way of supporting users outsider the organization supported infrastructure. SI is also supported across browsers and does not bother about underlying Operating Systems. SI does not use any ActiveX controls but utilises the architecture based on HTML/CSS that were common in early 2000s.
   SI was Intended to provide a typical website (or portal) experience for an external user like the customer of the organization, or a partner. It is clunky to use and typically does not match the expectation of a modern website. Use SI if you want to frustrate your users.

Alternate access channels for Siebel include:

• Offline access, called ‘Siebel Mobile Client’, allows users to work in disconnected mode on a data snapshot in the user’s laptop. The Siebel client synchronizes from time to time with the Siebel server
• Siebel Handheld provides access to the application through Windows 6 based mobile devices. It is fast declining in popularity due to obvious reasons
• Siebel Mobile: Siebel Mobile applications are enabled using a container app provides access to Siebel mobile-specific UI developed using Open UI. You could expose the same Open UI screens to mobile devices as well, but that is a sure way to make sure people do not use touch based devices to access Siebel.
  Typically mobile UI is developed with limited fields and features and deployed to a distinct URL (a separate Siebel Object Manager takes care of requests through this URL).
  Offline mode is supported, but is limited to 50 MB on the device (including metadata). Enabling offline mode requires additional configuration in the application (e.g. data filters).

Web Server #

Siebel applications use a third party web server like IIS or Apache. When the user enters the application URL in the browser or performs an action in the Siebel application, the request travels over HTTP to reach the web server. The URL itself (for e.g.: crm.myorg.com/callcenter_enu) consists of two parts - the IP/domain name for web server 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 the above URL, SWSE will understand that the request is for call center application and forwards it to the back end for processing.

Once the response has been formulated by the back end infrastructure, Web server responds back with the HTML content that the browser can understand and display to the user.

Important components here are:

• eapps.cfg: Configuration file that informs SWSE on where to locate the Siebel server. It contains parameter values including a dummy (anonymous) user that is used to initiate login page, and session time-out values
• Virtual directories: Located in SWSE logical profile directory, these folders store the web server files required by the various Siebel applications
• lbconfig.txt:  Siebel native load balancer uses this file to recognize the various Siebel servers and the components available on them. Depending on the load balancing option and component availability, the request is routed to a specific Siebel server

Gateway #

Any request forwarded by SWSE to Siebel will pass through Siebel Gateway (a.k.a Name Server), which in turn routes the request to the available Siebel servers. Gateway keeps a tab on various Siebel servers in the enterprise and components deployed on servers. All server and component 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 the components that are required to serve that request, and on servers that can take requests at that instant. A single gateway can serve multiple enterprises.

Important components here are:

• siebns.dat – All configuration information of Siebel servers is stored here. Siebel servers use this file at the time of start-up to determine the components that have be brought online. Non-persistent information in the volatile store is periodically dumped to this file.

 Siebel Server #

Siebel server (more specifically one or the other Object Managers) receives user requests, pulls in data from database/from other sources, applies business logic, builds user interface (UI), merges data & UI and sends back information to requester. Siebel server processes can be executed in interactive, background or batch mode, and can be single or multi-threaded.

Important components here are:

• Siebel Application Object Manager (AOM) is a key component of Siebel server that does most of the work. There can be more than one AOM in a single Siebel server. Following are few interesting facts about AOM:
  • Different verticals & horizontals in Siebel CRM use different Object Managers. Siebel vertical line of applications are industry-specific (e.g., Siebel Life Sciences, Siebel Media & Telecom), while horizontal applications cut across industries (e.g., Siebel Call Center, Siebel eService)
  • Each language within the vertical/horizontal will have its own OM. We can have a “sales_enu” (English-US) and a “sales_egb” (English-UK)
  • OMs can serve requests from users, or from systems integrating with Siebel in real-time. For e.g. ‘Siebel Call Center’ typically is configured for end users, while ‘EAI Object Manager’ will cater to external system requests
  • Object Managers use other components in the same server or in some other server to execute assigned tasks. So we have ‘Data Manager’ worrying about database interactions, ‘Assignment Manager’ taking care of task allocating work to employees, ‘File System Manager’ providing access to files and so on.
• There are components in Siebel servers that are not OMs, and can work independent of user interactions. For e.g., ‘Workflow Process Manager’ takes care of executing ‘Siebel Workflows’ that apply business rules or automate a task, ‘Transaction Router’ & ‘Transaction Processor’ manage remote clients and ‘Enterprise Integration Manager’ enables batch loading of external data in Siebel application
• Siebel Web Engine (SWE) connects the SWSE & web server with Siebel server. It gathers information on the UI layout through Siebel Web Template (SWT) files and in SRF (Siebel Repository File), and supplies the generated HTML to the web server
• Siebel Repository is a collection of application configuration tables, data tables and indexes that are used by Siebel, and reside on the database. Customization to Siebel CRM typically involves making changes to the Siebel Repository
• Siebel Repository File is the compiled form of Siebel repository. All components of the Siebel server use both repository and SRF

A logical grouping of Siebel servers is called “Enterprise Server”. While it is not a physical entity, it functions to tie together the specified Siebel servers. One enterprise server will function using a single instance of database.

A summary of the request/response flow for Siebel CRM applications is provided below.

Database #

Siebel uses a third party relational database - Oracle or DB2 are supported. Typically the database servers are placed in the same data center as the application server, and should have good network connectivity with the Siebel server. Connections from Siebel server to DB are ‘automatically’ handled, developers do not have any control over how DB queries are fired or how the connections are pooled. Reading of Siebel data can bypass business/integration layer, but writes cannot be directly done on the DB.

File System #

The file store used by Siebel applications is known as ‘Siebel File System’. File system can be a Network Access Storage, or a simple shared folder that is accessible for all Siebel servers. One enterprise will have a single file system.

Files are read and written only through the Siebel business or integration layer. Files are stored as Siebel Archive Files (*.saf), a Siebel-proprietary compressed format. When user or an external system requests for the file, Siebel retrieves the file from disk, decompresses it and provides the actual file to the requester.

The descriptions above should have provided you with a fair idea on how the Siebel system works. If this has piqued your interest, further-reading can be found in “Siebel System Administration Guide” of Siebel Bookshelf .

You can download the architecture in Visio format here.

Download Architecture