Deployment Planning Guide > Application-Level Deployment Planning >

Siebel Configurator Server Components

Siebel Configurator allows users to interactively configure customizable products when ordering or generating a quote. Siebel Configurator uses a constraint-based solution engine that resides on the Siebel Server. This engine evaluates customer choices and generates product configurations that conform to business rules. Business rules are defined using constraint statements contained in models stored on the Siebel File System.

Siebel Configurator is supported in the Siebel Server environment by the following components:

• Application Object Manager (AOM). The Siebel Configurator solution engine functions within an AOM, such as Call Center Object Manager (SCCObjMgr) for Siebel Call Center.
• Siebel Product Configurator Object Manager (eProdCfgObjMgr). This is an AOM containing the Siebel Configurator solution engine. It can be deployed on a separate Siebel Server from where Siebel Configurator sessions are invoked.
• Siebel File System. This component stores cached object definitions for customizable product models in the CFGCache directory on the Siebel File System.

Configurator's architecture has been greatly enhanced in Siebel 7. With Siebel 7 a completely modular, service-based architecture has been put in place with different services interacting with each other to result in a Configurator user session.

At the same time, recognizing that configuration may be computationally expensive in some cases, some basic infrastructural enhancements allow flexibility of different deployment options to take care of different business needs. This document discusses the different deployment options along with the considerations for choosing an option in a later section.

Before discussing the actual parameters and where they can be set, it is worthwhile to go through a brief overview of Configurator's architecture and to get an understanding of the various services that are run to result in a multi-user Configurator deployment.

Figure 6. Detailed Configurator Architecture

Figure 6 shows detailed configurator architecture and the interaction of various services with each other during run time. What follows is a description of the important services depicted in this diagram:

• UI Business Service. The UI business service is a service that the configurator uses to render the UI by binding the customizable product structure with the templates and submitting it to the Siebel Web Engine for rendering to the client browser. The UI service is the way the user interacts with the configurator. A unique instance of the UI service is required for each user.
• Instance Broker. The Instance Broker is a service that interacts with the UI service and maintains all information about the current configuration of the customizable product that the user is configuring. This service interacts with other services in response to user requests during configuration, receives their responses, and serves as backup to the user through the UI service.
• Object Broker. The Object Broker is a service that extracts the customizable product definition from the database for use by other configuration services.
• Config Services. This is a configuration service that consists of factories (defined below).
• Factory. The factory is a service that creates a translation of the customizable product definition that is retrieved by the Object broker into a format the worker (defined below) can understand.
• Constraint Engine. The constraint engine is also called the worker.
• Worker. The worker is a service that enforces all the rules associated with the configuration and validates all user selections, as they are made to ensure a valid configuration.

For more information about elements of Siebel Configurator's internal architecture, including Instance Broker (Complex Object Instance Service business service) and Object Broker (Cfg Object Broker business service), see Product Administration Guide.

Siebel Configurator Performance Factors

Siebel Configurator performance has two aspects:

• Customizable product loading time. This is the time elapsed from the moment a user clicks Customize in a quote or order until the user interface for the customizable product has been loaded and displayed to the user.
• Selection response time. This is the time elapsed from the moment a user makes a selection until Siebel Configurator returns a response, such as an update to the customizable product or a conflict message.

The key performance factors that influence these times are as follows:

• Use of SnapShot Mode caching. This feature caches customizable product models in memory, which significantly reduces the amount of time required to load customizable products for each new user. This feature is particularly useful for improving performance when a product line has a small number of large, complex customizable products. For more information on Snapshot Mode caching, see Product Administration Guide.
• Number of concurrent configuration users. This is the number of concurrent users who access customizable product models. This figure will be some percentage of the total number of concurrent users on the AOM.

  Specifically, you would be concerned with the total number of configuration sessions per hour, and the average length of those sessions.

• Size and complexity of product models. This represents the total size and complexity of each customizable product model, particularly where multiple hierarchical levels, many constraints, and a complex user interface are defined.

  A major potential performance factor is custom scripting attached to update events on applicable business components, such as Quote, Quote Item, Quote Item Attribute, Order, Order Item, and Order Item Attribute.

• Number of product models. This is the number of customizable product models accessed by users. It is assumed that each user accesses no more than one customizable product model at one time. A given group of concurrent users may access multiple models, however, each of which must be separately cached.

Siebel Configurator Performance Drivers

Based on an understanding of Configurator's architecture, the following section examines some performance drivers for a Configurator deployment. Run-time performance of the Configurator can be divided into two areas. They are:

• Response time of loading configuration. This is the time elapsed from the instance user clicks Customize in a quote or order, until the Configurator UI is loaded and displayed to the user. This will depend upon a number of factors like the model size and complexity, the time taken to extract the model definition from the database, and instantiating all the services that are required to create the session.
• Response time for each selection made by the user. This is the time elapsed from the instance a user makes a selection until the Configurator returns with a response that may be an update to the configuration or a conflict message. This will depend on the model size and complexity.

  This section of the Deployment Planning Guide deals with ways to minimize the load time and not with response time for each selection.

  At the highest level, the response time of a configuration to load would be best under the following circumstances:

  • The model definition is cached in memory and does not have to be extracted from the database
  • All of the services that are required are already available and do not have to be instantiated.

    Caching of objects and services in memory can lead to significant improvement in the load time performance of a configuration session. Ideally, everything would be cached, which would give the best possible load time performance. However, that is not possible because the RAM available on the server is limited. This is why a caching strategy has to be devised for each deployment.

    To enable administrators to implement the caching strategy that is best suited for their deployment, a number of "switches" in the form of server parameters have been provided.

Siebel Configurator Deployment Planning

There are two major approaches to deploying Siebel Configurator:

• Running Siebel Configurator in an AOM component.
• Running Siebel Configurator on one or more dedicated Siebel Servers. Such servers are sometimes referred to as remote servers, because they are remote to the machine on which AOM is running. In general, this section uses the term dedicated servers.

Running Siebel Configurator in an AOM Component

You can run Siebel Configurator in the AOM component, such as for Siebel Call Center.

If a small number of concurrent users require configuration sessions, or there are a small number of customizable product models, then this deployment option may yield reasonable performance and make the most effective use of your hardware resources.

Running Siebel Configurator on Dedicated Servers

You can run Siebel Configurator on one or more dedicated Siebel Server machines using a server component other than the AOM. This component is Siebel Product Configurator Object Manager (eProdCfgObjMgr).

Possible variations on this deployment strategy include:

• Running one eProdCfgObjMgr component with one AOM component
• Running multiple eProdCfgObjMgr components with one AOM component
• Running one eProdCfgObjMgr component with multiple AOM components

If a large number of concurrent users require configuration sessions, or there are a large number of customizable product models, then using one or more dedicated servers may yield the best performance and make the most effective use of your hardware resources.

Configurator Caching

Object Broker

The Object Broker is a service that extracts the customizable product definition from the database for use by other configuration services. To improve performance, the Object Broker also maintains a cache of objects in the memory to minimize interaction with the database. You can configure the number of objects that are cached from a list in the server parameters later in the process. Normally the size of the cache is quite small. Different users can share the same Object cache.

Factory

The factory is a service that creates a translation of the customizable product definition that is retrieved by the Object broker into a format the worker (detailed below) can understand. Each factory can serve multiple users at run time. Factories are customizable product-specific, meaning that each customizable product requires its own unique factory. Factories can be cached in the memory; you can configure the number of factories that are cached from a list in the server parameters later in the process.

Worker (7.5.3 and Earlier)

The worker is a service that enforces all the rules associated with the configuration and validates all user selections, as they are made to ensure a valid configuration. A unique instance of the worker, specialized for the customizable product the user is configuring, is required for each user. Unlike factories, multiple users cannot share workers at the same time. However, when a user exits configuration, the worker is freed and it can be used by another user for a session. A server setting is available for caching workers and avoiding the performance impact of creating a worker at run time.

Worker (7.7 and Later)

After 7.5.3, the purpose of the worker has not changed, except that it is now a "shared" worker. A session only locks a worker during a single configuration request. In between requests, the worker can serve additional configuration sessions.

While the relative number of workers now required to support a user base depends on the time between clicks of particular scenarios and the number of clicks that require worker interaction, the general guideline is that a given worker can now support two to three concurrent users for the same model.

SnapShot Mode

SnapShot mode is a server setting that allows the Configurator to create and execute using cached objects, factories, and workers. If this setting is not chosen, each user configuration session would be associated with the following:

• Extraction of the customizable product definition and all objects associated with it from the database
• Creation of a factory for the customizable product
• Creation of a worker for the user session

If this mode is chosen, depending upon the parameter values set up, objects, factories, and workers would be cached in memory and would be first examined if they can be used to initiate a user session. Only if the existing cache cannot support the user session will new objects be extracted or factories or workers created.

Considerations About SnapShot Mode

Here are some things to remember about SnapShot mode:

• SnapShot mode decides the upper bound of caching.
• Cache is created as one goes along. This means the first user request would result in the first set of cache being created. The second user may end up using the same cache because the user wants to configure the same customizable product that user 1 configured. Meanwhile, the third user, who wants to configure a different product, creates a new cache and so on.

Determining Server Settings for Cache Management in SnapShot Mode (7.0.4 and 7.5)

Table 13 shows server settings for SnapShot mode.

Determining Server Settings

After outlining the reasons for caching and listing the parameters that are used to manage the cache, you need to determine the settings. The cache parameters will vary widely depending upon the customizable product structure, rules, size, and so on. However, there are some quick tests that you can do to determine the size of the customizable product. From these tests, you can estimate the size of the factory and worker and determine the cache parameters.

The procedure below describes what you need to do. It is part of an example that explains how to determine server settings. Note that all numbers used for memory in the example that follows are purely hypothetical and are not in any way representative of the actual resource requirements in a production environment.

Test Steps

• Run the Siebel application in a connected client mode. The database may or may not be on the same machine; it does not matter.
• Launch the Siebel application and navigate to Quote/Order (whichever the end user would be using).
• Launch Windows Task Manager and note the memory used by Siebel.exe (for example, if memory is 20 MB, call it X).
• Add the customizable product to the order (assuming this is the end user scenario).
• Launch Configurator by clicking Customize. Note the memory after the model is loaded (for example, if memory is 40 MB, call it Y).
• Add items to the configuration as an end user would.
• Do the same for a couple of conflicts and their resolution. After following the steps that a normal end user would, note the memory (for example, if memory is 50 MB, call it Z).
• When you have added enough items as an end user would, click Done to save and exit configuration.

Determining Factory and Worker Size

Factory Size

As a rule, you can assume that the size of the factory at run time is 75% of the incremental memory used when instantiating the customizable product.

For example, factory size equals 75% of (Y-X)= .75(40-20) = 15 MB.

Worker Size

Worker size varies during run time. Generally, the worker size increases as selections are made. To size the worker, take the maximum memory observed and subtract the factory size from it.

For example, worker size equals (Z-X)-Factory size= (50-20)-5= 25MB.

Object Cache Size

Because this is normally quite small (for example 500K), you can ignore it in your calculations.

Example of Sizing Cache Parameters with SnapShot Mode

Assumptions

The requirement is to support 5000 concurrent call center users. Among them, at any time, 100 users use Configurator. This means:

• The enterprise needs to support 5000 concurrent call center users.
• Of these 5000 call center users, 100 need to be using Configurator concurrently.
• There is only one customizable product in the product portfolio. (Multiple-product cases will be discussed in a later section.)

Sizing

Because all caching and services are specific to the Object Manager process on a Siebel Server, first you must estimate the size of the call center deployment. (The numbers below are used for example only and not indicative of call center sizing.)

• Assume you are supporting the 5000 call center users on eight application servers (each being a Pentium 4 machine with 4 CPUs and 4GB of memory), with each server handling 625 users.
• Each application server itself is run with 25 Object Managers, with each Object Manager supporting 25 users.

To support cached objects, factories, and workers for all 100 users, the following conclusions can be drawn:

• At least one factory needs to be cached for every Object Manager process. This means you must cache 25 factories per server or one per OM.
• To support all 100 concurrent users to get a cached worker, you must cache, at a minimum, 100 workers across the enterprise. At the same time at least one worker should be cached for each Object Manager process. This means you must cache 25 workers per server or one per OM.

In the example above, the cache size in this case for each OM equals the size of the factory cache plus the size of the worker cache. Expressed as a formula, it looks like this: 5+25= 30MB per OM. Therefore, the Configurator cache requires a total of 30*25= 750MB across the whole server for each server.

The server parameters would be set as follows for each application server:

• eProdCfgSnapshotFlg: True
• eProdCfgNumOfCachedObjects: 1000
• eProdCfgNumbOfCachedFactories: 1
• eProdCfgNumbOfCachedWorkers: 1

Observations About Sizing

From the sizing exercise above, it is clear that the Configurator cache needs to be actively managed for best performance using appropriate resources. This is why it is extremely important to go through the exercise of sizing the cache. In some cases the cache requirements may be such that they require additional application servers to fully support all users with good response times for load time.

