Overview
Bucher + Suter (b+s) Connects for Siebel is a pre-packaged integration of Oracle's Siebel CRM and Cisco's Unified Contact Center Enterprise (UCCE), Unified Contact Center Hosted (CCH) or Unified Packaged Contact Center Enterprise (PCCE) solution. It is a centralized process that manages the real time flow of interactions between the Siebel desktop user interface and Cisco's CCE/CCH. CCE/CCH utilizes the b+s Connects for Siebel to route phone calls, emails and chats to the best skilled agents, who can accept and manage these interactions using their Siebel Web Client.
b+s Connects for Siebel Components
b+s Connects for Siebel is the umbrella term of the Siebel CRM to CCE/CCH integration solution. It consists of the following six components:
b+s Communication Toolbar Adapter (Communication Toolbar Adapter)
The Communication Toolbar Adapter is a Dynamic-link library (DLL) implementing the Adaptive Communication API Interface of Siebel. The Communication Toolbar Adapter DLL is loaded and started by the Siebel Communication Session Manager. Depending on the Siebel configuration, the Communication Session Manager starts multiple times in parallel. Each instance loads an instance of the Communication Toolbar Adapter DLL.b+s ConnectMCAL (ConnectMCAL)
ConnectMCAL (Multi Channel Application Link) is a Web service interface used to connect to Cisco CCE/CCH for using CTI functionality of the voice channel and to MediaManager for media channels. Sometimes MCAL is used as a synonym for the two components ConnectMCAL and MediaManager. ConnectMCAL can be configured to offer the interface as SOAP Web service or as TCP binding interface. The b+s Connects for Siebel uses the TCP binding interface.b+s MediaManager (MediaManager)
MediaManager is a software component which allows ConnectMCAL to connect to the CCE/CCH media routing interfaces ARM and MRI.b+s DataStore (DataStore)
To allow screen transfer from one agent to another, a large block of data (up to 16KB) and a Siebel Bookmark, needs to be transferred along with the call task. Because in CCE/CCH the size of call context data is limited and cannot transport this data, the data is saved to the DataStore and a unique ID referencing this data is stored in CCE/CCH call context. In this way, the Siebel bookmark can be transferred from one Communication Toolbar Adapter to another, while the Communication Toolbar Adapter is running on the same or another Siebel Communication Server. Please note that the Siebel bookmark used to transfer the screen along a chat transfer is not stored on the DataStore but remains in Siebel, more precisely next to the chat transcript.b+s Siebel RoutingAdapter (Siebel RoutingAdapter)
The Siebel RoutingAdapter is a standalone service that offers a Web service interface to be called by Siebel for routing an ERMS mail. Furthermore, the Siebel RoutingAdapter itself calls a Web service in Siebel to update the routing state of emails.b+s ChatConnector (ChatConnector)
The ChatConnector is a software component which connects the MediaManager component to a chat server using the eXtensible Messaging and Presence Protocol (XMPP).
ConnectMCAL, MediaManager, DataStore and the Siebel RoutingAdapter form together the so-called Central Components.
Overall Siebel Architecture
Figure High Level Siebel Architecture shows a simplified generic representation of the architecture and infrastructure of a Siebel Business Applications deployment. The most important Siebel components which are used for a generic multichannel b+s Connects for Siebel deployment are described below. For detailed information about the different Siebel components see Siebel Deployment Planning Guide, Siebel System Administration Guide, and the Siebel Installation Guide for the operating system you are using.
- Siebel Web Client: The means for end users (i.e. agents) to access Siebel application features and data via a modern Web browser.
Each Siebel Server functions as an application server and is composed of server components. Each server component performs a defined function.
Siebel Application Object Managers: Siebel Server components that reside on a Siebel Server and support users/agents accessing Siebel applications through the Siebel Web Client and a Web server, or through external applications.
Siebel Communications Server: Provides an infrastructure to support several kinds of communications activities for Siebel Business Applications users/agents, including session communications (such as voice calls) and inbound and outbound communications (such as email).
Siebel Enterprise Application Integration (Siebel EAI): Provides components for integrating Siebel Business Applications with external and internal applications, and provides inbound and outbound interfaces to and from a Siebel application. Used for email routing in conjunction with the b+s Connects for Siebel's RoutingAdapter.
Siebel Workflow: 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. Used for email routing in conjunction with the b+s Connects for Siebel's RoutingAdapter.
Siebel Communications Server
Siebel Communications Server provides an infrastructure to support several kinds of communications activities for Siebel application users/agents. The b+s Connects for Siebel's Communication Toolbar Adapter DLL uses the Adaptive Communications API of Siebel Communications Server to enable session-based/interactive communications so that Siebel users/agents who use the communications toolbar can make or receive voice calls and handle emails.
The Siebel Communications Management component group includes the following server components:
Communications Session Manager: Supports multichannel user-interactive sessions for agents using the communications toolbar for voice, email, or other types of work items.
Communications Configuration Manager: Loads and caches communications configuration data for agents using functions supported by Communications Session Manager.
Communications Inbound Receiver: Receives inbound work items and, in some deployments, queues them for processing by Communications Inbound Processor. Work items can include email messages (for Siebel Email Response).
Communications Inbound Processor: For deployments of Siebel Email Response supporting non-real-time work items, this component processes inbound work items that were queued by Communications Inbound Receiver.
Communications Outbound Manager: Processes outbound communications, for email, fax, wireless messages, or page channels. Supports communication requests, whether directly or through Siebel Workflow. Also supports outbound capabilities for Siebel Email Response and for the Send Email, Send Fax, and Send Wireless Message commands.
The Communication Toolbar Adapter DLL is loaded and started by the Siebel Communications Session Manager. Depending on the Siebel configuration, the Communications Session Manager starts multiple times in parallel. Each Communications Session Manager loads an instance of the Communication Toolbar Adapter DLL (see chapter Capacity and Scalability Considerations for further details).
Your Siebel implementation may not have all the components described below, depending on which software modules you have purchased.
b+s Connects for Siebel Architecture
Deployment Models
The modular architecture of the b+s Connects for Siebel solution offers a wide variety of deployment models. Each deployment model has its pros and cons regarding redundancy, complexity, management, costs etc. In theory, all components of the b+s Connects for Siebel Central Components can be installed on one single host or each component can have its own separate host. This does not apply to the b+s Connects for Siebel Communication Toolbar Adapter as it is not a self-running application but a DLL that must be installed on the Siebel Communication Server(s). In this chapter, deployment models of the b+s Connects for Siebel solution recommended by b+s are described.
Be aware that if you intend to operate the b+s Connects for Siebel in both a production and in a testing environment none of the b+s Connects for Siebel components can be shared! I.e. two completely separated installations of the b+s Connects for Siebel components are required where each environment has its own set of Communication Toolbar Adapter(s) and Central Components.
Single Agent Peripheral Gateway (PG) Deployments
Voice Channel Only
Voice, Email and Chat Channel
Multiple Agent Peripheral Gateways (PG) Deployments
For a deployment with multiple CCE/CCH Agent PGs, that form together one big virtual contact center, multiple Siebel Communications configuration entries and a separate Siebel profile for each entry is required. Furthermore, each CCE/CCH Agent PG requires its own redundant ConnectMCAL instance. Hostnames/IP addresses and ports of the ConnectMCAL instances are specified in the different Siebel profiles. Agents can be assigned to one primary Siebel Communications configuration entry only. For each Siebel Communications configuration entry you must edit the Siebel Definition File and import it again. Refer to Voice Configuration for further information concerning the required adjustments in the Siebel Definition file.
Voice Channel Only
The following picture illustrates the deployment of a multi Agent PG voice environment:
Multi Agent PG Voice Call Screen Transfer
The transfer of a Siebel view from one agent to another along a voice call only works for dedicated configurations in multi Agent PG deployments. The following table gives an overview of the supported and unsupported configurations:
| Agent A | Agent B | Warm Transfer Agent A -> Agent B | Supported |
|---|---|---|---|
| PG 1 | PG 2 | Direct to phone extension of agent B | NO |
| PG 1 | PG 2 | Via "external" route point external = PG 2 is configured as routing client in DN for RP | NO |
| PG 1 | PG 2 | Via "internal" route point internal = PG 1 is configured as routing client in DN for RP | YES |
Multi Channel
A multichannel deployment with multiple CCE/CCH Agent PG's is also possible. Each CCE/CCH Agent PG requires its own redundant MediaManager instance. And each MediaManager requires its own redundant CCE/CCH MediaRouting PG.
Take care about restrictions for multichannel deployments with multiple Agent PG's:
- The "big virtual contact center" approach, where an item (chat, email) is received on one site and can be distributed to any agent on any site, is not possible.
- The items (chat, mail) received on one site can only be routed to agents on the same site.
- Items (chat, mail) cannot be rerouted by an agent to another agent on another site.
Redundancy Considerations
- Communication Toolbar Adapter Depending on the Siebel configuration, multiple Siebel Communications Session Managers each with its own Communication Toolbar Adapter DLL can be started on the same Siebel Communication Server or distributed over multiple Siebel Communication Servers. Please refer to the chapter Multiple Communication Toolbar Adapter Instances for further information.
- ConnectMCAL ConnectMCAL can be deployed on two hosts to achieve hot-standby redundancy. One ConnectMCAL is started and active, the second is started but inactive as the Communication Toolbar Adapter communications with one ConnectMCAL at a time. In case of a failure of the connected ConnectMCAL (or the connection between the Communication Toolbar Adapter and ConnectMCAL) the Communication Toolbar Adapter establishes a connection to the other ConnectMCAL. Both ConnectMCALs connect to both CTI Servers which run on CCE/CCH Agent PG side A and CCE/CCH Agent PG side B. If the active CTI Server fails, the formerly idle connection to the other CTI Server becomes active. Furthermore, both ConnectMCAL connect to both MediaManager (one is active, the other idle). If the active MediaManager fails, the formerly idle connection to the other MediaManager becomes active.
- Siebel RoutingAdapter The Siebel RoutingAdapter can be deployed on two hosts to achieve cold-standby redundancy. One Siebel RoutingAdapter is started an active, the second is stopped and inactive. Both Siebel RoutingAdapter have the same configuration. If the active Siebel RoutingAdapter fails, the inactive has to be pointed to the correct Siebel Inbound Web Service (check configuration) and started manually. Furthermore, the URL of the appropriate Siebel Outbound Web Service must be updated so that the newly started Siebel RoutingAdapter is reachable.
- MediaManager The MediaManager component can be deployed on two hosts to achieve hot-standby redundancy. One MediaManager is started and active, the second is started and idle. On the Cisco MR PG, both MediaManagers are configured. If the active MediaManager fails, the idle MediaManager takes over automatically.
- ChatConnector The ChatConnector component can be deployed on two hosts to achieve cold-standby redundancy. One ChatConnector is started and active, the second is stopped and inactive. Both ChatConnectors have the same configuration (connection to one MediaManager and one chat server). If the active ChatConnector fails, the inactive ChatConnector has to be pointed to the correct MediaManager and chat server (check configuration) and started manually.
- DataStore The DataStore component can be deployed on two hosts to achieve hot-standby redundancy. The Communication Toolbar Adapter (or multiple if deployed) connects to both DataStores, A and B simultaneously.
Failover Behavior
Figure Redundant Deployment shows a redundant installation of the b+s Connects for Siebel with two separate Siebel Communications Session Managers, two MCALs (two ConnectMCALs with two MediaManagers), two DataStores, two Siebel RoutingAdapters, two ChatConnectors and a redundant CCE/CCH Agent PG. For the sake of simplicity not all Siebel and Cisco components are shown on this figure (e.g. Siebel Application Object Manager, Siebel Gateway Name Server, Siebel Web Server, Cisco CCE/CCH Central Controller, Cisco UCM are missing).
Service State Definitions
- ACTIVE means that the particular service is started and ACTIVE (i.e. the application is processing requests)
- INACTIVE means that the particular service is started and its overall state is ACTIVE but it does not process any message until a fail-over of its pair service occurs.
- IDLE means that the particular service is started but IDLE. If the ACTIVE service fails the IDLE service takes over and becomes ACTIVE
- STOPPED means that the particular service is stopped and must be started manually to become ACTIVE
With CCE/CCH version 10.0 Cisco Systems Inc. has announced that the /LOAD Configuration Parameter is considered as a deprecated feature. This means that no more engineering development will occur for this feature and that it will be scheduled for removal in a future CCE/CCH release. The new behavior is that agents are automatically set to not ready on CTI disconnects. Without the /LOAD Configuration Parameter the characteristics of fail over situations with the b+s Connects for Siebel are slightly different.
Failover behavior with /LOAD Configuration Parameter set to 0
The following list shows the fail-over behavior in case of an outage of one of the redundant components with no /LOAD Configuration Parameter set or with /LOAD Configuration Parameter set to 0:
Component: Communication Toolbar Adapter
Outage: Communication Toolbar Adapter 1
Fallback: Communication Toolbar Adapter 2
- Only agents that are logged in on the affected Communication Toolbar Adapter affected.
- All agents that are logged in on another Communication Toolbar Adapter instance are not affected by the outage.
- ConnectMCAL detects the outage after a configurable session timeout.
- ConnectMCAL is configured in a multi-instance mode and does not immediately log out the affected agents because they will be logged in again when the failed Communication Toolbar Adapter recovers or if the agent is logged in via another Communication Toolbar Adapter.
Component: MCAL
Outage: ConnectMCAL A
Fallback: ConnectMCAL B
- The Communication Toolbar Adapters disable all buttons on the Siebel Communications Toolbar and log out the agents.
- CCE/CCH sets the agents to not ready.
- The Communication Toolbar Adapters reconnect to ConnectMCAL B.
- The Communication Toolbar Adapters log the agents in again on ConnectMCAL B and re-enable the buttons on the Siebel communications Toolbar. The agents' states are the same as before the fail-over.
- Limitations:
- Agents are set to not ready after the recovered calls have ended, even if they were ready when they received the calls before the fail-over occurred.
- If wrap-up is enabled agents are always placed into work not ready after the recovered calls have ended, even if they were ready when they received the calls before the fail-over occurred.
- When using the sample Siebel Definition File that is shipped with the b+s Connects for Siebel, a new Siebel activity is created for recovered calls.
Component: MediaManager
Outage: MediaManager A
Fallback: MediaManager B
- If MediaManager A ceases to work properly, the idle MediaManager B automatically activates and ConnectMCAL and the CCE/CCH MR PG reconnect that instance.
- All queued media tasks are dropped during the MediaManager fail-over and need to be re-queued after the fail-over is complete.
- The media tasks and route requests that were active at the time the fail-over occurred are lost.
Component: CTI Server
Outage: CTI Server A
Fallback: CTI Server B
- ConnectMCAL informs the Communication Toolbar Adapters about the lost connection ("CTI server is offline2")
- The Communication Toolbar Adapters disable all buttons on the Siebel Communications Toolbar and log out the agents.
- CCE/CCH sets the agents to not ready.
- CTI Server B becomes active.
- ConnectMCAL reconnects to CTI Server B.
- ConnectMCAL informs the Communication Toolbar Adapters about the new CTI connection ("CTI server is online").
- The Communication Toolbar Adapters log the agents in again and re-enable the buttons on the Siebel Communications Toolbar.
- Limitations:
- Agents are set to not ready after the recovered calls have ended, even if they were ready when they received the calls before the fail-over occurred.
- If wrap-up is enabled agents are always placed into work not ready after the recovered calls have ended, even if they were ready when they received the calls before the fail-over occurred.
- When using the sample Siebel Definition File that is shipped with the b+s Connects for Siebel, a new Siebel activity is created for recovered calls.
Component: Agent PG
Outage: Agent PG A
Fallback: Agent PG B
- ConnectMCAL informs the Communication Toolbar Adapters about the lost connection ("CTI server is offline")
- The Communication Toolbar Adapters disable all buttons on the Siebel Communications Toolbar and log out the agents.
- CCE/CCH logs out the agents with reason code 50002
- Agent PG B becomes active.
- ConnectMCAL informs the Communication Toolbar Adapters about the re-established CTI connection ("CTI server is online").
- The Communication Toolbar Adapters log the agents in again and re-enable the buttons on the Siebel Communications Toolbar.
- Limitations:
- Agents are set to not ready after the recovered calls have ended, even if they were ready when they received the calls before the fail-over occurred.
- Agents are not placed into wrap-up after the recovered calls have ended
- When using the sample Siebel Definition File that is shipped with the b+s Connects for Siebel, a new Siebel activity is created for recovered calls.
Component: DataStore
Outage: DataStore A
Fallback: DataStore B
- The Communication Toolbar Adapters are connected to both DataStores and the Siebel bookmarks are sent to both DataStores when transferring/conferencing a call.
- If one DataStore goes down, the Siebel bookmark can still be stored to the other DataStore and the Siebel bookmark can also be read from this DataStore.
Component: Siebel RoutingAdapter
Outage: Siebel RoutingAdapter A
Fallback: Siebel RoutingAdapter B
- If Siebel RoutingAdapter A fails, new media task (except chats) cannot be routed anymore until Siebel RoutingAdapter B is up and running (manual startup required).
- The currently active media tasks (except chats) cannot be re-routed until Siebel RoutingAdapter B is up and running.
- The agents are still able to end, pause and resume work items of media tasks.
Component: ChatConnector
Outage: ChatConnector A
Fallback: ChatConnector B
- If ChatConnector A fails, new chat tasks cannot be routed anymore until ChatConnector B is up and running (manual startup required).
- All chat sessions currently in CCE/CCH queues are de-queued and cannot be recovered.
- All active chat sessions to agents are terminated.
Failover behavior with /LOAD Configuration Parameter set to 1
The following list shows the fail-over behavior in case of an outage of one of the redundant components with /LOAD Configuration Parameter set to 1:
Component: Communication Toolbar Adapter
Outage: Communication Toolbar Adapter 1
Fallback: Communication Toolbar Adapter 2
- Only agents that are logged in on the affected Communication Toolbar Adapter are affected.
- All agents that are logged in on another Communication Toolbar Adapter instance are not affected by the outage.
- ConnectMCAL detects the outage after a configurable session timeout.
- ConnectMCAL is configured in a multi-instance mode and does not immediately log out the affected agents because they will be logged in again when the failed Communication Toolbar Adapter recovers or if the agent is logged in via another Communication Toolbar Adapter.
Component: MCAL
Outage: ConnectMCAL A
Fallback: ConnectMCAL B
- The Communication Toolbar Adapters disable all buttons on the Siebel Communications Toolbar and log out the agents.
- CCE/CCH logs out the agents with reason code 50002
- The Communication Toolbar Adapters reconnect to ConnectMCAL B.
- The Communication Toolbar Adapters log the agents in again on ConnectMCAL B and re-enable the buttons on the Siebel Communications Toolbar. The agents' states are the same as before the fail-over.
- Limitations:
- No call data is recovered (ANI, dialed number, call variables, ECC variables, call type etc.)
- Recovered calls are displayed as "-> Call from " on the Siebel Communications Toolbar.
- Agents are set to not ready after the recovered calls have ended, even if they were ready when they received the calls before the fail-over occurred.
- Agents are not placed into wrap-up after the recovered calls have ended
- When using the sample Siebel Definition File that is shipped with the b+s Connects for Siebel, a new Siebel activity is created for recovered calls.
Component: MediaManager
Outage: MediaManager A
Fallback: MediaManager B
- If MediaManager A ceases to work properly, the idle MediaManager B automatically activates and ConnectMCAL and the CCE/CCH MR PG reconnect that instance.
- All queued media tasks are dropped during the MediaManager fail-over and need to be re-queued after the fail-over is complete.
- The media tasks and route requests that were active at the time the fail-over occurred are lost.
Component: CTI Server
Outage: CTI Server A
Fallback: CTI Server B
- ConnectMCAL informs the Communication Toolbar Adapters about the lost connection ("CTI server is offline")
- The Communication Toolbar Adapters disable all buttons on the Siebel Communications Toolbar and log out the agents.
- CCE/CCH logs out the agents with reason code 50002
- CTI Server B becomes active.
- ConnectMCAL reconnects to CTI Server B.
- ConnectMCAL informs the Communication Toolbar Adapters about the new CTI connection ("CTI server is online").
- The Communication Toolbar Adapters log the agents in again and re-enable the buttons on the Siebel Communications Toolbar.
- Limitations
- No call data except for the ANI is recovered (dialed number, call variables, ECC variables, call type etc.)
- Agents are set to not ready after the recovered calls have ended, even if they were ready when they received the calls before the fail-over occurred.
- Agents are not placed into wrap-up after the recovered calls have ended
- When using the sample Siebel Definition File that is shipped with the b+s Connects for Siebel, a new Siebel activity is created for recovered calls.
Component: Agent PG
Outage: Agent PG A
Fallback: Agent PG B
- ConnectMCAL informs the Communication Toolbar Adapters about the lost connection ("CTI server is offline")
- The Communication Toolbar Adapters disable all buttons on the Siebel Communications Toolbar and log out the agents.
- CCE/CCH logs out the agents with reason code 50002
- Agent PG B becomes active.
- ConnectMCAL informs the Communication Toolbar Adapters about the re-established CTI connection ("CTI server is online").
- The communication Toolbar Adapters log the agents in again and re-enable the buttons on the Siebel Communications Toolbar.
- Limitations:
- Agents are set to not ready after the recovered calls have ended, even if they were ready when they received the calls before the fail-over occurred.
- Agents are not placed into wrap-up after the recovered calls have ended .
- When using the sample Siebel Definition File that is shipped with the b+s Connects for Siebel, a new Siebel activity is created for recovered calls.
Component: DataStore
Outage: DataStore A
Fallback: DataStore B
- The Communication Toolbar Adapters are connected to both DataStores and the Siebel bookmarks are sent to both DataStores when transferring/conferencing a call.
- If one DataStore goes down the Siebel bookmark can still be stored to the other DataStore and the Siebel bookmark can also be read from this DataStore.
Component: Siebel RoutingAdapter
Outage: Siebel RoutingAdapter A
Fallback: Siebel RoutingAdapter B
- New media tasks (except chats) cannot be routed anymore until Siebel RoutingAdapter B is up and running (manual startup required).
- The currently active media tasks cannot be re-routed until Siebel RoutingAdapter B is up and running.
- The agents are still able to end, pause and resume work items of media tasks.
Component: ChatConnector
Outage: ChatConnector A
Fallback: ChatConnector B
- If ChatConnector A fails, new chat tasks cannot be routed anymore until ChatConnector B is up and running (manual startup required).
- All chat sessions currently in CCE/CCH queues are de-queued and cannot be recovered.
- All active chat sessions to agents are terminated.
Multiple Communication Toolbar Adapter Instances
For performance, scalability and redundancy purposes multiple Siebel Communications Session Managers each with its own Communication Toolbar Adapter DLL can be started on the same Siebel Communication Server or distributed over multiple Siebel Communication Servers.
Correct setup of the Siebel parameters MaxMTServers, MinMTServers, and MaxTasks on the Communications Session Manager component can reduce impact of Communications Session Manager Crashes or freezes and provide a more reliable running environment for the agents.
MaxTasks: Specifies the total number of tasks (threads) that can run concurrently on this Siebel Communications Session Manager for this Siebel Server. Beyond this number, no more tasks can be started to handle additional requests. In a contact center environment the number of tasks refers to the number of agents.
MaxMTServers: Specifies the maximum number of multithreading processes that can run concurrently on this Siebel Communications Session Manager. Beyond this number, no more multithreading processes can be started to handle additional requests.
MinMTServers: Specifies the default minimum number of multithreading processes that will start on this Siebel Communications Session Manager when the parent process is started. The parent process can be started either explicitly (using Siebel Server Manager) or automatically (if the Siebel Server is started when the component state was last set to Running). Setting MinMTServers to 0 effectively disables the Siebel Communications Session Manager component.
The default parameter settings for the Communications Session Manager are as follows:
MaxTasks: 20MinMTServers: 1MaxMTServers: 1
By increasing the MaxMTServers and MinMTServers parameters multiple instances of
Communications Session Manager are launched when the Siebel Server is started.
This way the agents will be distributed between the multiple instances and in
case of a Communications Session Manager Instance crash or freeze, only the
agents connected to this particular instance are affected.
MaxMTServers and MinMTServers are typically set to the same value. Doing this
avoids performance penalties for a user whose login causes a new multithreading
process to start. MaxMTServers must be equal to or greater than MinMTServers.
Starting all multithreading processes up front when the parent process is started
is generally acceptable. The memory overhead for running a multithreading process
itself, apart from the overhead of its threads, is minimal. The ratio MaxTasks
divided by MaxMTServers determines the maximum number of threads (tasks ->
agents) that can run concurrently on a given multithreading process.
When an agent logs in to a Communications Session Manager an instance of the Communication Toolbar Adapter DLL is loaded which creates a session to communicate with the b+s Connects for Siebel's DataStore and ConnectMCAL components. For every agent that logs in to the same Communications Session Manager/Communication Toolbar Adapter DLL the existing session is used. However, a new session is created by the Communication Toolbar Adapter DLL if one of the following session parameters differs from the ones used by an existing session.
MCALHostSideAMCALHostSideBMCALHostPortSideAMCALHostPortSideBMCALHostWebServiceNameSideAMCALHostWebServiceNameSideBMCALHostSideASecuredMCALHostSideBSecuredMCALUsernameMCALPasswordMCALSessionTimeoutAgentEventMaskCallEventMaskTaskEventMaskPopupNotReadyReasonsPopupLogoutReasonsPopupWrapupReasonsEnableVoiceEnableMediaOverrideSiebelLanguageCode
Example:
If 1200 agents are expected to work simultaneously the MaxTasks, MaxMTServers
and MinMTServers can be set as followed:
MaxTasks: 1200MinMTServers: 2MaxMTServers: 2
With these settings, there will be 2 Communications Session Manager Processes created, each with its own Communication Toolbar Adapter DLL, when the Siebel Application server starts. The first agent will log in to the first Communications Session Manager process and all of this user's subsequent requests will also use the first process. The second agent logs into the second process, the third agent will log in to the first process again since Siebel's Server Request Broker (SRB) component will pick the Communications Session Manager process based on the round-robin algorithm. If one Communications Session Manager Process fails for some reason a maximum of 600 users instead of all 1200 users will be affected.
Please check the Siebel Performance Tuning Guide and the Oracle support document How Do You Use the MaxMTServers and MinMTServers Parameters To Improve Stability of the Communications Session Manager and To Manage Multiple CommSessionMgr Processes? For more details concerning the parameters MinMTServers, MaxMTServers and MaxTasks.
Host System Requirements
As the Communication Toolbar Adapter Driver DLL is installed on Siebel Communication Server(s), please refer to the official Siebel documentation for software and hardware requirements.
The Central Components of b+s Connects for Siebel can be deployed on an Operating System that runs either directly on the server hardware or on a bare-metal virtualization solution.
General Host System Classification
b+s classifies host systems for its software solutions regardless of whether they are deployed on a virtualized or non-virtualized operating system as followed:
| Host System Class | CPU Cores | RAM | Disk Space* |
|---|---|---|---|
| Small | 2 | 4GB | 40GB |
| Medium | 4 | 4GB | 40GB |
| Large | 4 | 8GB | 40GB |
*Refers to the disk space required for b+s applications, does not include disk space required for the operating system.
General Virtualization Requirements
b+s provides predefined OVA-Templates for all host system classes listed in the table above. The templates contain essential hardware specifications which are required for a quick deployment of a virtualized host system (e.g. number of CPU cores, memory size etc.). Be aware that additional configuration options like network adapter settings will still have to be configured manually by a system administrator. The same applies for the installation and configuration of the host system's operating system.
If b+s software is deployed on a virtualized Windows Server operating system, the following restrictions apply:
- Only VMware ESX or ESXi bare-metal virtualization (type 1 hypervisor) software is supported.
- For co-residency of b+s software components with Cisco Unified Communications (UC) software refer to the official Virtualization for Unified Contact Center Enterprise and the general Virtualization for Unified Contact Center Enterprise.
- In case of a non-co-resident deployment of Cisco UC and b+s software, it is permissible to deploy 3rd party software on a separate VMware instance on the same server (blade server or normal rack server) as long as the VMware instance where b+s software is installed receives the required hardware resources from the host system at all times.
3rd Party Host System Requirements
For third-party host system requirements for all involved Cisco components as well as information regarding hard- and software requirements of CCE/CCH, refer to the Hardware and System Software Specification (Bill of Materials): Cisco ICM/IPCC Enterprise & Hosted Edition.
For System Requirements and Supported Platforms for Siebel Business Applications refer to the official Siebel System Requirements and Supported Platforms Documentation web page.
Capacity
Capacity and Scalability Considerations
Agent Capacity - Central Components
The following table shows which host system class is suited for the host system where the b+s Connects for Siebel Central Components are deployed, depending on the required maximum number of concurrent agents.
| Host System Class | Maximum number of concurrent agents | Comments |
|---|---|---|
| Small | 1 - 50 | For labs/testing environments or small production environments |
| Medium | 51 - 500 | For medium-size production environments |
| Large | 501 - 2'000 | For large-size production environments |
The supported maximum number of concurrent agents as listed in the table above refer to the following conditions:
- All b+s Connects for Siebel Central Components are deployed on the same host (ConnectMCAL, DataStore, MediaManager, Siebel RoutingAdapter, ChatConnector).
- All 3rd party applications that the b+s Connects for Siebel connects to (e.g. chat server, Cisco Contact Center components) are deployed on a separate host.
- The numbers above only apply if b+s Connects for Siebel is deployed with CCE/CCH. For scalability limitations specific
to Cisco Packaged Contact Center Enterprise (PCCE) please refer to the
latest Cisco Packaged Contact Center Enterprise Product Specifications document. - The dimensioning guidelines above originate from a b+s lab testing environment that includes a Siebel CRM system simulator. Actual quality of service (delays, responsiveness, etc.) experienced by the agents might vary from the above dimensioning guidelines. These variations include structure and size of the Siebel CRM database, overall level of the Siebel CRM tuning, message payload, transferred Siebel CRM attached data, intensity of the contact processing workflow(s), as well as other Siebel CRM configuration and topology variables outside the scope of the b+s Connects for Siebel. b+s highly recommends an in-house load test to make sure that the total quality of service under load is satisfactory.
Use the following calculations to determine the required agent capacity:
- 1 voice-agent counts as 1 agent
- 1 voice-email-agent counts as 1 agent
- 1 voice-chat-agent counts as 2 agents
- 1 voice-email-chat-agent counts as 2 agents
Calculation Example 1: Voice-only
Overall maximum number of concurrent agents: 1000
- Maximum number of concurrent voice-agents: 1000
Overall required agent capacity: 1000 voice agents = 1000
Calculation Example 2: Voice and Email
Overall maximum number of concurrent agents: 1000
- Maximum number of concurrent voice-agents: 500
- Maximum number of concurrent voice-email-agents: 500
Overall required agent capacity: 500 voice-agents + 500 voice-email-agents = 1000
Calculation Example 3: Voice and Chat
Overall maximum number of concurrent agents: 1000
- Maximum number of concurrent voice-agents: 500
- Maximum number of concurrent voice-chat-agents: 500
Overall required agent capacity: 500 voice-agents + 2 x 500 voice-chat-agents = 1500
Calculation Example 4: Voice and Chat
Overall maximum number of concurrent agents: 1000
- Maximum number of concurrent voice-chat-agents: 1000
Overall required agent capacity: 2 x 1000 voice-chat-agents = 2000
Agent Capacity - Communication Toolbar Adapter
For scalability and redundancy purposes, multiple Siebel Communications Session Managers each with its own Communication Toolbar Adapter DLL can be started on the same Siebel Communication Server or distributed over multiple Siebel Communication Servers. Please check the Siebel bookshelf Siebel Performance Tuning Guide and chapter Multiple Communication Toolbar Adapter Instances of this document for more details (especially concerning the parameters
MinMTServers, MaxMTServers and MaxTasks). As the performance impact to the Communication Toolbar Adapter DLL depends on multiple variable factors there is
no defined maximum of allowed concurrent agents other than it must not exceed the maximum number of concurrent agents of the underlying b+s Connects for
Siebel Central Components. Please contact b+s Product Management for assistance if several hundred agents should be deployed on multiple Siebel Communications
Session Manager / Communication Toolbar Adapter DLLs.
Mobile Agent Capacity
Mobile agent call processing uses significantly more host system resources and therefore reduces the maximum number of supported agents. Use the calculation guidelines as documented in the latest Cisco Unified Contact Center Enterprise Design Guide to determine mobile agent capacity.
Network Requirements
Latency
ConnectMCAL – Cisco CCE Agent PG (CTI Server Protocol)
Latency across the link between the ConnectMCAL-services and the Cisco CTI Server pair must not exceed 100ms one way (200ms RTT). 50ms (100ms RTT) is preferred.
Maximum Round Trip Time: 200 milliseconds
MediaManager – Cisco CCE Agent PG (ARM Protocol)
Latency across the link between the MediaManager-services and the Cisco CCE CTI Server pair must not exceed 100ms one way (200ms RTT). 50ms (100ms RTT) is preferred.
Maximum Round Trip Time: 200 milliseconds
MediaManager – Cisco CCE MR PG (MRI Protocol)
Latency across the link between the MediaManager-services and the Cisco CCE MR PG pair must not exceed 100ms one way (200ms RTT). 50ms (100ms RTT) is preferred.
Maximum Round Trip Time: 200 milliseconds
Communication Toolbar Adapter – DataStore (DS104 Protocol)
Sharing of an agent's current Siebel screen along a call transfer or call conference is only possible if a pair of central DataStores is installed and properly configured. The Communication Toolbar Adapter-to-DataStore network carries the so-called Siebel Bookmark (data representing the agent's Siebel screen) between the Communication Toolbar Adapter instances and the DataStore pair. This traffic consists primarily of the Siebel Bookmark itself and control messages.
When deployed over a WAN, this network connection is critical to the process of transferring the Siebel Bookmark from one Communication Toolbar Adapter to another in case of a call transfer or conference. It must meet latency requirements and, therefore, either IP-based priority queuing or Quality-of-Service (QoS) must be used on the network links. The Communication Toolbar Adapter-to-DataStore network has a maximum one-way latency of 200ms (400ms RTT).
Maximum Round Trip Time: 400 milliseconds
Port Utilization
This chapter describes the default ports used by Communication Toolbar Adapter, MediaManager, DataStore, ConnectMCAL, Siebel RoutingAdapter and ChatConnector.
The information provided is based on default configuration settings. In most cases, it is possible to adjust these setting during installation or configuration. Therefore, the following listings might not show the actual ports in use on your system.
Ports used by Communication Toolbar Adapter
On startup the loaded Communication Toolbar Adapter instance determines an offset for the value of the command-line interface service port by trying to start the service and increment the port number until it finds one that is not already in use by another process. The resulting offset will be used for the command-line interface service port and determines the instance ID.
| Server Protocol & Port | Notes |
|---|---|
| TCP 8040 - 8049 | Local service port for the command-line interface of Communication Toolbar Adapter |
| TCP 8015 | Client connection to ConnectMCAL service port (side A and B) |
| TCP 42029 | Client connection to DataStore service port (side A and B) |
Ports used by MediaManager
| Server Protocol & Port | Notes |
|---|---|
| TCP 7010 | Local service port for the command-line interface |
| TCP 7021 | Local service port for client connection from MR PG (insecure/secure) |
| TCP 7050 | Local service port for client connection from MCIL clients (insecure/secure) |
| UDP 1810 | UDP port for redundancy |
| TCP 42027 | Client connection to CTI Server service port side A |
| TCP 43027 | Client connection to CTI Server service port side B |
| TCP 42030 | Client connection to CTI Server service port side A (secure) |
| TCP 43030 | Client connection to CTI Server service port side B (secure) |
Ports used by ConnectMCAL
| Server Protocol & Port | Notes |
|---|---|
| TCP 8030 | Local service port for the command-line interface |
| TCP 8031 | Local service port for HTTP status info service |
| TCP 42027 | Client connection to CTI Server service port on side A |
| TCP 43027 | Client connection to CTI Server service port on side B |
| TCP 7050 | Client connection to MediaManager MCIL service port |
| TCP 8015 | Local service port for client connection from Communication Toolbar Adapter |
Ports used by DataStore
| Server Protocol & Port | Notes |
|---|---|
| TCP 42029 | Local service port for client connection from Communication Toolbar Adapter |
| TCP 42030 | Local service port for the command-line interface |
| TCP 42031 | Local service port for HTTP status info service |
Ports used by Siebel RoutingAdapter
| Server Protocol & Port | Notes |
|---|---|
| TCP 9015 | Local service port for the command-line interface |
| TCP 9085 | Local service port for HTTP status info service |
| TCP 8015 | Client connection to ConnectMCAL service port (side A and B) |
Ports used by ChatConnector
| Server Protocol & Port | Notes |
|---|---|
| TCP 5222 | Remote port of the chat server |
| TCP 7050 | Remote port of MediaManager |
| TCP 9010 | Local port for remote console of ChatConnector |
| TCP 9080 | Local port for HTTP connections, used to display ChatConnector status page |