Bookshelf Home | Contents | Index | PDF |
Deployment Planning Guide > Application-Level Deployment Planning > Siebel Configurator Server ComponentsSiebel 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:
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 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:
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 FactorsSiebel Configurator performance has two aspects:
The key performance factors that influence these times are as follows:
Siebel Configurator Performance DriversBased 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:
Siebel Configurator Deployment PlanningThere are two major approaches to deploying Siebel Configurator:
Running Siebel Configurator in an AOM ComponentYou 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 ServersYou 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:
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 CachingObject BrokerThe 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. FactoryThe 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 ModeSnapShot 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:
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 ModeHere are some things to remember about SnapShot mode:
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 SettingsAfter 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
Determining Factory and Worker SizeFactory SizeAs 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 SizeWorker 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 SizeBecause this is normally quite small (for example 500K), you can ignore it in your calculations. Example of Sizing Cache Parameters with SnapShot ModeAssumptionsThe requirement is to support 5000 concurrent call center users. Among them, at any time, 100 users use Configurator. This means:
SizingBecause 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.)
To support cached objects, factories, and workers for all 100 users, the following conclusions can be drawn:
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:
Observations About SizingFrom 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 OptionsAs 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:
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:
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 ServerConsider 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. AssumptionsThe requirement is to support 5000 concurrent call center users. Among them, at any time, 100 users use the Configurator. This means:
SizingBecause 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.)
To support cached objects, factories, and workers for all 100 users, the following conclusions can be drawn:
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. |
Deployment Planning Guide |