Application-Level Deployment Planning

Some Siebel applications or product modules can be deployed in multiple ways. This chapter provides an overview of deployment options for these applications. Use this chapter to help make decisions about how to deploy applications across Siebel Servers. This chapter includes the following topics:

Session Communications

Siebel Email Response

Siebel Product Configurator

Siebel Workflow Manager

Siebel Workflow Deployment Planning

Siebel Remote and Batch Job Processing

Planning Batch Processing When Using Siebel Remote

For more information about application deployment planning, see Siebel Performance Tuning Guide, Siebel Installation Guide for the operating system you are using, Siebel System Administration Guide, and other relevant guides identified in this chapter.

Session Communications Server Components

Session communications refers to using Siebel Communications Server components to enable contact center agents or other users to handle interactive communications work items. For example, Siebel CTI and Siebel Chat support this capability, enabling agents to handle voice calls or chat interactions using the communications toolbar.

Siebel Communications Server provides an application environment to support several kinds of communications activities for Siebel application users, including session communications (such as voice calls or chat). For more information about Siebel CTI, see Siebel CTI Administration Guide. For more information about Siebel Chat, see Siebel Chat Guide.

Key Siebel Server Components

Session communications are supported in the Siebel Server environment primarily by the following components:

Communications Session Manager (CommSessionMgr). This server component manages interactive communications work items such as voice calls.
Application Object Manager. This server component, such as Call Center Object Manager, manages application sessions for end users who use the Siebel Web Client, including users who handle communications work items (agents). Interactive communication requests from agents typically go through the Application Object Manager.
Server Request Broker (SRBroker). This server component handles communications between the Application Object Manager and certain other Siebel Server components, including CommSessionMgr.
For example, when a Siebel CTI agent makes a call through the communications toolbar, the request goes from the Application Object Manager to CommSessionMgr by way of SRBroker.
SRBroker is used whether CommSessionMgr runs on the same computer as the Application Object Manager, or on a different computer.

Additional Siebel Server Component

You might also be using the following Siebel Server component to manage session communications:

Communications Configuration Manager (CommConfigMgr). Optionally, you might use this server component to cache communications configuration data.

Session Communications Performance Factors

Depending on your deployment, your agents might handle phone calls (Siebel CTI) or work items of other communications channels, or some combination of these. Use the following factors to analyze system performance:

Inbound calls processed per hour. This is the number of inbound calls (or other types of work items) processed per hour (or some other time period) by your communications infrastructure.
Outbound calls processed per hour. This is the number of outbound calls processed per hour (or some other time period) by your communications infrastructure. (For outbound predictive dialer calls, only the calls that are answered and processed by Communications Server are relevant here.)
Number of user communications actions per minute (load). This is the average number of communications-related user actions per minute, and the average think time between such user actions. Communications-related actions typically refers to actions performed using the communications toolbar.
Longer think times mean less load on the Siebel database and Siebel Server. Think time is an important factor in the overall system load. Approximate actual user usage in your estimations.
Number of concurrent communications users (agents). This is the number of concurrent users of session communications features, typically, contact center agents. This figure is some percentage of the total number of concurrent users on the Application Object Manager.
Number of work items. This represents the average number of inbound and outbound work items for each agent, and how these factors relate to your organization’s service goals are also important factors influencing performance. Some agents receive a large number of work items from ACD queues, or initiate a large number of work items. Supervisors or other users might be defined as agents but might receive only escalated work items, for example.
Volume of customer data. This is the total volume of customer data. Data volume affects how quickly data can be retrieved for various purposes, such as to perform lookups for pop-up windows, route work items, or populate the customer dashboard. In many cases, data volume directly affects agents’ response times. Assume a realistic volume of data and tune the database to reflect real-world conditions.

Third-Party Product Considerations

Review information presented in applicable third-party documentation for any requirements that affect your deployment. For example:

Some CTI middleware software might place limitations on the number of agents that can be served at a single contact center site.
Integration with ACD queues, predictive dialers, or other modules might affect your configurations, affect network traffic, or have other impacts.
The capacity of your telephony link (between the ACD switch and the CTI middleware) can affect performance.

Session Communications Deployment Planning

