2 Siebel CRM Architecture and Infrastructure

This chapter provides an overview of Oracle's Siebel CRM architecture and infrastructure and provides introductory information about tuning the Siebel CRM applications for performance and scalability. It contains the following topics:

• About Performance and Scalability
• About Siebel Architecture and Infrastructure
• Siebel Architecture and Infrastructure Areas for Tuning
• About Siebel User Request Flow
• Performance Tuning Terminology
• Sizing Considerations for Siebel CRM Version 17.0 and Later

Related Books

Siebel Deployment Planning Guide

Siebel Installation Guide for the operating system you are using

Siebel System Administration Guide

Using Siebel Tools

Configuring Siebel Business Applications

About Performance and Scalability

Every implementation of Siebel CRM is unique. Your Siebel application architecture, infrastructure, and configurations might differ depending on your business model.

Performance and scalability are defined as follows in the context of this guide:

• Performance. A Siebel application's ability to function, generally measured in response time or throughput. For example, measures of performance might include the time required to log in to the Siebel application or to display a Siebel view in the Siebel Web Client, or the volume of transactions (sometimes referred to as requests) that a server component can process in a given time period. Some typical inhibitors of performance are inadequate hardware, excessive network round trips, heavy customizations, and poor networking infrastructure.
• Scalability. A Siebel application's ability to continue to perform well as volumes increase. Scalability is generally measured in hardware terms; for example, maintaining acceptable performance after adding new processors on existing computers (vertical scalability) or new Siebel Server computers (horizontal scalability) to process an increased number of users. Some typical inhibitors of scalability are an inflexible application module structure and an inability to run parallel processes.

For more definitions of terminology related to performance and scalability, see Performance Tuning Terminology.

About Siebel Architecture and Infrastructure

This topic shows a generic representation of the architecture and infrastructure of a Siebel CRM deployment. Your Siebel applications might be deployed differently. For descriptions of individual entities included in this illustration, see Siebel Deployment Planning Guide , Siebel System Administration Guide , and the Siebel Installation Guide for the operating system you are using .

Siebel Architecture and Infrastructure Areas for Tuning

The following list provides information about tuning some specific areas of the Siebel applications architecture and infrastructure.

Performance in many of these areas can be monitored and analyzed using Siebel Application Response Measurement (Siebel ARM), which is described in Monitoring Siebel Application Performance with Siebel ARM and Analyzing Siebel ARM Data.

• Siebel Application Object Managers. Siebel Application Object Managers are Siebel Server components that reside on a Siebel Server and support users accessing Siebel applications through the Siebel Web Client and the Siebel Application Interface, or through external applications. Running Siebel Application Object Manager components has significant performance and scalability implications. In general, the goal for tuning a Siebel Application Object Manager is to maximize scalability with little or no performance degradation as more users use Siebel applications. Although Siebel Application Object Manager components can be tuned for optimal performance, capacity for this and all other Siebel Server components is ultimately limited by Siebel Server computer resources such as CPU and memory. For more information about tuning this area, see Tuning the Siebel Application Object Manager for Performance.
• Siebel Web Client. The means for end users to access Siebel application features and data. Siebel Web Client uses a Web browser. Siebel applications like Siebel Call Center or Siebel Self Service, Siebel Web Tools, and Siebel Mobile applications on mobile devices all use the Siebel Web Client. The response time experienced by the Siebel Web Client end user is subject to the configuration and tuning of Siebel Enterprise elements such as the Siebel Application Object Manager, network bandwidth and latency, the Siebel Application Interface, the Siebel database, and the Siebel application configuration (represented in the Siebel runtime repository). It is also subject to local computer resources and settings, including browser settings such as those for caching. For more information about tuning this area, see Tuning Siebel Web Client for Performance. See also Tuning Customer Configurations for Performance.
• Siebel Communications Server. Siebel Communications Server provides an infrastructure to support several kinds of communications activities for Siebel CRM users, including session communications (such as voice calls) and inbound and outbound communications (such as email). Siebel Communication Server processing can affect end user response time, and might demand additional Siebel Application Object Manager resources to support user sessions. Performance and scalability is subject to third-party server configuration and capacity and Siebel Server computer resources and configuration. For more information about tuning this area, see Tuning Siebel Communications Server for Performance.
• Siebel Workflow. Siebel Workflow is an interactive environment that automates business processes such as automating escalation of events and notification of appropriate parties; routing and assigning work; processing work; and enforcing authorization and transition rules. Siebel Workflow processing can affect end user response time (for synchronous requests), and might demand additional Siebel Application Object Manager resources to support user sessions. Performance and scalability is subject to Siebel Server computer resources and configuration. For more information about tuning this area, see Tuning Siebel Workflow for Performance.
• Siebel Product Configurator. Siebel Product Configurator supports order management and product configuration functions for Siebel applications. Siebel Product Configurator processing can affect end user response time (for configuration sessions), and might demand additional Siebel Application Object Manager resources to support user sessions. Performance and scalability is subject to Siebel Server computer resources and configuration. For more information about tuning this area, see Tuning Siebel Product Configurator for Performance.