In addition to the preceding calculation, in some situations it is appropriate to set the number of workers according to how much memory is available once enough memory has allocated been to the factory cache and application overhead. The details of this calculation are specific to an individual implementation's average factory size, average worker size, and average object manager process size. The average OM process size depends on the number of OM processes, the total memory available, and the maximum process size for the OS being used. For additional assistance in this area, contact Siebel Expert Services.

Deployment Options

As mentioned at the beginning of the discussion on architecture, one of the enhancements made to the Configurator is the flexibility of deployment options offered with Siebel 7. These deployment options are as follows:

• Deploy Configurator to run on the same machine as the base application server, as shown in the figure below.
• Deploy Configurator to run on a different machine than the base application server. The figure below depicts this deployment option.
• The modes shown above are the supported deployment options for 7.0.3/7.0.4 releases. Release 7.5 supports the following third deployment mode:

In many cases, the option of deploying Configurator on a different server may result in a much better use of resources due to pooling effects. Considering the example examined and sized from the preceding section, the result was a sizing of one factory and one worker to be cached for each Object Manager on each server. The implications of this across the whole enterprise are as follows:

• The number of OMs on each server was 25, so each server will cache 25 factories and 25 workers.
• Across the whole enterprise of eight application servers, this translates to 25*8= 200 factories and 200 workers to be cached.
• In memory terms:
  • 200*5= 1000MB for caching factories, and
  • 200*25= 5000MB for caching workers

    This results in a total memory usage of 6000MB across the enterprise.

Because the requirement is to support 100 concurrent users, a large number of these factories and at least 100 of these workers are idling at any time. The large amount of cache in this case is because there is no way to know in advance which Object Manager process the user who is configuring is connected to. For this reason, caching must be done across all object managers.

There are other problems with this scenario. For instance, what happens when two users are connected to the same OM process and both want to configure? In this case, the second user has to create a worker, causing performance issues for that user. Also, if there are multiple users configuring on the same machine, the server might run out of memory.

Consider another scenario. Assume that the enterprise has customizable products that these users might be configuring, with 50 concurrent users configuring each customizable product. However, because there is no way to know in advance which OM process these users might be connected to, you would have to cache two factories and two workers for each OM. This is a less-than-satisfactory solution in this instance.

Example of Sizing the Deployment with a Dedicated Configurator Server

Consider the example that was sized for the deployment option of running the Configurator on the same servers as the application server, and size it for the deployment option of Configurator running on a separate server.

Assumptions

The requirement is to support 5000 concurrent call center users. Among them, at any time, 100 users use the Configurator. This means:

• The enterprise needs to support 5000 concurrent call center users.
• Of these 5000 call center users, 100 need to be using the Configurator concurrently.
• There is only one customizable product in the product portfolio. (Multiple-product cases will be discussed in a later section.)

Sizing

Because all caching and services are specific to the Object Manager process on a Siebel Server, first you must estimate the size of the call center deployment. (The numbers used below are an example only and not indicative of call center sizing.)

• Assume you are supporting the 5000 call center users on seven application servers (each being a Pentium 4 machine with 4 CPUs and 4GB of memory), with each server handling 720 users.
• Each application server itself is run with 25 Object Managers, with each Object Manager supporting 25 users.
• Assume that one server has been configured to run the Configurator that will support the 100 users.
• The Configurator server is configured to run with four Object Managers, with each Object Manager supporting 25 users.

To support cached objects, factories, and workers for all 100 users, the following conclusions can be drawn:

• At least one factory needs to be cached for every Object Manager process. You must cache four factories for the Configurator server or one per OM.
• To support all 100 concurrent users to get a cached worker, you must cache, at a minimum, 100 workers across the Configurator server. This means you must cache 25 workers for each Object Manager on the Configurator server.

In the example above, the cache size in this case for each OM equals the size of the factory cache plus the size of the worker cache. Expressed as a formula, it looks like this: 5*1+25*25= 630MB per OM. Therefore, the Configurator cache requires a total of 4*630= 2520 MB across the whole Configurator server for each server.

The server parameters would be set as follows for the application and Configurator servers:

The implications of this across the whole enterprise of eight servers, with one of the servers working dedicatedly to support Configurator, means 2520MB of cache. This is much lower than the 6000MB required for the eight application server deployment option. Choosing this deployment option makes better use of the cache.

Moreover, since the Configurator server is configured to allow only 25 connections to each OM, there would never be a case where a user does not find a cached worker to work with. In a multi-model scenario, this deployment would be much more efficient in terms of memory usage.

Server Settings for Dedicated Configurator Server Deployment Mode (7.5 and later)

Table 14 shows server settings for dedicated Configurator server deployment mode.