Installing and managing a complex enterprise application such as Oracle's Siebel CRM can be challenging. Whether you consider yourself a seasoned IT professional or a beginner: once we add concepts such as load balancing or multiple language deployment, it is easy to get lost.
The reason why you are reading this book might have been stated above. In this book, we are going to follow a typical Siebel CRM installation procedure. Additionally, we will look under the hood and learn how to manage all those different pieces of software.
Understanding the building blocks of Oracle's Siebel CRM applications as well as knowing how to avoid general pitfalls during installation and system management are of course great benefits. We can then execute our Siebel CRM projects more quickly and subsequently with less cost and risk.
When you finish this book, you will not only be able to successfully master the installation and system management procedures, you will also have the advantage of a deep understanding of the intricacies of Siebel CRM.
Instead of starting the setup program in a rush to see what happens, we should first understand what we are going to install. It is therefore strongly recommended to follow the course of this book. The topics in this book are arranged so that each chapter builds upon the previous one. The following is a list of what we will learn:
Understanding the Siebel web architecture
Planning and preparing a Siebel CRM installation
Installing the Siebel CRM server and client software on different operating systems
Installing ancillary server software
Configuring load balancing and installing language packs
Managing Siebel Servers
Provisioning external authentication
Understanding and managing data security
Supporting developer teams and mobile users
Deploying configuration changes
Measuring application performance
This chapter sets the stage with an overview of the Siebel Web Architecture. We will describe the building blocks of the latter in order to be able to lay out a concise planning document and use a structured approach during the installation and configuration procedures.
In order to allow thousands of users access to critical enterprise data over the web channel, Siebel CRM is based on a typical web architecture. This architecture allows for great scalability and platform compatibility and has been under development for more than a decade.
In 2001, Siebel released version 7.0 of its CRM suite. This was the first version that was completely web-based. Prior versions (like Siebel 2000) were based on the client-server architecture, which was typical for enterprise applications in the 90s.
However, Siebel 7.0 was not the first version that allowed access to data and functionality from a web browser. Applications like Siebel eService or Siebel eSales were available in earlier versions and the Siebel web architecture as we see it today had its origin in these first customer facing web applications.
The Siebel web architecture consists of the following main building blocks:
A relational database to store customer, administrative, and repository data
A shared directory structure to store binary, non-relational information such as attachment documents and temporary files
Let us bring these building blocks together in a diagram:
The diagram above depicts the Siebel Web Architecture. In the following section, we will discuss each of the major building blocks in detail.
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).
DB2 UDB for z/OS
8 or above
2005 SP1 or above
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:
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.
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.
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.
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.
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.
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.
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 first part of the URL entered into the browser's address bar points to the web server that hosts the Siebel Web Server Extension.
The second part of the URL references a virtual directory on the web server. The naming convention (as suggested by Oracle but not written in stone) is "application_language". So, the above diagram shows an example of a connection to the Siebel Call Center application in American English (enu = English—United States). Each "application_language" string is stored as a section in the
eapps.cfgfile read by the Siebel Web Server Extension.
In the section in the
eapps.cfgfile, the SWSE can read the Siebel Server hostname and the port number of the Siebel Connection Broker component.
In addition, the SWSE reads the internal name of the Application Object Manager instance.
The SWSE can now connect to the Siebel Connection Broker component and request a session for the Application Object Manager.
The Siebel Connection Broker forwards the request to the appropriate process on the Siebel Server.
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.
A Siebel application can display data from and write data to multiple data sources. including non-relational sources.
Siebel CRM has a proprietary protocol named SISNAPI (Siebel Internet Session Network Application Programming Interface), which allows processes external to the application object manager to communicate with the latter.
Installing Siebel CRM is a complex endeavour that involves multiple professionals. In this chapter, we learned the fundamentals of the Siebel web architecture and how this infrastructure provides enterprise class applications to large end user audiences.
In this chapter, we named the building blocks that are needed to run Oracle's Siebel CRM applications.
In the next chapter, we will learn how to plan and prepare the installation of the Siebel CRM infrastructure.