As we learned in previous, a Siebel enterprise is a collection of Siebel servers that share the following characteristics:
In order to better understand the relationships between the Siebel Servers in an enterprise,their components and parameters, it is best to examine the Enterprise Explorer view in the Administration - Server Configuration screen in the Siebel Web Client.We can access that view by logging on to the Siebel Web Client using an administrative user account.Then, we navigate to the Site Map,select the Administration - Server Configuration screen and click the hyperlink for the Enterprise Explorer view.The following screenshot shows the partially expanded Siebel Enterprise Explorer tree applet in that view:
We can observe that a Siebel enterprise consists of the following:
Next, we will discuss each of these major building blocks of a Siebel Enterprise in more detail.
As we can confirm by examining the Enterprise Explorer tree,multiple Siebel servers can be members of a Siebel Enterprise. Each Siebel server has one or more component groups assigned, which results in a list of components that the server hosts.Furthermore, parameters and event log levels can be set at the server level.In the following sections of this chapter, we will discuss the configuration of Siebel servers in greater detail.
A component group is—as the name suggests—a collection of components.Grouping components allows for better manageability.The preconfigured Siebel enterprise for Siebel Industry Applications contains more than fifty component groups.The following screenshot shows the list of component groups for the selected enterprise:
We can click the Component Groups folder in the explorer tree to obtain the list as depicted.The components within a component group serve a common purpose,such as supporting the deployment of application configurations (Application Deployment Manager group) or assignment of data to users or organization (Assignment Manager group).Component groups are the vehicles that enable Siebel CRM functionality— implemented as components—on Siebel servers. Later in this chapter, we will learn how to assign and enable component groups on Siebel servers.
The following table describes the most important component groups—in alphabetical order—available in Siebel CRM version 8:
As we can see from the table above, there are many component groups that mainly hold the object manager components for specific Siebel applications while other groups enable cross-application functionality such as integration with external systems or reporting.The two system component groups (System Management and Auxiliary System Management) are enabled on each Siebel server by default and should never be disabled.
Each component, no matter what specific functionality it implements, is defined only once for the entire enterprise.The result of this is a very high level of reusability.Components can run multiple times on any server within the enterprise but they all inherit their parameter settings from an enterprise-wide template—the component definition.
In more technical terms, a component is a type of program with a specific set of parameters that can be instantiated on one or more servers in the enterprise.The core Siebel server technology is implemented in the C++ programming language.When the C++ code represented as.dll (dynamic link library) files on Microsoft Windows or so (shared object) files on Linux and other UNIX-based operating systems is executed, a task is instantiated on the Siebel server. The task is also visible as an operating system process or thread.
In order to examine the component definitions for a Siebel enterprise, we can use the Component Definitions view in the Administration - Server Configuration screen of the Siebel Web Client.The out-of-the-box configuration for a Siebel enterprise contains over one hundred component definitions, most of them language-specific.The following screenshot shows the Component Definitions view in the Administration - Server Configuration scree:
The view displays the list of component definitions for the current Siebel enterprise as well as the parameter definitions for the selected component definition. A component definition is specified by the following:
Next, we will discuss the component definition run modes and component types.
Component definition run modes
The run mode of a component definition drives the general behaviour of the server component.There are three run modes:
A background component is defined as a constantly running process which performs tasks that require regular attention. Examples of ypical Siebel background components are the various "EAI Receivers" that enable integration with other enterprise applications. We can imagine that if a Siebel application should be able to process incoming data at any given point in time, a receiver must be constantly listening for data sent by an external system.To avoid the component consuming too much CPU time while "waiting", a Sleep Time parameter controls the amount of time that the component remains in a "sleeping" state before "waking up" and doing the actual work.
Batch components are typically invoked by an administrator, an end-user initiated workflow, or by schedule. Each task for these components has a defined start time and only consumes CPU and memory of the host machine when it is active.Once the task is complete,the operating system process is finished as well. Examples for batch components are the Enterprise Integration Manager (EIM), which supports import, export, delete, and merge of mass data or the Database Extract component, which is used to extract the initial database snapshot for mobile clients.
Application object managers are the dominant example for interactive components.Their main purpose is to wait for incoming requests from either the end users or external systems and handle the request according to the metadata information in the Siebel repository file (.srf).
The component type property of a component definition defines both the base functionality of the component and the list of parameters for all components of that type.When we explore the list of component definitions for a Siebel enterprise we find. For example, dozens of component definitions that have a type of "Application Object Manager".Closer inspection of the parameters list for each of these component definitions reveals that they have the same parameters albeit with slightly different values.
The generic component types used to define the majority of components in a Siebel Enterprise are listed below:
Application Object Managers, as discussed above, serve as request handlers for end users or external systems.The main distinguishing parameters for application object managers are Application Name and Language Code.Components of the Business Service Manager type allow the Siebel server to execute code implemented as a so-called business service method as a component.The majority of Siebel functionality is implemented as business services. Developers can write custom business services to implement additional functionality. The Business Service Name and Method parameters distinguish component definitions of this type.
As discussed above, Enterprise Application Integration (EAI) Receivers are components that serve as listeners for incoming requests and data from external systems. Siebel CRM supports the following protocols for EAI message exchange:
Apart from the three component types discussed above, we can find many others that are, most of the time, specific for one component definition.These component definitions, such as the Siebel Connection Broker or other system-related components, use specialized code to implement their functionality.
Later in this, we will learn how to create additional component definitions, which will deepen our understanding of these major building blocks of Siebel server-side functionality.
Many parameters have the same value for all component definitions.Good examples for enterprise-wide parameters are Username and Password.They define the name and password of the database account that is used by Siebel processes to connect to the Siebel database When these parameters are defined on the enterprise level and are not changed at a lower level such as the server or component level, the value of each parameter is inherited by subordinate members of the hierarchy.
To view the list of parameters for the current enterprise, we can navigate to the Parameters view in the Administration - Server Configuration screen in the Siebel Web Client.The following screenshot shows the parameter list for the SIEBELEVAL enterprise:
The User Name parameter is selected and we can observe by its description that it denominates the database username for connections to the Siebel database.
Enterprise profiles are reusable collections of parameters. A good example is the ServerDataSrc profile which—very much like in a Siebel Developer client's configuration file—contains the information to allow the object manager to connect to the server database.We can investigate all enterprise profiles for a given Siebel enterprise by navigating to the Profile Configuration view of the Administration - Server Configuration screen in the Siebel Web Client, which is shown in the following screenshot:
The view displays all enterprise profile definitions for the selected enterprise. The Server Datasource profile is currently selected and a part of the list of parameters for this profile is visible.We can observe that the DB Connector DLL parameter has a value of sscdo90.A similar parameter (DLL)exists in the [ServerDataSrc] section in the Siebel Developer Web client's configuration file.The following screenshot shows the [Server DataSrc] section of the siebel.cfg file, which is the configuration file used for the Siebel Sales application:
We can observe by comparing the values of the DLL parameters that sections in client configuration files and enterprise profiles serve a similar purpose.Enterprise profiles are typically referenced by their alias name in server or component parameters.For example, the Call Center Object Manager component definition references the ServerDataSrc profile in its data source parameters.The following screenshot shows a portion of the Component Definitions view and the OM - Named Data Source name parameter for the Call Center Object Manager (ENU) component definition:
The value of this parameter is a comma-separated list of names of enterprise profiles that contain the connectivity information.All other application object manager definitions reference the same enterprise profile to obtain the connection information for the server database. Having to set connection parameter for the server database only in one place implements a high level of reusability.
Enterprise profiles are also known as "named subsystems", which is the term used in the Siebel Server Manager command line utility. The word "named" is an abbreviation for "name daemon" and refers to the Siebel Gateway Name Server service.
System alerts are a special type of enterprise profile. Similar to all other enterprise profiles, they are reusable collections of parameters. Their speciality lies within the purpose of defining a list of e-mail recipients—typically administrators—who need to be notified in case of an error situation on one of the servers.We can find a default system alert definition when we navigate to the System Alerts folder in the Enterprise Explorer view of the Administration - Server Configuration screen. System alerts can be referenced by specifying their name as the value of the Notification Handler parameter of the component definition.As a result, an e-mail will be sent to the recipients defined in the system alert profile when the component's tasks exit with an error.
Siebel enterprise hierarchy and parameter inheritance
As we have now discussed the major building blocks of a Siebel enterprise, we find that they are arranged in a specific hierarchy.This hierarchy also defines the inheritance of parameter values from higher levels to lower levels.The following diagram depicts the information available from the Enterprise Explorer view:
We can summarize our exploration of the Siebel enterprise structure as follows (using the numbers in the diagram):
When we observe and rearrange the different levels of parameters in the above diagram, we find the following chain of parameter value inheritance in a Siebel enterprise:
If a parameter with the same name exists in a lower level and has not been changed at that lower level, it inherits its value from the parameter in the upper level.If we change a parameter at a lower level,for example at the server component level, this is considered a parameter override.In that case, the chain of inheritance is broken and the parameter must now be managed on the level that it has been set on.
An administrator must therefore consider any changes to parameters very carefully.In general, setting parameter values at higher levels is recommended in order to avoid repetitive work at lower levels. If for any reason we wish to reestablish the chain of inheritance for a parameter, we must use the Delete Parameter Override command from the applet menu.The following screenshot shows the Notification Handler parameter at the server level:
The command Delete Parameter Override—visible in the screenshot in the context menu —can be used to delete the overridden value at the current level and reestablish inheritance of the parameter value from upper levels.On your demonstration system use the Administration - Server Configuration screen in the Siebel Web Client to verify the findings in the previous section.
Siebel - CRM Related Interview Questions
|Siebel - CRM Interview Questions||Siebel System Admin Interview Questions|
|Salesforce Admin Interview Questions||Salesforce Developer Interview Questions|
|Siebel EAI Interview Questions||Advanced jQuery Interview Questions|
|Cap Gemini Siebel CRM Interview Questions||Siebel EIM Interview Questions|
|AppleScript Interview Questions||Salesforce Crm Interview Questions|
|Windows Workflow Foundation Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.