Generally, you run Siebel Communications Server components for session communications, such as CommSessionMgr, on the same Siebel Server computers as those running Application Object Managers. In some cases, however, you must run CommSessionMgr on a different computer than the Application Object Managers. These options are described in detail, as follows. CTI middleware generally runs on servers located at each contact center facility.

Running CommSessionMgr on Application Object Manager Computers

Generally, you run Siebel Communications Server components for session communications on the same Siebel Server computers as those running Application Object Managers. Such a topology allows the Application Object Manager load balancing mechanism to indirectly balance Communications Server load. CommSessionMgr loads are fairly light and do not, in themselves, present a reason to run this component on dedicated computers.

Set the Enable Communication parameter to True for all of the Application Object Managers to which your agents connect. If you use load balancing, then configure all of the Application Object Managers to which requests are distributed in the same way.

Running CommSessionMgr on Dedicated Computers

Sometimes you must run CommSessionMgr on a different computer than the Application Object Manager components.

CommSessionMgr must run on the same computer where the communications driver for your CTI middleware is running. If your driver requires a particular operating system, then you must install Siebel Server and run CommSessionMgr on a computer with that operating system. Communications drivers must be able to run on one of the supported Siebel Server platforms, as described in the Certifications tab on My Oracle Support.

Siebel Email Response Server Components

Siebel Email Response uses Communications Server components to enable contact center agents to read and respond to inbound email messages. For more information about Siebel Email Response, see Siebel Email Administration Guide.

Key Siebel Server Components

Siebel Email Response is supported in the Siebel Server environment primarily by the following server components:

Communications Inbound Receiver (CommInboundRcvr). This server component receives inbound work items and queues them for processing by Communications Inbound Processor. Work items might include email messages (for Siebel Email Response).
- For nonreal-time work items, such as email messages for most deployments of Siebel Email Response, Communications Inbound Receiver queues work items it has received for further processing by Communications Inbound Processor.
- For real-time work items, such as email messages for some deployments of Siebel Email Response, Communications Inbound Receiver processes work items it has received. Communications Inbound Processor is not used.
Communications Inbound Processor (CommInboundProcessor). This server component processes inbound work items that were queued by Communications Inbound Receiver.
Communications Outbound Manager (CommOutboundMgr). This server component sends outbound email.
Siebel File System Manager. This server component writes to and reads from the Siebel File System. It stores inbound messages prior to processing and stores attachments to inbound and outbound email messages.

Additional Siebel Product Module

In addition to Siebel Email Response, you might be using the following Siebel module:

Siebel Assignment Manager. You can use this module for routing email messages to agents.

Third-Party Email Server

Siebel Email Response works in conjunction with your third-party email server. Review information presented in documentation for your email server for any requirements that affect your deployment. For information about supported email servers, see the Certifications tab on My Oracle Support.

Siebel Email Response Performance Factors

The key factors that influence performance for Siebel Email Response deployments are as follows:

Inbound email messages processed per hour. This is the number of inbound email messages processed per hour (or some other time period) by your communications infrastructure.
Requirements for processing outbound messages are relatively minor and are tied to inbound message volume. However, you must also consider other usage of the CommOutboundMgr component or of the email system. For example, you can configure the Send Email command to send email through CommOutboundMgr.
Volume of customer data. This is the total volume of customer data, including templates or categories, literature items, and so on. Template format (HTML or plain text) is a related factor.

Other factors include the size and complexity of inbound email messages and outbound replies.

Also relevant are user settings in the Outbound Communications section of the User Preferences screen, such as whether a reply contains the original message (Include Original Message in Reply setting), or whether HTML or plain text is an agent’s default message format (Default Message Format setting).

Siebel Email Response coverage in this topic focuses on inbound and outbound email processing. In a multichannel environment, session communications performance issues also apply.

Siebel Email Response Deployment Planning

Processing inbound email messages makes more demands on server resources, particularly CPU usage levels, than processing outbound messages.

A single computer must handle processing of inbound messages associated with a single response group.

If inbound message volume warrants it and if multiple server computers are available to run CommInboundRcvr and related components, then consider running CommInboundRcvr on a separate computer (or computers) from other Communications Server components.

Combining processing of messages for multiple email accounts in a single response group can make processing of inbound messages more efficient. However, if message volume is expected to grow, then limiting the number of email accounts processed by each response group gives you more flexibility to distribute processing across multiple servers, avoiding processing bottlenecks.

