Understanding servers, components, and parameters - Siebel - CRM

As we learned in previous, a Siebel enterprise is a collection of Siebel servers that share the following characteristics:

  • Their configurations are stored by the same Siebel Gateway Name Server
  • They connect to the same Siebel database and file system

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:

Figure

partially expanded Siebel Enterprise Explorer tree applet in that view

We can observe that a Siebel enterprise consists of the following:

  • Servers
  • Component groups
  • Component definitions
  • Enterprise parameters
  • System alerts
  • Enterprise profiles

Next, we will discuss each of these major building blocks of a Siebel Enterprise in more detail.

Servers

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.

Component groups

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:

Figure

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:

Table

most important component groups—in alphabetical order—available in Siebel CRM version 8

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.

Component definitions

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:

Figure

Component Definitions view in the Administration

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:

  • A unique name and alias (short name)
  • Run mode
  • Component group membership
  • Component type
  • List of parameters that define the behavior of the component

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:

  • Background
  • Batch
  • Interactive

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).

Component types

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 Manager
  • Business Service Manager
  • Enterprise Application Integration Receiver

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:

  • MQ (IBM Websphere Message Queuing)
  • MSMQ (Microsoft Message Queuing)
  • JMS (Java Message Service)
  • HTTP (Hypertext Transfer Protocol)
  • File
  • SOAP (Simple Object Access Protocol)

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.

Enterprise parameters

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:

Figure

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

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:

Figure

Server Configuration screen in the Siebel Web Client

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:

Figure

[Server DataSrc] section of the siebel.cfg file

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:

Figure

portion of the Component Definitions view and the OM - Named Data Source name

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

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:

Figure

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):

  1. A Siebel enterprise contains one or more Siebel servers.
  2. More than 50 default component groups are part of a freshly installed Siebel enterprise.
  3. Each component group contains one or more component definitions. Component definitions also define the parameterization of server processes at the enterprise level.
  4. Each enterprise has a preconfigured list of global parameters.
  5. Enterprise profiles (including System Alerts) are reusable collections of parameters and are typically referenced at lower levels.
  6. We can assign multiple component groups to each Siebel server and each component group can be assigned to more than one Siebel server.
  7. As a result of the component group assignment, each Siebel server hosts a specific set of components. Component parameters can be individually set on each Siebel server.
  8. When a component—representing program code—is executed on a Siebel server, a task is instantiated.We can pass specific parameter values to a task before it starts.

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:

Figure

different levels of parameters in the above diagram

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:

Figure

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.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Siebel - CRM Topics