Whenever a salesperson looks up customer information, a call center agent enters a new trouble ticket, or a customer drops an item into the shopping cart on the Internet, all this information must be stored in a database. Siebel CRM is no exception to that rule. Relational database management systems (RDBMS) do a great job in storing any type of data and Siebel CRM supports a variety of versions and vendors.

The following table lists database system vendors (in alphabetical order), products, and versions supported by Siebel CRM 8.1 (Source: Siebel System Requirements and Supported Platforms, Version 8.1).

In addition to the above list, Siebel Remote, Siebel Tools, and the Application Deployment Manager use an embedded database engine from Sybase (Adaptive Server Anywhere). The version currently supported by Siebel CRM 8.1 is 9.0.1. Supported software vendors, platforms, and product versions are listed in the Siebel System Requirements and Supported Platforms document (SR&SP), which is published along with each release of Siebel CRM. SR&SPs can be downloaded from Oracle's Technology Network website at http://otn.oracle.com in the Documentation section.

What we need to know about the Siebel database is that it is used to store all the customer, administrative, and repository data. No business logic, such as constraints, primary keys, or foreign key references, is implemented at the database level. So, we can imagine the Siebel database simply as a place to store all the relational data we need in order to run the system.

Not all data needed by end users such as salespersons or call center agents can be easily stowed away in a set of tables in a relational database. People often rely on graphical information such as charts or images, additional descriptions, documents downloaded from the Internet, spreadsheets, and so on to get a more complete view of the relational data such as the customer information they see in the Siebel client.

Technically, the Siebel File System is a shared directory with a number of subdirectories. Most of these subdirectories are created during the installation process but some are added manually when specialized modules such as Siebel Search are set up.

Whenever an end user, an external system, or internal processes upload file-based information, the file is compressed, and stored in the directory tree. We can see a typical Siebel File System directory tree in the screenshot below:

For files that need to be accessed and downloaded by end users or external systems, Siebel CRM creates a record in a database table that points to the file. Because the files are compressed, and stored in a network share that is typically not accessible by the average user, the level of information security is very high. Even if we could locate a file stored in the Siebel File System, we would not be able to read the information contained in the file unless we uncompressed it using either the Siebel application or command line utilities provided by Oracle.

The following screenshot illustrates how a document attached to a customer record can be located and downloaded from the Siebel Web Client using the Attachments view in the Accounts screen.

A PDF file has been uploaded using the New File button. End users can now access the file by clicking on the hyperlink in the Attachment Name column.

Even though we can install and manage several Siebel Enterprise Servers in our network infrastructure, an Enterprise Server is not a piece of software but merely a logical collection of Siebel Servers that access the same Siebel database and file system, and which are managed by a single Siebel Gateway Name Server.

A Siebel Enterprise may consist of dozens of Siebel Servers, each running dozens of components—programs which implement a specific functionality. Each of these components has different parameter values. In order to easily manage all this information across the entire Enterprise, Siebel has developed the Gateway Name Server. It is a service or daemon process that stores the entire enterprise configuration in a text file named siebns.dat, hence the official name of the file is "Enterprise Configuration Store".

In order to understand the role of the Gateway Name Server properly, we can examine the following scenario:

A Siebel administrator stops all Siebel services. He then tries to start the Siebel Servers without starting the Gateway Name Server. An error message indicates that the Siebel Server could not start.

This is because the only piece of information that a Siebel Server has at the moment of startup is the hostname of a Gateway Name Server, which it immediately tries to contact in order to retrieve more configuration information.

So, the Gateway Name Server is a critical component of the Siebel Web Architecture because it must be present when any Siebel Server starts up or configuration changes have to be applied. However, if the Gateway Name Server fails during normal operation, end users and external systems will still be able to access the Siebel applications and functionality provided by the Siebel Servers. But, it is of course a good idea to monitor the Gateway Name Server and bring it back to life as soon as possible if it should fail.

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:

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.

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.

As the entire communication with the browser on the end user's computer has to be done via http, a web server is a vital part of the Siebel Web Architecture. Siebel CRM supports a variety of vendors and products such as Microsoft's Internet Information Services, HP Web Server (Apache), or Oracle HTTP Server (Apache).

The web server has to exist but does not need to take heavy load. As we have seen above, the Application Object Manager handles all incoming requests. So, the web server's only task is to pass requests to the application object manager and pass the result back to the end user's browser.

It is exactly at this point where questions should be raised. How can a third-party web server communicate with a proprietary application server? (We learned that the Siebel Server is not a standard application server.) The solution is just at hand in the form of a piece of software that is installed on the web server in order to teach it the internal Siebel protocol. This is where the Siebel Web Server Extension enters the stage.

The Siebel Web Server Extension (SWSE) enables any supported web server to communicate with the object managers on the various Siebel Servers. The SWSE serves as a plug-in and enables the web server to forward incoming request URLs from the end user's browser to the application object manager session on the Siebel Server.

Among the more interesting capabilities of the SWSE is the authentication of user sessions and load balancing. The SWSE reads a configuration file named eapps.cfg that links each virtual directory on the web server to a process on the Siebel Server. This process is implemented as a server component named Siebel Connection Broker.

The following diagram illustrates how the SWSE connects to the appropriate Application Object Manager on one of the Siebel Servers on the network:

We cannot discuss web-based architectures without talking about web browsers. As we know, the Siebel Web Engine renders the result pages, which are then passed back to the user's browser window. Siebel applications come with a pre-built user interface that can be distributed in two modes, namely High-Interactivity (HI) Mode and Standard Interactivity (SI) Mode. HI mode provides for very high usability. For example, drag and drop operations, scrolling through lists of records, the right-click context menu, and the wizard-style Task User Interface are features that are only available in the HI mode. The penalty for this high level of user friendliness is the limited set of supported browsers. In fact—because HI mode uses Microsoft's ActiveX technology—Microsoft Internet Explorer is the only browser that is supported for Siebel applications in HI mode. The following screenshot shows the Siebel Sales application in High-Interactivity mode running in Microsoft Internet Explorer:

Other browsers like Firefox or Safari are supported only for Siebel applications in SI mode. The following screenshot shows the Siebel Partner Portal application in Standard-Interactivity Mode in Mozilla Firefox.

There are even more ways to generate a rich user experience. The Siebel Enterprise Application Integration (EAI) framework provides pre-built web services and capabilities to support any external application, from a simple browser to middleware-based UI generators, to access the Siebel data and business logic in order to generate their own UI.