Siebel Product Configurator Server Components

Siebel Product Configurator allows users to interactively configure customizable products when ordering or when generating a quote. Siebel Product Configurator uses a constraint-based solution engine that resides on the Siebel Server called the Constraint Engine. This engine evaluates customer choices and generates product configurations that conform to business rules.

For more information about using, installing, administering, and tuning Siebel Product Configurator modules, see:

Siebel Product Administration Guide
Siebel Installation Guide for the operating system you are using
Siebel System Administration Guide
Siebel Performance Tuning Guide
Article ID 2112562.1 on My Oracle Support

Remaining topics about Siebel Product Configurator in this chapter include:

Siebel Product Configurator Components

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

Application Object Manager. The Siebel Product Configurator solution engine is called by the Application Object Manager, such as Call Center Object Manager (SCCObjMgr_lang, such as SCCObjMgr_fra for French) for Siebel Call Center.
Siebel Product Configuration Object Manager (alias eProdCfgObjMgr_locale). This is a special-purpose Object Manager component suitable for some Siebel Product Configurator deployments. For convenience, the component alias is generally referred to in this guide as simply eProdCfgObjMgr. This component contains the Siebel Product Configurator solution engine. It can be deployed on a separate Siebel Server from where Siebel Product Configurator sessions are invoked.
The Siebel Product Configurator server in this type of deployment is also referred to as a remote or dedicated Siebel Product Configurator, which works in coordination with the invoking Application Object Manager. See later in this topic for locale-related requirements for a remote Siebel Product Configurator component.
Siebel File System. This component stores cached object definitions for customizable product definitions in the CFGCache directory on the Siebel File System.

Locale-Related Requirements for Remote Siebel Product Configurator Components

The three-letter extension to the alias of the Siebel Product Configuration Object Manager component (jpn in the example of eProdCfgObjMgr_jpn) corresponds to the value for the Locale Code parameter (alias LocaleCode) associated with the invoking Application Object Manager. For a remote Siebel Product Configurator component that you intend to invoke, the name of the component must follow this pattern.

The reason for this requirement is that data passed between the invoking Application Object Manager and the remote Siebel Product Configurator component is in a locale-specific format.

If Locale Code on the invoking Application Object Manager is set to a value that does not correspond to a language supported for Siebel applications, then you must either change the Locale Code on the invoking Application Object Manager or create a new remote Siebel Product Configurator component with the required name.

For example, assume the invoking Application Object Manager is SCCObjMgr_enu, but Locale Code is set to ENG rather than ENU. In this case, you must do one of the following:

Change Locale Code to ENU in order to work with a remote Siebel Product Configurator component named eProdCfgObjMgr_enu.
Create a remote Siebel Product Configurator component named eProdCfgObjMgr_eng.

In addition, note that the Language and Locale Code parameter settings for the remote Siebel Product Configurator component must match the parameter settings for the invoking Application Object Manager component.

For more information about the Language and Locale Code parameters, see Siebel Global Deployment Guide. For more information about creating and configuring server components, see Siebel System Administration Guide.

Siebel Product Configurator Architecture

Because product configuration can sometimes be computationally expensive, the configuration infrastructure provides flexible deployment options to suit different business needs. Topics in this section discuss considerations for choosing among different deployment options.

Before the Siebel Product Configurator parameters, and where to set them, are described, a brief overview is presented of the Siebel Product Configurator architecture and of the various services in a Siebel Product Configurator deployment.

The following figure shows detailed Siebel Product Configurator architecture and the interaction of various services with each other during run time.

Detailed Siebel Product Configurator Architecture: This image is described in the surrounding text.

The important services depicted in the preceding figure are as follows:

UI. The UI business service is a service that the Siebel Product Configurator uses to render the user interface 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 business service is the way the user interacts with the Siebel Product Configurator. A unique instance of this service is required for each user.
Instance Broker. The Instance Broker is a service that interacts with the UI service and maintains all of the 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. The Instance Broker is accessed through a proxy service: either the Complex Object Instance Service business service or the Remote Complex Object Instance Service business service.
Configurator Object Broker. The Configurator Object Broker is a service (Cfg Object Broker business 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 as follows).
Factory. The factory is a service that represents a translation of the customizable product definition that is retrieved by the Configurator Object Broker into a format a worker (defined as follows) can understand.
Constraint Engine or Worker. The constraint engine, also called a worker, is a service that enforces all of the rules associated with the customizable product. It validates all selections (interactive or batch) as they are made to ensure a valid configuration. A worker of a factory can be shared among different requests originating from the same Application Object Manager process.

