| Siebel CRM System Administration Guide Siebel Innovation Pack 2015, Rev. A E24823-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM System Administration Guide Siebel Innovation Pack 2015, Rev. A E24823-01 |
|
Previous |
Next |
View PDF |
The various programs that operate on the Siebel Server are implemented as components. A component represents only a specific type of program. A component is executed or operated as a task, or instantiation of a component, on a specific Siebel Server. This topic includes the following information:
Components execute tasks in one of three run modes, background, batch, or interactive:
Background-mode components. Background-mode components execute tasks to perform background operations for the Siebel Server. After a background mode component task starts, it runs until you explicitly stop the task, or until the Siebel Server itself is shut down.
You can manually start a background mode component by using the Siebel Server Manager. Components with a Default Tasks parameter set to a value greater than zero might start automatically when the Siebel Server is started. Examples of background mode components include Transaction Router, Replication Agent, and Workflow Monitor Agent.
Batch mode-components. You must manually start these components by using the component job process in the Server Manager GUI or by the Server Manager command-line interface. Batch-mode components end after the task has been performed. Examples of batch mode components include Database Extract and Enterprise Integration Manager.
Interactive-mode components. Interactive-mode components start tasks automatically in response to client requests. Interactive mode component tasks execute for as long as the client maintains the session, and end when the client disconnects. Examples of interactive mode components include Synchronization Manager and Application Object Managers.
For a list of Siebel Server components and their associated run modes, see "Siebel Server Components".
Siebel Server supports multiple component types. Each type performs a specific function or job. A component type is configured with a set of parameters that determine its behavior to create an entity called a defined component (or component). Components are defined at the Siebel Enterprise Server level in component groups. Component groups are then assigned to one or more Siebel Servers within the Siebel Enterprise Server on which they can execute tasks.
When the Siebel Server is installed and initially configured, predefined components are automatically configured for each component type. These predefined components are then automatically assigned to each Siebel Server within the Siebel Enterprise Server. You can run your entire Siebel Business Applications deployment by using these predefined components, or you can modify their definitions and create new defined components to fine-tune your Siebel configuration. For a list of predefined Siebel Server components, see "Siebel Server Components".
The defined components feature allows you to create multiple defined components for a given component type, simplifying the process of starting various types of tasks that use different parameters, and managing components across multiple Siebel Servers.
For example, you might create one defined component for an Application Object Manager for the Siebel Sales application in U.S. English, and another for an Application Object Manager for the Siebel Service application in French. Although these defined components use the same component type, they service distinct sets of users with different functionality requirements, and are distinct entities that can be individually managed, configured, and administered. Defined components are configured in the Enterprise Component Definitions view of the Server Manager GUI.
|
Note: For the remainder of this guide, the term component refers to both predefined components and defined components that you might create or modify. |
Component groups are functional areas that involve logical groupings of Siebel Server components and multiple operating system processes. A component group consists of one or more components, which might be running in one or more operating system processes. Component groups act as:
The unit of deployment on, or assignment to, a Siebel Server. In general, you include in a Siebel Server the group of components that are deployed on one or more servers.
A unit for monitoring functionality of the interrelated components within the group (you can get a summary of the operational status at the component group status, which is determined by the individual states of the constituent components).
A unit of control, whereby you can make available or unavailable the interrelated components in a single step, such as Siebel Remote or Workflow Management.
Siebel Business Applications provide several predefined component groups. For a list of the components contained within each component group, see "Siebel Server Component Groups". For information about creating your own component groups, see "Creating a Custom Siebel Server Component Group".
The Siebel Server runs each component in its own separate process (or shell). These shells provide the interface for a component to communicate with shared memory, and use infrastructure facilities for logging, events, networking, and so on.
A shell performs the following actions when it is forked off:
Initializes the logging and networking facility.
Determines which component to run. The component is specified as a DLL (personality DLL), which is run by the Siebel Server either as part of the input parameters or as part of a network message.
Attaches to shared memory.
The Siebel Server forks off an appropriate shell based on the component mode (interactive, batch, or background) and whether the component is object manager-based, multithreaded, or both. The tables in this topic identify the shell types created in various scenarios for interactive-mode, batch-mode, and background-mode components.
|
Note: To conserve system resources and minimize the number of processes running on the Siebel Server, disable the component groups that you do not plan to run. If you cannot disable a component group because you require components within the group, then you can set other components within the group that you do not require to Manual Start mode. For information about disabling component groups, see "Unassigning Component Groups on a Siebel Server". For information about setting a component to start manually, see "About Starting Siebel Server Components". |
Table 2-2 identifies the shell types created for interactive-mode components.
Table 2-3 identifies the shell types created for batch-mode components.
Table 2-4 identifies the shell types created for background-mode components.
The following are examples of shells for Siebel Server components:
A background component that is not object manager-based is brought up in a siebproc shell. For example, Transaction Processor (alias TxnProc).
An interactive component that is multithreaded and not object manager-based is brought up in a siebmtsh shell. For example, Server Request Broker (alias SRBroker).
A multithreaded, object manager-based component is brought up in a siebmtshmw shell. For example, Call Center Object Manager for U.S. English (Call Center Object Manager (ENU), alias SCCObjMgr_enu).
The following parameters configure shell (process) startup for interactive, batch, and background mode components:
Maximum MT Servers (alias MaxMTServers)
Minimum MT Servers (alias MinMTServers)
Maximum Tasks (alias MaxTasks)
Default Tasks (alias DfltTasks)
For more information about configuring these parameters, see "Siebel Enterprise, Server, and Component Parameters" and "Application Object Manager Parameters in Server Manager".
To review information about the shells forked off by the Siebel Server, access the Siebel Server log file. For information about viewing Siebel Server log files, see Siebel System Monitoring and Diagnostics Guide.
