1. Deployment Planning Guide
  2. Recommendations for Collocating Server Components

Recommendations for Collocating Server Components

This topic is part of Mapping Siebel CRM Deployment Elements to Platforms.

When deciding which server components to collocate, consider the following recommendations:

  • You use the Siebel Enterprise Server installer to install all of the server modules for your Siebel CRM applications deployment. Many installation characteristics have changed significantly as of Siebel CRM 21.2, as described in Siebel Installation Guide. Siebel Server, Siebel Gateway, Siebel Application Interface, and other server modules are always installed for any installation of Siebel Enterprise Components. Installed modules are available to be configured and deployed using Siebel Management Console, as you choose. You must keep track of which installed modules you are configuring and deploying, and where they are deployed.

    You might choose to deploy some of these modules together as part of the same installation (collocate them), install and deploy modules in separate installation locations on the same computer or operating system instance, or install and deploy them on different computers. In production environments, and particularly in large deployments, it is generally recommended to deploy modules separately, whether on the same computer or on different computers. The different deployment options present different benefits and risks, particularly related to availability and reliability in the event of computers requiring restart, or of shared application containers requiring restart. Some decision factors for collocating Siebel Server components or component groups are also noted in this topic.

  • Where Siebel Server and Siebel Gateway are installed and deployed together (collocated), they share the same application container. If the application container is shut down or restarts, then this affects all modules sharing the application container, severely limiting availability and reliability for these modules. Siebel Application Interface uses its own application container even where it is collocated with Siebel Server or Siebel Gateway.

    Assume, for example, that Siebel Server and Siebel Gateway are collocated. If, on the Siebel Server, there are issues with outbound REST or SOAP on UNIX, JBS (Java Business Services), or inbound email using the email servlet, or if there are heavy loads for these features, then restarting the application container can impact the Siebel Gateway or Siebel Web Clients. Installing, configuring, and removing Siebel Servers also use the application container. Note, however, that restarting the application container does not present issues where Siebel Server and Siebel Gateway are not collocated, or where these modules are collated but where operations of these types do not apply. Customers must consider such factors, among others, when planning their Siebel CRM deployment topology and before installing and deploying Siebel CRM server modules.

  • As you plan your Siebel CRM topology, you must also plan for the input that you must provide when you run the Siebel CRM installer or run Siebel Management Console, including data such as port numbers used by Siebel modules. You must anticipate various installation and configuration requirements. You must have a security and authentication framework in place to be able to install and configure the Siebel software. After your installations are done, you must install the Siebel database and configure various installed Siebel modules. Using Siebel Management Console, you can configure the Siebel Gateway, Siebel Enterprise, Siebel Server, Siebel Application Interface, and other modules. The Siebel Gateway, Siebel Server, and Siebel Application Interface need to be able to communicate with one another in order to configure and operate your installed software.

    For more information, see Siebel Installation Guide and Siebel Security Guide.

  • Install the Siebel Document Server on a dedicated server. Siebel Document Server uses Microsoft Word to create documents. Because Word is a single-threaded process, Siebel Document Server could block other processes running on the same server.

  • Consider what time of day a component is used. For example, a typical scenario is to run Siebel EIM batch jobs during off-peak hours. Doing this means Siebel EIM can be collocated with a server that is busy during peak hours. You can collocate components running off-peak with on-peak components for server consolidation purposes.

  • Collocation architecture decisions are driven by the load placed on each component and the overall size of the deployment. Consider this scenario: an implementation plan involves having 1000 connected users with light Assignment Manager usage, light Siebel Workflow usage, heavy off-peak Siebel EIM batch jobs, and a moderate Communications Server load. This implementation also requires some degree of high availability and resiliency. One possible architecture solution would be as follows:

    • Clustered Siebel Gateway. Collocated Siebel File System, Assignment Manager, Workflow Monitor Agent, and Communications Server. You can also configure Siebel Gateway clustering using Siebel Management Console, as noted in Defining High Availability Policies.

    • Multiple, load-balanced Siebel Application Object Managers. The number of servers required depends on the level of configuration and scripting complexity.

  • You can choose to engage Oracle’s Application Expert Services to perform an architecture and sizing review early in the implementation process. Once key metrics are known (user count, data volume, transaction volume, interfaces, and so on), you can determine the architecture and size of the Siebel CRM deployment. Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.

  • Some components are complex to size (for example, Siebel Product Configurator) and require expertise to determine an appropriate architecture and distribution of components. It is always necessary to have a thorough understanding of your customizable products and how they are used.

  • It is common practice in a large implementation (with thousands of users) to dedicate a server (usually a set of servers) to one function. Doing this makes it easier to monitor the performance of each segment of the implementation and makes it easier to scale each subset of the architecture. In a large implementation, Application Object Managers, Workflow, EAI, Assignment Manager and Siebel Product Configurator would all run on dedicated servers. Instances of Siebel Gateway and Siebel Application Interface would also run on dedicated hardware.

  • When there are more than a relatively small number of remote users (100 or so), run server components from the Siebel Remote (alias Remote) and Disconnected Mobile Synchronization (alias MobileSync) component groups on a dedicated server. Planning considerations must include the total number of remote users, the expected data volume transferred between the enterprise database and the remote client, and the quantity of visibility events.

    Visibility events include adding or removing a position to an account team, adding or removing a user to a position, and so on. When a visibility event occurs, it can cause a great deal of Siebel Remote activity.

  • In general, it is important to identify those processes with the potential for spikes of resource consumption and spread the load accordingly.

Related Books

Siebel Installation Guide

Siebel Security Guide