For more information about elements of Siebel Product Configurator’s internal architecture, including the Instance Broker and the Configurator Object Broker, see Siebel Product Administration Guide.

Siebel Product Configurator Architecture for Oracle Constraint Technology Integration

An Oracle Constraint Technology integration for Siebel Product Configurator is available as an alternative way to deploy Siebel Product Configurator. For the current release, such an integration is in developer preview status only. Deploying this type of integration requires the following modules:

Siebel Enterprise Cache. To use Siebel Product Configurator in an integration of this type, you must install and configure the Enterprise Cache within your Siebel CRM deployment, as described in the Siebel Installation Guide for the operating system you are using. Siebel Enterprise Cache is based on Oracle Coherence. For more information about using Oracle Coherence, see product documentation on the Oracle Help Center.
Siebel Constraint Engine. To use Siebel Product Configurator in an integration of this type, you must install and configure the Constraint Engine within your Siebel CRM deployment, as described in the Siebel Installation Guide for the operating system you are using. The Constraint Engine is based on Oracle Advanced Constraint Technology. For more information about using Oracle Advanced Constraint Technology, see product documentation on the Oracle Help Center.

Note: In the context of this type of integration, the Siebel Constraint Engine as discussed here is completely different than the Constraint Engine used by the traditional Siebel Product Configurator offering. (Most of the information about Siebel Product Configurator in this guide pertains to the traditional offering.)

For information about installing and configuring the Siebel Enterprise Cache and the Siebel Constraint Engine, see the Siebel Installation Guide for the operating system you are using. See also Article ID 2112562.1 on My Oracle Support.

For more information about using Siebel Product Configurator, see Siebel Product Administration Guide.

Siebel Product Configurator Performance Factors

For an overview of Siebel Product Configurator server components and other architecture elements, see Siebel Product Configurator Server Components.

Siebel Product Configurator performance contexts to consider include response times for:

Loading customizable products. The time elapsed from the moment a user clicks Customize in a quote or order until the Siebel Product Configurator user interface for the customizable product is loaded and displayed to the user.
Responding to user selections. The time elapsed from the moment a user makes a selection until Siebel Product Configurator returns a response, such as an update to the customizable product or a conflict message.

The following performance factors, particularly customizable product size and complexity, are relevant in both of these contexts:

Number of concurrent configuration users. The number of concurrent users who access customizable product definitions. This figure is some percentage of the total number of concurrent users on all of the applicable Application Object Managers.
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 customizable products. The total size and complexity of each customizable product definition, 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 customizable products. The number of customizable products accessed by users. It is assumed that each user accesses no more than one customizable product at one time. A given group of concurrent users might access multiple customizable products, however, each of which must have a separately cached factory. (An existing worker can be shared if one is available. Otherwise, internal performance mechanisms generate a new worker.)
Use of SnapShot mode caching. A feature that caches customizable products in memory, significantly reducing the amount of time required to load customizable products for each new user. SnapShot mode is particularly useful for improving performance when a product line has a small number of large, complex customizable products. For more information about SnapShot mode caching, see Siebel Product Administration Guide.

The response time of loading customizable products depends in part on the time taken to extract the customizable product definition from the database, and the time needed to instantiate all of the services required to create the session. At the highest level, the response time for loading a customizable product would be best under the following circumstances:

The customizable product 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 load time performance for 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. For this reason, a caching strategy must be devised for each deployment. To enable administrators to implement the caching strategy that is best suited for their deployment, several switches in the form of server parameters have been provided.

Siebel Product Configurator Deployment Planning

Siebel Product Configurator deployment planning must take into account the considerations described in the following topics:

About Deployment Topology for Siebel Product Configurator

There are two major topology approaches to deploying Siebel Product Configurator:

Running Siebel Product Configurator in an Application Object Manager component.
Running Siebel Product Configurator on one or more dedicated Siebel Servers.

