2Siebel Architecture Overview
Siebel Architecture Overview
This chapter provides an overview of the architecture for Siebel CRM. It includes the following topics:
Building Blocks of a Siebel CRM Deployment
The following figure shows an example of the elements in a Siebel CRM deployment. A brief description of these elements appears in the following table to help you understand the Siebel CRM architecture.
The current release of Siebel CRM supports certain specific database and operating system platforms, as well as certain combinations of them. For a list of the operating systems and RDBMS products supported by the current release, see the Certifications tab on My Oracle Support.
The following table describes the major elements in a Siebel CRM deployment.
| Entity | Description |
|---|---|
Siebel Web Clients |
Includes the following client types:
For more information, see About Siebel Client Types. |
Siebel Application Interface. |
The Siebel Application Interface identifies requests for Siebel data and forwards them to the Siebel Servers. It receives data from Siebel Servers and helps format it into Web pages for Siebel clients. You install and configure the Siebel Application Interface as a separate module, located in the DMZ. (The DMZ or demilitarized zone is located behind an external firewall but outside of an internal firewall.) For more information, see About the Siebel Application Interface. |
Siebel Server load balancing |
Siebel Server load balancing is provided by Siebel Application Interface and Siebel Gateway working together. For more information, see About Siebel Server Load Balancing. |
Siebel Enterprise Server |
A logical grouping of Siebel Servers that connect to one database and that allows management of Siebel Servers as a group. The corresponding configuration entity is called the Siebel Enterprise. For more information, see About the Siebel Enterprise Server and the Siebel Server. |
Siebel Servers |
Application server software that provides both user services and batch mode services to Siebel clients or other components. For more information, see About the Siebel Enterprise Server and the Siebel Server. |
Siebel Gateway |
Stores configuration and status information for Siebel Enterprise, Siebel Server, Siebel Application Interface, Siebel Enterprise Cache, Siebel Constraint Server, and other components. For more information about Siebel Gateway, see About the Siebel Gateway.
Note: Siebel CRM supports an optional native clustering feature for Siebel Gateway to provide high availability benefits to Siebel CRM customers. This feature works at the software level and is the preferred and recommended approach for clustering the Siebel Gateway. For more information, see
Defining High Availability Policies.
|
Siebel database |
Stores database records. Includes third-party RDBMS software and Siebel tables, indexes, and seed data. Also includes the Siebel runtime repository. |
Siebel File System |
Shared file system directory or directories storing data and physical files used by Siebel clients and Siebel application components. For more information, see About the Siebel File System. |
Siebel CRM deployment |
All of the physical and logical elements required to deploy Siebel applications, including:
|
Siebel Enterprise Integration Management (EIM) Siebel Enterprise Application Integration (EAI) |
These modules allow importing and exporting of data from other databases to the Siebel database, and provide various other integration services. For more information, see About Siebel Enterprise Integration Manager and About Siebel Enterprise Application Integration. |
Siebel Tools Siebel Web Tools |
Siebel CRM provides two main development tools:
You use Siebel Tools to modify standard Siebel objects and create new objects to meet your organization’s business requirements. For example, you use Siebel Tools to extend the data model, modify business logic, and define the user interface.
Note: For more information about these programs, see
About Siebel Tools and Siebel Web Tools. See also
Using Siebel Tools.
|
About Siebel Client Types
This topic describes the Siebel client types. The term Siebel Web Client sometimes refers to all of the browser-based clients and sometimes refers to one specific client type, which is described in the following section. For information about Siebel Open UI, the user interface for all of the Siebel Web Client types, see About Siebel Open UI.
This topic contains the following information:
Siebel Web Client
The Siebel Web Client runs in a standard browser on the end user’s client computer. The browser connects through the Siebel Application Interface to the Siebel Server, which executes business logic and accesses data from the Siebel database. Only the user interface layer of the Siebel CRM architecture resides on the user’s computer.
This topic is part of About Siebel Client Types.
Other considerations about the Siebel Web Client are as follows:
Installed software. In general, no additional application software is required on the client. At minimum, the client requires only a Web browser.
Application connection. This is the connection through the Siebel Application Interface to the Siebel Server. Applications run on the Siebel Server and forward pages to the client. Applications display in a standard Web browser on the end user’s client computer, such as a connected laptop or desktop computer.
Database connection. This is the connection through the Siebel Server to the Siebel database. No Siebel database or database client is installed on the client.
For information about installing and setting up the server environment to support this client, see the Siebel Installation Guide for the operating system you are using and other documentation. See also the Certifications tab on My Oracle Support.
Siebel Mobile Web Client
The Siebel Mobile Web Client is like the Siebel Web Client except that it includes installable software and uses a local database that synchronizes with the Siebel database.
This topic is part of About Siebel Client Types.
The Siebel Mobile Web Client includes the following:
Installed software. Windows-based software containing Siebel applications and related services is installed on each client. The client also requires a Web browser.
Application connection. Applications run on each client. Applications display in a standard Web browser on the end user’s client computer, such as a laptop.
Database connection. A local database and a local Siebel File System are installed on each client. Applications access the local database.
Users periodically synchronize the local database and Siebel File System with a remote Siebel database and Siebel File System. Users synchronize data using components on the Siebel Server. Mobile users synchronize with the remote Siebel database and the Siebel File System without going through the Siebel Application Interface or any other Siebel Server component. The Siebel Remote (alias Remote) and Disconnected Mobile Synchronization (alias MobileSync) component groups must be enabled on the Siebel Server, among other requirements. The local database for Siebel Mobile Web Client uses Oracle Database SE2.
For information about installing the Siebel Mobile Web Client and the local database and about installing and setting up the server environment to support this client, see the Siebel Installation Guide for the operating system you are using. For information about setting up and synchronizing the local database, see Siebel Remote and Replication Manager Administration Guide. See also the Certifications tab on My Oracle Support.
Siebel Developer Web Client
The Siebel Developer Web Client is like the Siebel Mobile Web Client except that it connects with the Siebel database for the enterprise.
This topic is part of About Siebel Client Types.
The Siebel Developer Web Client includes the following:
Installed software. Windows-based software containing Siebel applications and related services is installed on each client. The client also requires a Web browser.
Application connection. Applications run on each client. Applications display in a standard Web browser on the end user’s client computer, such as a connected laptop or desktop computer.
Database connection. A direct connection to the Siebel database is required. Appropriate database client software must be installed on the client. This client can connect directly to the Siebel File System or connect to it through the File System Manager server component.
For information about installing the Siebel Developer Web Client and installing and setting up the server environment to support this client, see the Siebel Installation Guide for the operating system you are using. See also the Certifications tab on My Oracle Support.
Siebel Mobile Applications
The Siebel Mobile applications are a group of Siebel CRM applications that are accessed from a browser on a mobile device, such as a tablet or smart phone, where the browser connects through the Siebel Application Interface to an Application Object Manager component on a Siebel Server.
For Siebel Mobile disconnected applications, the Disconnected Mobile Synchronization component group (alias MobileSync) must be enabled on the Siebel Server, among other requirements.
This topic is part of About Siebel Client Types.
For more information about Siebel Mobile applications, see Siebel Mobile Guide: Connected and Siebel Mobile Guide: Disconnected. For information about setting up the server environment to support these applications, see the Siebel Installation Guide for the operating system you are using and other documentation. See also the Certifications tab on My Oracle Support.
About the Siebel Application Interface
The Siebel Application Interface serves as the Web server for Siebel CRM applications. The Siebel Application Interface identifies requests for Siebel application data coming from Web clients and flags these requests for routing to a Siebel Server. When information is sent from the Siebel Server back to the Web client, the Siebel Application Interface helps complete the composition of the Web page for forwarding to the client.
You can install and deploy multiple Siebel languages on a single Siebel Application Interface instance. The Siebel Server and the Siebel Application Interface do not have to be operated in the same language. However, the Siebel Server, the Siebel Application Interface, and all other server components must use the same character set. You install and configure the Application Interface as a separate module, located in the DMZ. (The DMZ or demilitarized zone is located behind an external firewall but outside of an internal firewall.)
The Siebel Application Interface and Siebel Gateway work together to provide Siebel Server load balancing. When a user requests a new application connection, Siebel Application Interface sends a request to Siebel Gateway, which returns a connect string for the least-loaded Application Object Manager from among the Siebel Servers supporting that component. The user session will use this Application Object Manager.
For information about installing and configuring the Siebel Application Interface and about deploying Siebel languages, see the Siebel Installation Guide for the operating system you are using and Siebel Global Deployment Guide.
About the Siebel Enterprise Server and the Siebel Server
This topic describes the Siebel Enterprise Server and Siebel Server, and also the Application Object Manager components of the Siebel Server.
For information about applicable installation and configuration tasks, see the Siebel Installation Guide for the operating system you are using.
This topic includes the following information:
Siebel Enterprise Server
The Siebel Enterprise Server is a logical grouping of one or more Siebel Servers that connect to one Siebel database. The corresponding configurable entity is called the Siebel Enterprise. You can configure some server parameters at the enterprise level. Such parameters are inherited by individual Siebel Servers and applicable components. Some parameters can be overridden at the server level or component level.
You use the Siebel Enterprise Server installer for installing Siebel Gateway, Siebel Server, Siebel Database Configuration Utilities, Siebel EAI Connectors, and Siebel Application Interface. You use the same installer for installing Enterprise Cache and Constraint Engine.
After the initial configuration of the Siebel CRM deployment, using the Siebel Management Console, some subsequent configuration and administration tasks for Siebel Enterprise, Siebel Server, and server components might be performed by one or more administrators using Siebel Server Manager. Server Manager supports both a command-line user interface and a graphical user interface (GUI).
This topic is part of About the Siebel Enterprise Server and the Siebel Server.
Siebel Server
Each Siebel Server functions as an application server and is composed of server components. Each server component performs a defined function. Server components or groups of components determine which applications and services a Siebel Server supports. Components run in one of several modes:
Interactive mode. Interactive mode components start tasks automatically in response to user requests. Interactive tasks run until the user ends the session. Examples of interactive components include the Application Object Managers (alias, for example, SCCObjMgr_deu for Siebel Call Center for German) and the Synchronization Manager (alias SynchMgr).
Background mode. Background mode components handle background processing tasks. Typically, background tasks are called by interactive tasks. Background tasks run until they are explicitly shut down. Examples of background components include Transaction Router (alias TxnRoute) and Workflow Monitor Agent (alias WorkMon).
Batch mode. Batch mode components handle processing of asynchronous work requests. When the task is complete, the component exits. Examples of batch components are Database Extract (alias DbXtract) and Enterprise Integration Mgr (alias EIM).
Many of the Siebel Server components can operate on multiple Siebel Servers simultaneously, allowing Siebel applications to scale across many computers to support large numbers of users.
Other Siebel Server components provide additional functionality, including the following:
Synchronization for Siebel Mobile Web Clients and Siebel Mobile disconnected applications
Integration with legacy or third-party data
Automatic assignment of new accounts, opportunities, service requests, and other records
Workflow management
Document generation
This topic is part of About the Siebel Enterprise Server and the Siebel Server.
Siebel Connection Broker (SCBroker)
The Siebel Connection Broker component provides load balancing of connection requests to multiple Application Object Manager threads or processes running on the same Siebel Server.
Siebel Server Implementation
The Siebel Server runs as a system service under Windows and as a process under UNIX. This system service or process monitors and controls the state of all of the server components on that Siebel Server. Each Siebel Server is one instantiation of the Siebel Server system service or process within the current Siebel Enterprise Server.
Interactive and batch components can be configured to run as multiple processes or in some cases as multithreaded processes. Application Object Manager components (which are interactive) can run as multiple processes and as multiple threads for each process. Background mode components can run as multiple processes only.
For information about administering the Siebel Server system service or process, see Siebel System Administration Guide.
Language Pack Installation
It is strongly recommended to install the same set of languages on each server computer in your Siebel Enterprise Server. However, you can deploy different languages on different Siebel Servers, as needed. For more information, see the Siebel Installation Guide for the operating system you are using. See also Siebel Global Deployment Guide.
Application Object Manager
One of the most important types of server components is the Application Object Manager. These server components always run in interactive mode. They process user requests and are application- or service-specific. For example, the Siebel Call Center component group contains the Call Center Object Manager (alias SCCObjMgr_deu for German, for example), one for each language deployed on the Siebel Server. This Application Object Manager provides the session environment in which this application runs.
Internally, each Application Object Manager also contains a data manager and the Siebel Web Engine. When an Application Object Manager receives a user request to start an application, it follows this procedure:
The business object layer starts an application user session, processes any required business logic, and sends a data request to the data manager.
The data manager creates an SQL query and forwards it the Siebel database.
The data manager receives the data from the database and forwards it to the business object layer for additional processing.
The business object layer forwards the result to the Siebel Web Engine, which helps create the user interface for the data. The Siebel Web Engine then forwards the Web pages to the Siebel Application Interface.
This topic is part of About the Siebel Enterprise Server and the Siebel Server.
Application Object Manager Implementation
An Application Object Manager server component is implemented as a multithreaded process on the Siebel Server. At run time, a parent process starts one or more Application Object Managers as multithreaded processes, according to the Application Object Manager configuration. The terms multithreaded server or MT server are alternative terms for the multithreaded process, which is also called an Application Object Manager process.
Each thread in an Application Object Manager hosts tasks that are typically linked to one user session. These threads might be dedicated to particular user sessions, or they might serve as a pool that can be shared by user sessions. For each Application Object Manager, a few threads are dedicated to housekeeping functions.
Each Application Object Manager task communicates with the Siebel database, the Siebel Application Interface, or other components, as follows:
Communication with the Siebel database uses ODBC database connections. You can manage and tune database connections for optimal performance. You can optionally configure connection sharing for database connections.
Communication with the Siebel Application Interface uses SISNAPI (Siebel Internet Session API), a Siebel messaging format that runs on top of the TCP/IP protocol. SISNAPI connections use encryption and authentication based on Transport Layer Security (TLS).
Communication with other Siebel Enterprise Server components (including other Siebel Servers) also uses SISNAPI.
The Siebel Connection Broker (SCBroker) on each Siebel Server listens on a static, configurable TCP port for requests coming from the Siebel Application Interface. SCBroker forwards these requests to Application Object Manager processes.
For more information about the operation of multithreaded processes for Application Object Manager components, see Siebel System Administration Guide and Siebel Performance Tuning Guide.
About the Siebel Gateway
The Siebel Gateway provides the dynamic address registry for Siebel Servers and server components, and also for Siebel Application Interface and other modules, like Siebel Enterprise Cache and Siebel Constraint Engine. For example, at startup, Siebel Server within the Siebel Enterprise Server stores its network address in the Siebel Gateway’s nonpersistent address registry.
Siebel Enterprise Server components query the Siebel Gateway registry for Siebel Server availability and address information. When a Siebel Server shuts down, this information is cleared from the registry.
The Siebel Application Interface and Siebel Gateway work together to provide Siebel Server load balancing. When a user requests a new application connection, Siebel Application Interface sends a request to Siebel Gateway, which returns a connect string for the least-loaded Application Object Manager from among the Siebel Servers supporting that component. The user session will use this Application Object Manager.
The Siebel Gateway also includes persistent storage in the registry for configuration information for Siebel Server, Siebel Application Interface, and other installable components. This information includes:
Definitions and assignments of component groups and components
Operational parameters
Connectivity information
As this configuration information changes, such as during the configuration of Siebel Enterprise, a Siebel Server, or a Siebel Application Interface, this data is written to the Siebel Gateway registry.
There can be only one Siebel Gateway, or one Siebel Gateway cluster, installed and configured for each environment in which you have created a Siebel Enterprise. Further, you cannot share the same Siebel Gateway across development, test, and production environments.
Siebel CRM supports an optional native clustering feature for Siebel Gateway, to provide high availability benefits to Siebel CRM customers. This feature works at the software level and is the preferred and recommended approach for clustering the Siebel Gateway. For more information, see Defining High Availability Policies.
For information about installation and configuration tasks associated with Siebel Gateway, see the Siebel Installation Guide for the operating system you are using.
It is strongly recommended to install the same set of languages on each server computer in your Siebel Enterprise Server. For more information, see the Siebel Installation Guide for the operating system you are using. See also Siebel Global Deployment Guide.
Related Topics
Related Books
Siebel Installation Guide for the operating system you are using
Siebel Global Deployment Guide
About the Siebel File System
The Siebel File System is a shared file system directory or set of directories. The Siebel File System stores document files, Siebel Product Configurator models, and other files that are not suitable for database storage. Siebel CRM provides roles and responsibilities to control access to these files. System user preferences are stored in the userpref subdirectory of the Siebel File System.
For information about setting up and maintaining the Siebel File System, see the Siebel Installation Guide for the operating system you are using and Siebel System Administration Guide.
Siebel File System Recommendations
The following list provides recommendations for dealing with the Siebel File System:
All of the Siebel Servers must have direct access to the Siebel File System. The only exception to this rule is when a server computer is running a Siebel Document Server only. If the File System Manager server component (alias FSMSrvr) is disabled on the Siebel Document Server, then it accesses the Siebel File System through the FSMSrvr on another Siebel Server. In all other cases, the Siebel Server must be able to directly access the Siebel File System.
The Siebel File System can be configured to use multiple directories that exist on separate devices or partitions. Before you configure the Siebel Enterprise, at least one file system directory must exist that you can designate for use by the Siebel File System.
There are few strict rules for deploying the Siebel File System. Theoretically, the file system can be hosted on any of the server computers in the Siebel Enterprise Server or on computers in an independent file server farm. For small-to-medium deployments, a common scenario might be to place the Siebel File System on the Siebel Gateway computer. Implementations with a large number of attachments might need a dedicated file system computer. Consider using a high-speed RAID disk storage system to increase file system throughput.
It is strongly recommended that you disable short file-name generation on Windows servers hosting the Siebel File System, because this type of file-naming can cause severe performance impacts once the file system grows to a large size.
During normal operation of Siebel CRM software, it is likely that orphaned files are stored in the Siebel File System and that orphaned records exist in the Siebel database. Periodically run the
sfscleanuputility to remove orphaned files from the Siebel File System. This utility is located in thebinsubdirectory within the Siebel Server root directory. For information about using this utility, see Siebel System Administration Guide.
About Siebel Server Load Balancing
Load balancing distributes workload across multiple Siebel Server computers. Each Siebel Server runs an instance of the service that you want to load balance. Load balancing also provides failover. If one Siebel Server fails, then requests are automatically routed to the remaining Siebel Servers.
The Siebel Gateway and Siebel Application Interface work together to provide Siebel Server load balancing. When a user requests a new application connection, Siebel Application Interface sends a request to Siebel Gateway, which returns a connect string for the least-loaded Application Object Manager from among the Siebel Servers supporting that component. The user session will use this Application Object Manager.
You can use load balancing when the Siebel Enterprise Server has two or more Siebel Servers that are not clustered. Load balancing is the preferred method for providing high availability for the following server components:
Application Object Managers
Siebel Product Configurator (uses own load balancing method)
Siebel EAI (whenever possible)
On each Siebel Server, Siebel Connection Broker (SCBroker) provides intraserver load balancing. SCBroker distributes connection requests across multiple instances of Application Object Manager processes running on the same server computer. For more information, see About the Siebel Connection Broker.
Siebel CRM also supports load balancing across multiple installed instances of Siebel Application Interface. For more information, see Recommendations for High Availability Deployments.
About Siebel Internet Session Network API
Siebel Internet Session Network API (SISNAPI) is a Siebel proprietary message-body format running on top of TCP/IP. SISNAPI is used for communications between the Siebel Application Interface, Siebel Gateway, and Siebel Servers.
When the Siebel Application Interface receives a client request, it forwards it in SISNAPI format. The SISNAPI message-body format has the following parts:
HTTP header
Object Manager method name
Method arguments as key-value pairs
For information about user request types, see About User Request Types.
HTTP Header
When the Siebel Application Interface requests a new connection, the initial packets of the first SISNAPI message contain an HTTP header. This header includes a Uniform Resource Locator (URL) that provides routing information to the Siebel Enterprise Server, Siebel Server, and server component.
Connection Multiplexing
SISNAPI TCP/IP connections are specific to an Application Object Manager on one Siebel Server. Before a new connection is opened, the Application Object Manager checks to see whether an existing connection is available. If so, then an existing connection is used. Once the connection is established, it remains open to be used by subsequent messages in the session or to be reused by other sessions. For more information about connection multiplexing, see Siebel Performance Tuning Guide.
Transport Layer Security (TLS)
SISNAPI connections use Transport Layer Security (TLS) for encryption and authentication. For more information, see Siebel Security Guide. See also the Siebel Installation Guide for the operating system you are using.
User Request Types
The Siebel Application Interface generates three types of user requests. Each request type creates a new connection to a Siebel Server through the load balancer: initial request, retry request, and reconnect request. The Siebel native load balancing functionality is able to recognize and route these request types.
Initial request. The Siebel Application Interface generates this request to start a new user session as follows:
The Siebel Application Interface receives the request to start a user session.
The Siebel Application Interface creates the message. The HTTP header specifies the Siebel Enterprise Server and the desired server component. The message does not specify a Siebel Server name.
The Siebel Application Interface sends the request message to Siebel Gateway.
The Siebel Gateway returns a connect string for a suitable component: the least-loaded Application Object Manager running on one of the Siebel Servers that support that component.
The Siebel Application Interface in turn routes the request to the Siebel Server where this Application Object Manager is running. If no connection exists to the Siebel Server, then a new one is created.
The Siebel Server receives the message and creates a new user session. The Siebel Server forwards address information back to the Siebel Application Interface.
The Siebel Application Interface creates a cookie containing the address information. The Siebel Application Interface receives the cookie information in subsequent session requests. The Siebel Application Interface includes this information in the HTTP header.
The load balancer receives subsequent messages and forwards them directly to the specified Siebel Server and server component through the open connection.
Retry request. If a Siebel Server rejects an initial request, then the request is routed back to the Siebel Application Interface and the following occurs:
The Siebel Application Interface modifies the URL contained in the HTTP header by appending the letters RR to it.
The Siebel Application Interface resends the request to the Siebel Gateway for a suitable component on a different Siebel Server.
Reconnect request. Siebel Application Interface generates a reconnect request when it receives a user request for an existing user session that does not have a SISNAPI connection. The Siebel Application Interface uses the session cookie information to include the Siebel Server address in the HTTP header.
The reconnect request opens a new connection. Reconnect requests can occur for several reasons:
The SISNAPI connection was opened by Application Interface 1, but load balancing routes subsequent session messages to Application Interface 2, which does not have an existing connection.
The connection timeout is exceeded and the connection is closed.
The network environment closes the connection, for example due to a firewall time-out.
About the Siebel Connection Broker
The Siebel Connection Broker (SCBroker) server component provides intraserver load balancing. SCBroker distributes server requests across multiple Application Object Manager processes running on a Siebel Server.
SCBroker listens on a configurable, static port for new requests. When a new request is received, it forwards the request to the Application Object Manager process with the least number of running tasks, or forwards the request to another Application Object Manager process in round-robin fashion. A user session is created on this Application Object Manager. Thereafter, the requests that apply to this session are directly sent to the Application Object Manager process hosting the session.
SCBroker is enabled by default and has several parameters:
PortNumber. Sets the port number on which SCBroker listens. The default is 2321, but you can change the port number.
DfltTasks. Sets the default number of processes for SCBroker. The recommended value is 2.
MaxTasks. Sets the maximum number of processes for SCBroker. The recommended value is 2. This value cannot be less than DfltTasks.
AutoRestart. Default is On. If SCBroker terminates abnormally, then this setting allows it to restart automatically. Setting this parameter to Off or False is not recommended.
ConnForwardAlgorithm. The connection forwarding algorithm is the routing scheme for SCBroker to use when routing intraserver requests to Application Object Manager processes. Possible values are LL (least-loaded) and RR (round-robin). SCBroker uses the least-loaded algorithm by default.
LL. The least-loaded algorithm (default behavior) balances incoming Application Object Manager login requests. It identifies which Application Object Manager process is handling the least number of tasks and assigns that process to handle the session. If SCBroker determines that an Application Object Manager process is not responding to a request, then it sends subsequent requests to the next available Application Object Manager process (using least-loaded algortihm).
RR. The round-robin algorithm distributes all of the Application Object Manager login requests to the next Application Object Manager process in a round-robin fashion, that is, equal loads distributed in order and without priority. If SCBroker determines that an Application Object Manager process is not responding to a request, then it sends subsequent requests to the next available Application Object Manager process (using round-robin algortihm).
For more information about the ConnForwardAlgorithm parameter, see the information that follows this list of parameters.
ConnForwardTimeout. The connection forward time-out determines how long SCBroker waits for an Application Object Manager process to accept a request. The default is 500 milliseconds. This time-out minimizes wait time when SCBroker forwards a connection request to an Application Object Manager process and the request cannot be accepted. If a time-out occurs, then SCBroker reports an error back to the Siebel Application Interface.
ConnRequestTimeout. The connection request time-out determines how long SCBroker waits for all of the packets in an incoming new request. The default is 500 milliseconds. This time-out minimizes SCBroker wait time when TCP/IP requests are incomplete. If a time-out occurs, then the request is sent back to the Siebel Application Interface.
More Information about the ConnForwardAlgorithm Parameter
As noted, you can use the ConnForwardAlgorithm parameter to specify either least-loaded or round-robin routing. The round-robin routing scheme does not take into account the number of running tasks for each Application Object Manager process. It simply forwards each request to the next Application Object Manager process among the available processes. The least-loaded algorithm considers only the current number of tasks for each Application Object Manager process that is running.
The Siebel Gateway provides the connect string for the Siebel Application Interface to use for sending each request to an Application Object Manager process. If Siebel Gateway fails to provide a connect string, then Siebel Application Interface resends the request to the Siebel Gateway up to five times, with five seconds between each request.
In many circumstances, how an individual connection request is forwarded might be the same for either forwarding algorithm. The actual forwarding behavior depends on these factors:
The setting of the ConnForwardAlgorithm parameter for SCBroker.
-
The settings of the ConnForwardTimeout and ConnRequestTimeout parameters for SCBroker.
-
The current number of Application Object Manager processes.
The current number of tasks for the Application Object Manager component and for each Application Object Manager process.
Patterns of requests for new tasks and patterns of threads being freed up through logouts.
Application Object Manager parameter settings controlling the maximum number of tasks and the minimum and maximum number of Application Object Manager processes. The applicable parameters are:
Maximum Tasks (MaxTasks)
Minimum MT Servers (MinMTServers)
Maximum MT Servers (MaxMTServers)
For information about calculating the settings for MaxTasks, MaxMTServers and MinMTServers, see Siebel Performance Tuning Guide.
Sometimes an individual connection request is not forwarded to an existing Application Object Manager process but instead causes a new Application Object Manager process to start. This can occur with either forwarding algorithm, when each existing Application Object Manager process has reached its theoretical maximum number of tasks, based on dividing the maximum number of tasks by the maximum number of Application Object Manager processes. A new process starts only if the maximum number of tasks and the maximum number of Application Object Manager processes have not yet been reached.
For more information about applicable parameters, see also Siebel System Administration Guide and Siebel Performance Tuning Guide.
About the Server Request Broker
The Server Request Broker (SRBroker) server component processes both synchronous and asynchronous server requests.
Synchronous server requests are requests that must be run immediately, and for which the calling process waits for completion.
Asynchronous server requests are requests for which the calling process does not wait for completion.
SRBroker can run server requests on any Siebel Server in the Siebel Enterprise. For example, if SRBroker is unable to run a server request on the local Siebel Server because the required component is not enabled, then SRBroker finds another Siebel Server that is hosting the required component and runs it there. SRBroker runs by default on all of the Siebel Servers.
SRBroker decides where to run a server request using the following criteria:
If the required component is available locally, then SRBroker runs the task locally.
If the required component is not available locally, then SRBroker identifies any Siebel Servers in the same Enterprise that have the component online. Server requests are submitted to each of these Siebel Servers in turn (a round-robin algorithm).
If the required component is not available anywhere in the Enterprise, then the server request fails.
The SRBroker component helps provide resilient processing. As long as the required component is running on a Siebel Server somewhere in the Enterprise, then the server request can be processed. For more information about resilient processing, see About Resilient Processing.
About the Server Request Processor
The Server Request Processor (SRProc) server component processes asynchronous, server-initiated requests. These are requests that are submitted for later execution and that do not require the calling process to wait for the request to complete.
SRProc runs by default on all of the Siebel Servers. When asynchronous requests are submitted, they are stored in the Siebel database in the S_SRM_REQUEST table. SRProc periodically checks this table for any requests that are eligible to be run. For a request to be eligible, it must meet all of the following criteria:
The request must be in the correct state (Queued)
Its start time must have passed
The target Siebel Server must not be specified or must be the Siebel Server where the requested component is running
If a request is eligible, then SRProc invokes Server Request Broker (SRBroker) to run the request, as described in About the Server Request Broker. Therefore, as long as a target Siebel Server is not specified, asynchronous requests are read by any SRProc task on any Siebel Server.
The SRProc component helps provide resilient processing for server-initiated tasks. As long as an SRProc task is running somewhere in the Siebel Enterprise, the request is processed. For more information about resilient processing, see About Resilient Processing.
About Siebel Enterprise Application Integration
Siebel Enterprise Application Integration (EAI) provides components for integrating Siebel CRM with external applications and technologies. It is designed to work with third-party solutions such as those from IBM, CrossWorlds, TIBCO, Vitria, SeeBeyond, webMethods, and others.
Siebel EAI provides bidirectional real-time and batch solutions for integrating Siebel applications with other applications.
Siebel EAI is designed as a set of interfaces that interact with each other and with other components within the Siebel application. These interfaces are compatible with IBM MQSeries, Microsoft MSMQ, Java and Java EE, XML, HTTP, and many other standards.
Siebel EAI interfaces do the following:
Allow a flexible service-based architecture built on top of configurable messages using XML and other formats.
Expose internal Siebel objects to external applications
Take advantage of prebuilt adapters and enterprise connectors, and are compatible with third-party adapters and connectors.
Allow for data transformation.
Integrate external data through virtual business components (VBCs).
Provide a graphical business process designer, programmatic interfaces, and a high-volume batch interface.
For more information about Siebel EAI, see Overview: Siebel Enterprise Application Integration and other applicable documentation on Siebel Bookshelf.
About Siebel Enterprise Integration Manager
Siebel Enterprise Integration Manager (EIM) manages the bidirectional exchange of data between the Siebel database and other corporate databases. This exchange is accomplished through intermediary tables called EIM tables. The EIM tables act as a staging area between the Siebel database and other databases.
You must use Siebel EIM to perform bulk imports, exports, updates, and deletes. Using native SQL to load data directly into Siebel base tables (the tables targeted to receive the data) is not supported.
For more information about Siebel EIM, see Siebel Enterprise Integration Manager Administration Guide.
About Siebel Tools and Siebel Web Tools
Siebel CRM provides two main development tools:
Siebel Tools is a Windows-based, integrated environment for configuring Siebel applications.
Siebel Web Tools is an Application Object Manager component that provides similar functionality through the Siebel Web Client. Most of the information provided about Siebel Tools also applies to Siebel Web Tools.
You use Siebel Tools to modify standard Siebel objects and create new objects to meet your organization’s business requirements. For example, you use Siebel Tools to extend the data model, modify business logic, and define the user interface. Siebel Tools is also a way to integrate programs written using Siebel scripting languages.
A standard Siebel application provides a core set of object definitions that you can use as a basis for your own tailored application. Siebel Tools object definitions are grouped into four layers, each with a different purpose:
Physical user interface (UI) layer. Templates and tags that render the user interface in the client.
Logical user interface objects layer. Presentation of data (user interface).
Business objects layer. Objects that extract defined information from the database or provide a defined service.
Data objects layer. Database interface objects and table definitions.
Object types in a given layer depend on definitions in the next lower layer, and are insulated from other layers in the structure. You can make certain kinds of changes to a Siebel application without changing the underlying database structure. Similarly, you can extend the Siebel database schema without affecting the Siebel application. In many cases, configuration changes are made in concert across multiple layers in order to achieve the desired business functionality.
As of Siebel CRM 17.0, Siebel CRM applications use the Siebel runtime repository in the Siebel database.
For information about using Siebel Tools and Siebel Web Tools, see Using Siebel Tools, Configuring Siebel Business Applications, and other guides. For Siebel Tools installation instructions, see the Siebel Installation Guide for the operating system you are using.
Many aspects of the physical user interface can also be configured outside of Siebel Tools. For more information, see Configuring Siebel Open UI.
Example of User Request Flow in a Siebel CRM Deployment
The following figure illustrates how a user request is processed within the Siebel CRM architecture. In the diagram, there are two types of load balancing:
Siebel Application Interface load balancing. Web client requests can be forwarded to different instances of Siebel Application Interface. This type of load balancing is also called Web server load balancing.
Siebel Server load balancing. Siebel Application Interface and Siebel Gateway work together to distribute user requests to multiple Siebel Servers.
A typical Siebel client request flows from the user’s Siebel Web Client through the system components for Siebel CRM applications and back again, according to the following general flow:
A user performs an action that initiates a request. For example, the user clicks a link in the Site Map to navigate to a particular view. The request is generated by the Web browser and Siebel Web Client framework.
The request goes through the network, using an existing or new HTTP connection. The request might go through a network router, proxy server, cache engine, or other mechanism.
The Web server load balancer, if present, evaluates the request, determines the best Siebel Application Interface to receive the request, and then forwards the request to the Siebel Application Interface.
The Siebel Application Interface receives the HTTP request and determines that it is a Siebel application request.
The Siebel Application Interface parses the HTTP message and generates a SISNAPI message, based on the content of the HTTP message. The Siebel Application Interface also parses the incoming cookie to obtain the user session ID. The Siebel Application Interface forwards the request to a Siebel Server on a least-loaded basis.
Note: Siebel CRM applications require session cookies and do not support cookieless mode.On the Siebel Server, an Application Object Manager (AOM) receives and processes the SISNAPI message. If a database query is needed to retrieve the information, then the Application Object Manager formulates the SQL statement and sends the request to the Siebel database over a database connection.
The database request uses a protocol format that is specific to the database connector.
The database executes the SQL statement and returns data back to the Application Object Manager. The Application Object Manager forwards the message to the Siebel Application Interface that originated it.
The Siebel Application Interface receives the SISNAPI message and translates it back to HTTP. The message is now in the form of Web page content.
The Siebel Application Interface forwards the Web page content through the original HTTP connection to the end user’s Web browser.
The Web browser and the Siebel Web Client framework process the return message and display it to the end user.
About Siebel Open UI
Siebel CRM applications use Siebel Open UI. Siebel Open UI provides a rich user interface experience and is based on browser standards supported by recent versions of several browsers.
For more information about configuring and deploying Siebel CRM applications with Siebel Open UI, see the following related documentation:
Applications previously deployed using high interactivity now use Siebel Open UI. Many applications previously deployed using standard interactivity have been updated to use Siebel Open UI, while others might no longer work. Migrate your users to supported employee and customer applications, as appropriate. For more information, see Siebel Installation Guide for the operating system you are using and other relevant documentation.
For information about deploying Siebel CRM applications for your Web clients, see Deploying Siebel Open UI.
For information about configuring Siebel Open UI features for Siebel CRM applications, see Configuring Siebel Open UI.
For information about using Siebel CRM applications, see Siebel Fundamentals Guide.
For information about the functionality that is available for Siebel Open UI, see Siebel Open UI Deployment Guide on My Oracle Support (Article ID 1499842.1).
For the minimum browser standards for Siebel Open UI, see the Certifications tab on My Oracle Support.