
The Siebel Server
Processes that interact with end users, or external systems that access data in the Siebel database, or files in the Siebel File System, are all located on one or more Siebel Servers. Each Siebel Server is a member of just one enterprise. In more technical terms, a Siebel Server is an application server. An application server is a generic container for applications or programs that are made available for access by other systems.
Being just that, an application server, the Siebel Server hosts so-called components, that implement the various pieces of Siebel functionality such as providing end user sessions, uploading files to the Siebel File System, exchanging data with external systems, and so forth.
For the sake of scalability and preventing single points of failure, installing more than one Siebel Server is very common. This allows administrators to assign components to explicit servers and avoid poor performance when end users or external systems produce heavy load.
The software units on the Siebel Server that are needed to support Siebel applications include:
- Application Object Manager (AOM)
- Configuration Parameters
- Data Manager (DM)
- Siebel Repository File (SRF)
- Siebel Web Engine (SWE)
- Siebel Web Templates (SWT)
The Application Object Manager (AOM)
If we look at the Siebel Web Architecture from an end user's perspective, a component must exist on the Siebel Server that handles all requests made by the user as he or she clicks in the browser window. Components of this type are called Application Object Manager. They are programs that handle all user interactions such as authentication, data access, and rendering of the pages passed back to the user's browser. In other words, they execute the complete application logic on behalf of the end user. If we could place an application object manager under a microscope, this is what we would see:

In the following section, we will discuss the software units and files that are constitutional parts of the Siebel application architecture.
Configuration parameters
It is correct to think of the Application Object Manager as a generic program that acts upon a specific set of parameters for each incarnation. These parameters have historically been stored in text files on the Siebel Server. The files, with an extension of .cfg
, are still present in modern Siebel CRM versions but only a tiny fraction of the parameters that drive the behavior of the Application Object Manager originate there.
The second and more important portion of parameters is stored and managed by the Siebel Gateway Name Server and loaded into the Siebel Server's memory when it starts up.
Data Manager (DM)
This is the application object manager's access layer against the relational data sources. Using specific dynamic link libraries (dll) on Microsoft Windows or shared objects (so) on UNIX-based operating systems, the data manager layer generates database vendor-specific SQL statements.
Siebel Repository File (SRF)
As we can see in the object manager diagram, the application object manager reads a file with a .srf
extension. This file, known as the Siebel Repository File, contains a structured representation of the application metadata, which allows the object manager to quickly derive vital information such as table and column names, business logic, and user interface layout. The Siebel Repository File is consumed not only by the application object manager component type but also by other Siebel Server components that need access to metadata information.
Siebel Web Engine (SWE)
A request coming in from an end user or an external system is basically a set of commands towards the Siebel Web Engine (SWE). The SWE parses the commands and calls functions of underlying programs in order to satisfy the request. Other modules of the application object manager execute the business logic or access the database to retrieve the necessary data. The SWE is also responsible for building the result pages, which are then passed back to the browser.
Siebel Web Templates (SWT)
Many of the layout elements of the Siebel user interface such as lists or forms are repetitive in their style (for example a list will always contain a top banner with button controls and the columns in the list will always have a header and body text). For this reason, the HTML for these elements does not need to be generated on the fly. It can rather be stored in text files that are read by the Siebel Web Engine.
These files are named Siebel Web Templates and typically have a suffix of .swt
. If we examine these files more closely we find that they contain typical HTML tags such as <table>
but also tags that are proprietary commands for the Siebel Web Engine. These <swe:>
tags are replaced with content rendered by the Siebel Web Engine at runtime.

The above screenshot shows a Siebel Web Template opened in the Web Template Explorer provided by Siebel Tools, the development environment of Siebel CRM.