For details, see Siebel Product Configurator Deployment Topology Options.

This topic is part of Siebel Product Configurator Deployment Planning.

Running Siebel Product Configurator in an Application Object Manager Component

You can run Siebel Product Configurator in the Application Object Manager component, such as a language-specific Call Center Object Manager component.

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

Running Siebel Product Configurator on Dedicated Computers

You can run Siebel Product Configurator on one or more dedicated Siebel Server computers using a server component called the Siebel Product Configuration Object Manager (eProdCfgObjMgr).

Such server computers are sometimes referred to as remote servers, because they are remote to the computer on which the Application Object Manager is running. In general, this guide uses the term dedicated servers.

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

Possible variations on this deployment strategy include:

Running one eProdCfgObjMgr component with one Application Object Manager component
Running multiple eProdCfgObjMgr components with one Application Object Manager component
Running one eProdCfgObjMgr component with multiple Application Object Manager components
Running multiple eProdCfgObjMgr components with multiple Application Object Manager components

About Siebel Product Configurator Caching

This topic provides information about Siebel Product Configurator caching.

This topic is part of Siebel Product Configurator Deployment Planning.

Configurator Object Broker

The Configurator Object Broker is a service that extracts the customizable product definition from the database for use by other configuration services. To improve performance, the Configurator Object Broker also maintains a cache of objects in the memory to minimize interaction with the database. 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 Configurator Object Broker into a format that the worker (described as follows) can understand. Each factory can serve multiple users at run time. Factories are specific to each customizable product, meaning that each customizable product requires its own unique factory. Factories can be cached in memory.

Worker

The worker is shared: in other words, 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 customizable product.

SnapShot Mode

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

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

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

Considerations About SnapShot Mode

Here are some things to remember about SnapShot mode:

SnapShot mode determines the upper bound of caching.
The cache is created as one goes along. The first user request results in the first set of cache data being created. The second user might end up using the same cache because the user wants to configure the same customizable product that the first user configured. Meanwhile, the third user, who wants to configure a different product, creates a new cache, and so on.
Re-use of cache data occurs only for requests originating from the same Application Object Manager process, for any Siebel Product Configurator deployment.

Determining Factory and Worker Size

This topic provides information about determining factory and worker size for your Siebel Product Configurator deployment.

This topic is part of Siebel Product Configurator Deployment Planning.

Factory Size

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

For example, the factory size equals 75% of (Y minus X), which equals .75 times (40 minus 20), which equals 15 MB.

Worker Size

The 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, the worker size equals (Z minus X) minus the factory size, which equals (50 minus 20) minus 5, which equals 25 MB.

Object Cache Size

Because the object cache size is normally quite small (for example, 500 KB), you can ignore it in your calculations.

Example of Sizing the Cache with SnapShot Mode

This topic provides an example of sizing the Siebel Product Configurator cache with SnapShot mode.

This topic is part of Siebel Product Configurator Deployment Planning.

Assumptions

The requirement is to support 5000 concurrent Siebel Call Center users. Among them, at any time, 100 users use Siebel Product Configurator. This means:

The enterprise must support 5000 concurrent Call Center users.
Of these 5000 Call Center users, 100 must be able to use Siebel Product Configurator concurrently.
There is only one customizable product in the product portfolio.

Sizing

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

Assume that you are supporting the 5000 Call Center users on eight application servers (each a Pentium 4 computer with 4 CPUs and 4 GB of memory), with each server handling 625 users.
Each Siebel Server runs with 25 Application Object Managers, with each Application 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 must be cached for every Object Manager process. This means that you must cache 25 factories for each server or one for each Application Object Manager.
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, cache at least one worker for each Application Object Manager process. This means that you must cache 25 workers for each server or one for each Application Object Manager.

In the preceding example, the cache size in this case for each Application Object Manager equals the size of the factory cache plus the size of the worker cache. Expressed as a formula, it looks like this: 5 plus 25 equals 30 MB for each Application Object Manager. Therefore, the Siebel Product Configurator cache requires a total of 30 times 25, which equals 750 MB for each server.

The server parameters would be set as follows for each Siebel Server (Application Object Manager):

eProdCfgSnapshotFlg: True
eProdCfgNumbOfCachedWorkers: 1

