Do you want to Search Something?

Those who opened the gates

Wednesday, December 28, 2011

Components for Email Response in Siebel

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.

Key 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 may 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.

An Overview about Server Clustering

About Server Clustering

A server cluster is a group of two or more servers that are configured so that if one server fails, another server can take over application processing. The servers in a cluster are called nodes. Typically, these servers store data on a common disk or disk array.
Clustering software monitors the active nodes in a server cluster. When a node fails, the clustering software manages the transition of the failed server's workload to the secondary node.
When a clustered Siebel Server fails, all the applications and services on the server stop. Application users must reconnect and log in to the server that takes over. For example, if the Siebel Server that failed was hosting Siebel Communications Server, the communications toolbar is disabled, and users must reconnect and log in to the new server.
Cluster vendors can validate their third-party server cluster products to provide server clustering for deployments of Siebel Business Applications. For validation assistance, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert Services. For recommendations and help on the use of cluster products with Siebel Business Applications, customers should contact the cluster vendor of their choice.

Active-Passive Configuration

An active-passive server cluster contains a minimum of two servers. One server actively runs applications and services. The other is idle. If the active server fails, its workload is switched to the idle server, which then takes over application processing.
Because the standby server is idle, active-passive server clusters require additional hardware without providing additional active capacity. The benefit of active-passive clusters is that, after a failover, the same level of hardware resources is available for each application, thereby eliminating any performance impact on users. This benefit is particularly important for performance-critical areas such as the database. The most common use of active-passive clusters is for database servers.

Active-Active Configuration

An active-active server cluster contains a minimum of two servers. Both actively run applications and services. Each may host different applications or may host instances of the same application. If one server fails, its processing load is transferred to the other.
Active-active configuration is the most common server clustering strategy for servers other than the database server.
NOTE:  Configuring the Siebel Database (database server) and a Siebel Server to failover to each other is supported, but not recommended.
Potential Port Conflicts
Some Siebel Server components, such as Siebel Connection Broker (SCBroker), Siebel Gateway Name Server, Synchronization Manager (Siebel Remote), and Siebel Handheld synchronization listen on a configurable static port. When these components run in an active-active cluster, you must plan your port usage so there is no port conflict after failover.
For example, an active-active server cluster contains two platforms, each running a Siebel Server. If one platform fails, the other will host two Siebel Servers. Siebel Servers include several services, such as Siebel Connection Broker, that use a dedicated port. If this port number was the same on both platforms, there will be a port conflict after failover.
Capacity Planning
Active-active clusters use all the server platforms continuously. Consequently, they take better advantage of computing resources than active-passive clusters. When doing capacity planning, make sure that clustered servers have sufficient capacity to handle a failover. Because failovers are usually infrequent and normally last only a short time, some performance degradation is often acceptable.

Thursday, December 15, 2011

How to enable a Component Group on Siebel Server


To enable a component group on a Siebel Server
Navigate to Administration-Server Configuration screen, Enterprises, and then the Component Groups view.
In the Component Groups list, select the Siebel Server component group of interest.
In the Component Groups Assignment list, select the Siebel Server of interest.
Click the Enable button.
The Enabled on Server? field of the Siebel Server record becomes checked.
For the change to take effect, stop and restart the Siebel Server System Service.

Tuesday, December 13, 2011

Implementing ACRs In Siebel

ACRs are enhanced functionalities provided as a part of patch installation.
A list of various ACRs will be available in the Siebel Maintainance Release Guide which are updated and various revisions are available in support web.
ACRs are usually found as a Zip file in the local installation of Tools in a folder called REPPATCH.eg:
C:/Siebel/Tools/REPPATCH.
These zip files usually contain archive files of seed objects like Applet,Views,Table,Webtemplate files etc.
ef ACR 374 to configure IMAP protocol