Note: The Siebel Constraint Engine provides an integration with Oracle Advanced Constraint Technology for Siebel Product Configurator. This integration, an alternative to the traditional product configuration solution, is available as a developer preview. For more information about the role of the Siebel Constraint Engine in the product configuration process and about deploying Siebel Constraint Engine, see Siebel Product Administration Guide and 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 Oracle Advanced Constraint Technology, see product documentation on the Oracle Help Center.

About Siebel User Request Flow

The following diagram illustrates how a user request is processed within the Siebel CRM architecture and infrastructure (generically presented), and shows potential areas for performance tuning. For a description of each portion of this data flow, see Siebel System Administration Guide and other relevant documents on the Siebel Bookshelf .

A typical Siebel CRM client request flows from the user's Siebel Web Client through the system, and back again, following the general flow outlined below.

1. A user performs an action that initiates a request. For example, the user clicks a link in the Site Map to navigate to a particular view. The request is generated by the Web browser and Siebel Web Client framework.
2. The request goes through the network, using a new or an existing HTTP connection, to the Siebel Application Interface. The request might go through a network router, proxy server, cache engine, or other mechanism.
3. The Siebel Application Interface receives the HTTP request and determines that it is a Siebel application request.
4. The Siebel Application Interface parses the HTTP message and generates a SISNAPI (Siebel Internet Session Network Application Programming Interface) message, based on the content of the HTTP message. Siebel Application Interface also parses the incoming cookie to obtain the user session ID. The Siebel Application Interface and Siebel Gateway work together to provide Siebel Server load balancing. When a user requests a new application connection, Siebel Application Interface sends a request to Siebel Gateway, which returns a connect string for the least-loaded Application Object Manager from among the Siebel Servers supporting that component. The user session will use this Application Object Manager. SISNAPI is a messaging format that runs on top of the TCP/IP protocol. It is used for network communication between Siebel Servers and Siebel Application Interface. SISNAPI connections use encryption and authentication based on Transport Layer Security (TLS).
5. On the Siebel Server, the SCBroker component receives the initial request for a session and forwards it to a Siebel Application Object Manager process. Subsequent communication for the session does not use SCBroker. For more information, see Siebel Application Object Manager Infrastructure and related topics.
6. The Siebel Application Object Manager receives and processes the SISNAPI message sent from Siebel Application Interface. If a database query is needed to retrieve the information, the Siebel Application Object Manager formulates the SQL statement and sends the request to the Siebel database over a database connection. The database request goes through the database connection, using a protocol format that is specific to the database connector.
7. The database executes the SQL statement and returns data back to the Siebel Application Object Manager. The Siebel Application Object Manager forwards the message to the Siebel Application Interface that originated it.
8. The Siebel Application Interface receives the SISNAPI message, and translates it back to HTTP. The message is now in the form of Web page content.
9. The Siebel Application Interface load balancing configuration, if present, then forwards the Web page content through the original HTTP connection to the end user's Web browser.
10. The Web browser and the Siebel Web Client framework process and display the return message.

Performance Tuning Terminology

This topic provides definitions of specific terms related to performance and tuning Siebel CRM. For definitions of and , see About Performance and Scalability.

For more information about some of these terms and concepts (including concurrent users and think time) in the context of tuning Siebel Application Object Manager components, see Performance Factors for Siebel Application Object Manager Deployments.

Table Performance Tuning Terminology

The number of application users actively using and accessing the Siebel application, or a particular element, such as a Siebel Application Object Manager process, at a particular time. It is useful to distinguish between concurrently connected users and concurrently active users: both sets of users consume memory, but only active users consume CPU (processor) resources.

Delay experienced in network transmissions as network packets traverse the network infrastructure.

The wait time between user operations. For example, if a user navigates to the Account screen and reviews data for 10 seconds before performing another operation, then the think time in this case is 10 seconds.

Average think time is a critical element in performance and scalability tuning, particularly for Siebel Application Object Manager. When think time values are correctly forecasted, then actual load levels will be close to anticipated loads.

An operating system (OS) process. For example, a Siebel Server component such as Siebel Application Object Manager consists of multiple OS processes, referred to as multithreaded processes.

Multithreaded process (or MT server)

A process running on a multithreaded Siebel Server component that supports multiple threads (tasks) per process. Siebel Application Object Manager components run multithreaded processes that support threads.

A concept for Siebel applications of a unit of work that can be done by a Siebel Server component. Siebel tasks are typically implemented as threads.

An operating system feature for performing a given unit of work. Threads are used to implement tasks for most Siebel Server components. A multithreaded process supports running multiple threads to perform work such as to support user sessions.

Amount of time the Siebel application takes to respond to a user request, as experienced by the end user. Response time is an aggregate of time incurred by all server processing and transmission latency for an operation. Response time is based on processing related to the request and to processing for other requests that might affect this user request.