Observations About Sizing

From the preceding sizing exercise, it is clear that the Siebel Product Configurator cache must be actively managed for best performance using appropriate resources. It is extremely important to go through the exercise of sizing the cache. In some cases, the cache requirements might be such that they require additional application servers to fully support all of the 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 been allocated 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 Application Object Manager process size. The average Application Object Manager process size depends on the number of Application Object Manager processes, the total memory available, and the maximum process size for the operating system being used.

For additional assistance in this area, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.

Siebel Product Configurator Deployment Topology Options

Siebel Product Configurator offers the flexibility of different deployment topology options.

This topic is part of Siebel Product Configurator Deployment Planning.

Siebel Product Configurator deployment topology options are as follows:

Deploy Siebel Product Configurator to run on the same computer as the base application server computer, as shown in the following figure.
Deploy Siebel Product Configurator to run on a different computer than the base application server computer, as shown in the following figure.
Deploy multiple instances of Siebel Product Configurator on multiple dedicated application server computers, as shown in the following figure.

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

The number of Application Object Managers on each server was 25, so each server caches 25 factories and 25 workers.
Across the whole enterprise of eight application servers, this translates to 25 times 8, which equals 200 factories and 200 workers to be cached.
In memory terms:
- 200 times 5, which equals 1000 MB for caching factories, and
- 200 times 25, which equals 5000 MB for caching workers
This results in a total memory usage of 6000 MB across the enterprise.

Because the requirement is to support 100 concurrent users, many 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 Application Object Manager process the user who is configuring is connected to. For this reason, caching must be done across all of the Application Object Managers.

There are other problems with this scenario. For instance, what happens when two users are connected to the same Application Object Manager 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 computer, then the computer 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 Application Object Manager process these users might be connected to, you would have to cache two factories and two workers for each Application Object Manager, which would be a less-than-satisfactory solution.

Example of Deployment Sizing with a Dedicated Siebel Product Configurator Server

Consider the sizing example for the deployment option of running the Siebel Product Configurator on the same server as the application server (see Example of Sizing the Cache with SnapShot Mode). Size it instead for the deployment option of Siebel Product Configurator running on a separate server.

This topic is part of Siebel Product Configurator Deployment Planning.

Assumptions

The requirement is to support 5000 concurrent Siebel Call Center users. Among them, at any time, 100 users use the Siebel Product Configurator. This means:

The enterprise must support 5000 concurrent Call Center users.
Of these 5000 Call Center users, 100 must be able to use the Siebel Product Configurator concurrently.
There is only one customizable product in the product portfolio.

Sizing

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

Assume that you are supporting the 5000 Call Center users on seven application servers (each being a Pentium 4 computer with 4 CPUs and 4 GB of memory), with each server handling 720 users.
Each application server itself is run with 25 Application Object Managers, with each Application Object Manager supporting 25 users.
Assume that one server has been configured to run the Siebel Product Configurator that supports the 100 users.
The Siebel Product Configurator server is configured to run with four Application Object Managers, with each Application 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 must be cached for every Application Object Manager process. You must cache four factories for the Siebel Product Configurator server or one for each Application Object Manager.
To support all 100 concurrent users to get a cached worker, you must cache, at a minimum, 100 workers across the Siebel Product Configurator server. This means that you must cache 25 workers for each Application Object Manager on the Siebel Product Configurator server.

In the preceding example, the cache size in this case for each Application Object Manager equals the size of the factory cache plus the size of the worker cache. Expressed as a formula, it looks like this: (5 times 1) plus (25 times 25) equals 630 MB for each Application Object Manager. Therefore, the Siebel Product Configurator cache requires a total of 4 times 630, which equals 2520 MB for each server.

The server parameters would be set as follows for the Siebel Servers running the Application Object Managers and the Siebel Product Configurator servers:

Parameter Name	Value	Description
eProdCfgServer	Name of the Siebel Server running the Siebel Product Configurator.	Set On: Each Siebel Server running the Application Object Manager (see the information that follows about server settings for the dedicated Siebel Product Configurator server deployment mode)
eProdCfgSnapshotFlg	True	Set On: Each Siebel Server running the Application Object Manager and each Siebel Product Configurator server
eProdCfgNumbOfCachedWorkers	25	Set On: Siebel Product Configurator server

This type of deployment across an enterprise with eight servers, one a dedicated server to support Siebel Product Configurator, requires 2520 MB of cache. This figure is much lower than the 6000 MB required for the eight application server deployment option. Choosing this deployment option makes better use of the cache.

Moreover, since the Siebel Product Configurator server is configured to allow only 25 connections to each Application Object Manager, there would never be a case where a user does not find a cached worker to work with. In a scenario with multiple customizable products, this deployment would be much more efficient in terms of memory usage.

Server Settings for Dedicated Siebel Product Configurator Server Deployment Mode

The following table shows server settings for dedicated (remote) Siebel Product Configurator server deployment mode. Except where noted, set these parameters on the Application Object Manager component.

Parameter Name	Display Name	Data Type	Default Value	Description
eProdCfgRemote	Product Configurator - Use Remote Service	Boolean	False	Setting to determine whether Siebel Product Configurator is running on a different server from the Application Object Manager. On the Application Object Manager: set it to True when running a dedicated Siebel Product Configurator server. On the dedicated Siebel Product Configurator server: leave this set to False.
eProdCfgServer	Product Configurator - Remote Server Name	Text	None	Name of the Siebel Server on which you are running a dedicated Siebel Product Configurator server. If you are using multiple dedicated Siebel Product Configurator server, then separate the entries with semicolons (;).
eProdCfgTimeOut	Product Configurator - Time Out of Connection	Integer	20	Setting in seconds that determines for how long the Siebel Server would try to initiate a connection with the remote Siebel Product Configurator server before returning an error to the user.
eProdCfgKeepAliveTime	Product Configurator - Keep Alive Time of Idle Session	Integer	900	Setting in seconds to determine the maximum interval of inactivity during a configuration session. If the interval of inactivity reaches this value, then the user session is ended and the worker returns to the pool. If this parameter is not set, then an infinite interval is assumed. Set this parameter on the Application Object Manager only. It does not apply on the remote Siebel Product Configurator server. Note: On the remote Siebel Product Configurator server (eProdCfgObjMgr component), set the parameter ConnIdleTime to a value like eProdCfgKeepAliveTime plus 1 second.

Siebel Workflow Deployment Planning

Siebel Workflow lets you define, manage, and enforce your business processes or workflows. It allows you to design complex workflow processes and automate the enforcement of business policies and procedures. This module includes the following:

Workflow Processes. This module lets you define your company’s business processes using a familiar flowcharting interface. A workflow process consists of one or more process steps, such as start steps, subprocesses, decision points, and tasks. You configure workflow processes using the Process Designer in Siebel Tools.
Workflow Policies. This module lets you define policies that can act as triggers to execute a process. A policy consists of conditions and actions. When policy conditions are met, the policy action executes the relevant process.
State Models. This module is used for defining business object states and state transitions.

For information about using and administering Siebel Workflow, see Siebel Business Process Framework: Workflow Guide.

Each user request to the Workflow Process Manager starts a new thread. However, sessions for Object Manager components (such as EAI Object Manager or Application Object Manager) that might invoke workflow processes are cached and reused for subsequent requests. When you size a deployment of Siebel CRM applications, the maximum number of workflow tasks that you expect to have active at a given time helps determine the maximum number of Object Manager sessions created for Siebel applications.

The exact CPU and memory consumption of each task depends on the actions performed in your workflow processes. To estimate CPU and memory consumption in your production environment, run a single task, measure its resource consumption, and make an estimation based on your maximum concurrent sessions. Take session caching into account when making these measurements.

If you need a large number of sessions, then you might want to run Workflow Process Manager on multiple Siebel Server computers. You can then load-balance requests across the Siebel Servers. If you plan to run a significant number of tasks per server (such as 100 or more), then you might also want to run multiple multithreaded processes.

If you are going to run several different types of workflows, then run each type in a separate process. Doing so makes it easier to monitor the overall CPU and memory usage of each process type.

The number of multithreaded processes and the number of tasks for each process are controlled through the parameters MaxMTServers (Maximum MT Servers), MinMTServers (Minimum MT Servers), and MaxTasks (Maximum Tasks).