Typically expressed in transactions per second (TPS), expresses how many operations or transactions can be processed in a set amount of time.

Sizing Considerations for Siebel CRM Version 17.0 and Later

This topic provides information about sizing considerations for Siebel CRM version 17.0 and later releases, relative to prior releases. The information in this topic supersedes or modifies similar information provided elsewhere in this guide.

Sizing for Siebel CRM Tier

Siebel CRM version 17.0 introduced new business agility and cloud support capabilities, including the following:

• Siebel Application Interface, a new module, replaces Siebel Web Server Extension. Siebel Application Interface is a Java module conforming to the Java EE Web Profile standard and can run on any compliant application container (Web container). It is currently certified on and includes Apache Tomcat.
• Siebel Gateway replaces the previous module by the same name. The Siebel Gateway registry, based on Apache ZooKeeper, replaces the siebns.dat file.
• Siebel CRM server modules now use application containers on Apache Tomcat and Siebel REST API calls as part of the framework for configuration using Siebel Management Console (which replaces the Siebel Configuration Wizard) and for regular operations.

Both Siebel Application Interface and Siebel Gateway support distributed topologies, using Siebel Application Interface load balancing or Siebel Gateway clustering. For more information about these and related product changes, see the Siebel Installation Guide for the operating system you are using and Siebel Deployment Planning Guide .

For this release and subsequent Siebel CRM 18.x and 19.x Update releases, more memory and CPU are required compared to prior releases for Siebel Application Interface, Siebel Gateway, and Siebel Server. The following are observations made during the performance and scalability tests performed by Oracle:

• Siebel Application Interface. The minimum memory (RAM) required for the Java Virtual Machine (JVM) heap size was observed to be 4 GB. The CPU usage is about 1% per 1000 users and an additional 5% average CPU in case of a high login rate.
• Siebel Gateway. The minimum memory required for the JVM heap size was observed to be 4 GB. The CPU usage is about 1% to 2% after the Siebel Servers have started (4% maximum CPU) and an additional 5% average CPU in case of a high login rate. The same recommendations apply for each node. Example for configuration:
  • As of Siebel CRM 19.1 Update, it is recommended to set the JVM heap size minimum and maximum to 4 GB on Siebel Application Interface and Siebel Gateway.
  • On Microsoft Windows, you can set the JVM options using the tomcat8w utility. You must also specify the name of the service to which your setting applies. This utility is located in the SIEBEL_ROOT \applicationcontainer\bin directory. Alternatively, you can set the heap size in setenv.bat to 4 GB (-Xms4096M -Xmx4096M). This batch file is located in the SIEBEL_ROOT \applicationcontainer\bin directory.
  • On UNIX operating systems, set the heap size in setenv.sh to 4 GB (-Xms4096M -Xmx4096M). This shell script is located in the SIEBEL_ROOT /applicationcontainer/bin directory.

  Several issues, fixes, and recommendations in these areas are reflected in corresponding alert articles available on My Oracle Support. For more information about configuring JVM options, see 2472920.1 (Article ID) on My Oracle Support. See also the Java documentation from Oracle. For information about stopping and starting the application container and related information, see the Siebel Installation Guide for the operating system you are using and Siebel System Administration Guide .

  The preceding information regarding CPU requirements assumes two sockets Hexacore Intel Xeon CPU X5670@2.93 GHz, and a total of 12 cores.

  Note: The sizing information in this topic is based on consolidation of several Siebel CRM performance and scalability tests. Actual results may vary, based on a broad range of implementation-specific factors, such as application configuration and customization, transaction mix, duration of each request, login storms, frequent incoming EAI requests requiring a new login, hardware or operating system platform, network parameters, database size, and so on. Oracle does not warrant or guarantee that customers will obtain the same or similar results. It is strongly recommended that you thoroughly test your Siebel CRM applications by performing performance and scalability testing with the expected volumes to determine your specific resource requirements. Oracle does not share the details of its internal tests. To address your requirements, it is strongly recommended that you engage Oracle Advanced Customer Support to do the sizing based on those needs.

  Monitoring

  The following information describes how to monitor the usage of JVM heap size and other important metrics, such as the number of concurrent threads or other performance factors. For the run-time heap usage and thread usage information, Oracle used the Java Mission Control utility and connected to the remote JVM. To enable JMX remote on UNIX operating systems, add the following arguments to the setenv.sh file for the Siebel Gateway and Siebel Application Interface installations. After enabling JMX remote, you can monitor heap usage, threads, and other metrics using the Java Mission Control dashboard (for example, you can add graphs).

  -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=7777 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -XX:+UnlockCommercialFeatures -XX:+FlightRecorder

  Setting Up Garbage Collection Logs

  The table below describes parameters that you can optionally specify to capture garbage collection logs for troubleshooting purposes.

  Enables logging of garbage collection (GC) information.