These parameters are for each Siebel Server. For example, MaxMTServers refers to how many multithreaded processes to run on each Siebel Server computer.

For more information about server components, see Siebel System Administration Guide.

Planning Batch Processing When Using Siebel Remote

Long-running batch jobs can create transaction gaps in the Master Transaction Log for the Siebel Remote module for Oracle’s Siebel CRM. If the wait-time for the missing transactions expires, then the Transaction Processor component skips the missing transactions. The skipped transactions are not routed to mobile users.

Batch jobs could be performed by Siebel Assignment Manager, Siebel EIM, or other components.

For more information to help you to understand gaps in the Master Transaction Log, see 477585.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 499.

For an example with Siebel Assignment Manager, gaps in the Master Transaction Log can occur as follows:

Assignment Manager is processing a batch of transactions.
Assignment Manager obtains a group of transaction IDs. These are issued in numeric, sequential order.
Assignment Manager then commits these transactions. This process takes several minutes.
In the meantime, another process obtains a transaction ID.
The process commits the transaction and writes it to Siebel Remote’s Master Transaction Log. A sequence gap is created because the Assignment Manager transactions have not yet been written to the Master Transaction Log.
Transaction Processor detects the gap and waits a specified period called the wait-time (default is 600 seconds).
The wait-time expires before Assignment Manager completes the commit operation and writes the missing transactions to the Master Transaction Log.
When the wait-time expires, Transaction Processor skips the missing transactions and moves on to the transaction from the other process.
Transaction Processor logs information about the missing transactions. The Assignment Manager transactions are not routed to mobile users, even though they are later written to the Master Transaction log.

This topic contains the following information:

Conditions That Can Cause Missed Transactions

The following conditions in Assignment Manager can cause increased commit times. Longer commit times increase the risk that the Transaction Processor wait-time expires before the commit occurs and that Transaction Processor fails to process all of the transactions in the transaction log.

This topic is part of Planning Batch Processing When Using Siebel Remote.

Increasing the Assignment Manager Batch Commit Parameter

The default batch commit size (BatchSize) for Assignment Manager is 100. After processing 100 rows, transactions are committed to the database. If the batch commit size is increased, then this increases the risk of exceeding the wait-time.

Increased Number of Batch Assignment Threads

When multiple Assignment Manager threads are logging transactions, this creates a latency in accessing the transaction log table. This latency increase the risk of exceeding the wait-time.

Complicated Assignment Rules

When Assignment Manager has to resolve complicated assignment rules, this can increase commit times. Longer commit time together with the preceding conditions can increase the risk of exceeding the wait-time.

Avoiding Missed Transactions

To avoid exceeding the Transaction Processor wait-time during batch processing, adopt the following recommendations. Experiment with applying them in combination to achieve the best performance while minimizing the risk of exceeding the wait-time.

This topic is part of Planning Batch Processing When Using Siebel Remote.

Monitor the Transaction Processor Logs

As you apply the recommendations described as follows, use the Transaction Processor logs to see the result and help you to optimize system performance.

Transaction Processor writes these warning messages to its log file when it skips transactions:

GenericLog: GenericError: 0003-11-18 17:04:51
WARNING: A transaction gap has been detected after transaction 122.
Probable Cause: There maybe long-running transactions in your system which are not 
committing transactions within the specified duration (600 sec)
Recommendation: Reduce the batch size of your transactions. This will allow the 
transactions to be committed to the database within the wait-time window.

If skipped transactions occur while a batch job is running, then investigate the cause. The skipped transactions might not have been routed to mobile users. If so, then the mobile users might have to re-extract the database.

Set a Lower Batch Size for Assignment Manager

Setting a lower BatchSize value reduces the number of records processed before each commit. Reducing this figure reduces the commit times and the risk of exceeding the wait-time. If your performance goals require you to increase the BatchSize parameter, then do so only after analyzing the number of Assignment Manager threads that you have under average and peak workloads. The fewer Assignment Manager threads, the higher that you can set the BatchSize parameter.

You can get performance statistics on threads by raising the Assignment Manager log level. For information about raising the log level, see Siebel System Monitoring and Diagnostics Guide.

Serialize Batch Jobs

Consider staggering the start time of batch jobs. Running batch jobs in staggered or serial order can reduce the risk of exceeding the wait time.