Plan and Design Solution

The modular architecture of the Connects for Salesforce – CCE/CCX Edition solution offers a wide variety of deployment models. Each deployment model has its pros and cons regarding issues such as redundancy, complexity, management, and costs. In theory, all case routing add-on components can be installed on one single host or each component can have its own separate host. b+s recommends the deployment models that are described in this chapter.

Service State Definitions

• ACTIVE means that the particular service is started and ACTIVE (i.e. the application is processing requests)
• 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

CCE

Single Site Deployments (single Agent PG)

Base: Voice-Only

CCE Single-Site Voice-Only Deployment

Media Routing: Voice + Cisco Universal Queue Deployment

CCE Single-Site Voice + Cisco Universal Queue Deployment

info

Be aware that if you are intending to operate the product in this deployment model in both a production and a testing environment, none of the case routing add-on components can be shared! That is, two completely separate installations of these components are required.

Multiple Agent Peripheral Gateways (Agent PG) Deployments

Base: Voice-Only

For a deployment with multiple CCE voice PGs, each CCE voice PG requires its own redundant Finesse Servers.

The Connects Finesse Gadget URLs are specified in different Call Center configurations in Salesforce. Agents can be assigned to one Call Center configuration only.

Refer to the section Salesforce Call Center for further information concerning the required adjustments.

CCE Multi-Site Voice-Only Deployment

The following picture illustrates a Multi-PG voice deployment configuration:

Multi-PG share record & screen pop on transfer

The following features require a specific CCE configuration in order to perform properly between agents on different Voice PGs:

• Screen pop on transfer
• Share record

Correct configuration:

Agent A: PG1

Agent B: PG2

Voice Call consultation mode Agent A -> Agent B: Over “internal” route point (internal = PG 1 is configured as routing client in DN for RP)

Supported: ✓

Incorrect configuration 1:

Agent A: PG1

Agent B: PG2

Voice Call consultation mode Agent A -> Agent B: Direct to agents extension

Supported: ✗

Incorrect configuration 2:

Agent A: PG1

Agent B: PG2

Voice Call consultation mode Agent A -> Agent B: Over “external” route point (external = PG 2 is configured as routing client in DN for RP)

Supported: ✗

Cisco Universal Queue

In order to implement Cisco Universal Queue in a multi-agent PG environment, only one redundant Media Routing PG and one redundant b+s RoutingAdapter for Cisco Universal Queue are required.

Cases and Chats received at one site can be rerouted to other sites either by an agent or by the system.

CCX

Single-Site Deployments

Base: Voice-Only

CCX Single-Site Voice-Only Deployment

Special Conditions for Voice Deployments

The following list outlines some scenarios for special deployment conditions:

1. The user closes the browser or the browser crashes: When the user closes the browser, navigates away from the Salesforce page or the Salesforce browser window where the Connects Gadget is loaded crashes, a best-effort attempt will be made to notify the Finesse server.

   a. Server Action

   Finesse receives a presence notification of “Unavailable” from the client. Finesse waits 60 seconds, and then sends a forced logout request to the CTI server (code 255).

   b. Race Conditions
   
       i. The user closes the browser window. Finesse receives a presence notification of
           “Unavailable” for the user. Finesse tries to sign off the user; however, that
           user is already signed out.
   
       ii. If the browser crashes, it can take the Finesse server up to 120 seconds to
           detect that the client is gone and send a presence notification to Finesse.
           A situation can occur where the client signs in to the secondary Finesse server
           before the primary Finesse server receives the presence notification caused by
           the browser crash. In this case, the user may be signed out or put into the
           Not Ready state on the secondary Finesse server.
   
       iii. If the Finesse desktop is running over a slower network connection, Finesse
           may not always receive an “Unavailable” presence notification from the client
           browser. In this situation, the behavior mimics a browser crash, as described
           in the preceding condition.

2. The agent device loses the network or power connection or is logged out by supervisor: The agent will be logged out. A manual re-login is required.

   a. Server Action: Finesse sends a Logout event with reason -1 to the client.

3. The client experiences a network glitch (Finesse is in service) In this case, the Finesse XMPP connection temporarily goes down. Subsequently, the Connects Gadget freezes and the voice channel icon changes to state “reconnecting”. Additionally, a warning appears saying “Voice connection lost, reconnecting” instead of the b+s logo.

caution

Under certain conditions, Finesse sends a code of 255 to the CTI server (you may see a different code on the CTI server side). The actual behavior of the desktop under these conditions depends on the setting for “logout on agent disconnect”, (LOAD) in CCE. By default, the CTI server places the agent in state “NOTREADY”.

info

Finesse takes up to 120 seconds to detect when the user closes the browser or the browser crashes. Finesse waits 60 seconds before sending a forced logout request to the CTI server. Under these conditions, Finesse can take up to 180 seconds to sign out the agent.

Network Requirements

This chapter describes the default ports used by Connects for Salesforce – CCE/CCX Edition.

info

The information provided is based on default component variants / configuration settings. In most cases, it is possible to adjust these settings during installation or configuration. Therefore, the following listings might not show the actual ports in use on a given system.

Port Utilization – Voice Only (CCE and CCX)

Port utilization for CCE/CCX deployments

Default ports used by Connects Finesse Gadget

Server Protocol	Port	b+s	Notes
TCP	443	CCE	Secure web connection to Cisco Finesse (Finesse API and Connects Finesse Gadget)
TCP	8445	CCE	Secure XMPP connection to Cisco Finesse for Finesse >= 12.6(1)
TCP	7443	CCE	Secure XMPP connection to Cisco Finesse for Finesse < 12.6(1)
TCP	8445	CCX	Secure web connection to Cisco Finesse (Finesse API and Connects Finesse Gadget) Secure XMPP connection to Cisco Finesse

Default components connection ports table

The following tables list essential information for firewall administrators concerning the ports required to connect the individual components.

#	Source	Destination	Origin	Direction	Prot.	Port	Secured
1	Connects Finesse Gadget*	Salesforce**	Agent Browser	in/out	TCP/IP	443	Yes
2	Connects Finesse Gadget*	Cisco Finesse*	Agent Browser	in/out	TCP/IP	8445***	Yes

* Corporate network

** Cloud

*** 8445 for Finesse >= 12.6(1); 7443 for Finesse < 12.6(1)

Port Utilization – Cisco Universal Queue

Port utilization for CCE deployments – differences in Cisco Universal Queue

Default ports used by b+s RoutingAdapter Ext-MRI

Server Protocol	Port	Notes
TCP	9011	Local service port for the command-line interface of b+s RoutingAdapter Ext-MRI
TCP	9081	Local service port for b+s RoutingAdapter Ext-MRI HTTP status info service
TCP	7021	Connection for the MR PIM to connect to the b+s RoutingAdapter Ext-MRI

Default components connection ports table

The following table lists essential information for firewall administrators concerning the ports required to connect the individual components.

Cisco Universal Queue

#	Source	Destination	Origin	Direction	Prot.	Port	Secured
1	b+s Routing Adapter	Salesforce*	b+s Routing Adapter	out	TCP/IP	443	Yes
2	Cisco MR PIM**	b+s Routing Adapter***	Cisco MR PG	in/out	TCP/IP	7021 or configurable	Yes

* Cloud corp, netw. * Hosts 3,4 - corp. netw.

info

The actual configuration may vary depending on your component variation.

Redundancy Considerations and Failure Scenarios

The figures in this chapter show a redundant installation of the product depending on solution (CCE or CCX) and deployment type. For the sake of simplicity, not all Cisco components are shown on these diagrams (e.g. the Cisco CCE Central Controller is missing).

Service State Definitions used in the diagrams

• 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 as the component communicates with one single service at a time, the second service is started but INACTIVE.
• 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

Salesforce CRM

In case of an outage of the Salesforce CRM, a substitute agent desktop has to be used to handle call center based calls or cases (i.e. the Cisco Finesse Desktop. The CRM based features (e.g. click-to-dial, call activities) and information (lookup results) will not be available in that case.

Cisco Finesse Failover Conditions

A failover can occur in the following scenarios:

• The Cisco Tomcat Service (or Finesse Webservice) goes down
• The Cisco Finesse Notification (or XMPP) Service goes down
• Network connection loss or network glitch
• Finesse loses connection to both CTI servers

CRM Hosted Deployment

CCE (CRM Hosted)

Redundant CCE Voice-Only CRM Hosted Deployment

In this deployment model both Finesse servers connect to the CCE PG and both are activated. Only one of the two CTI Servers is active at any given time. In case of a PG failover, both Finesse Servers reconnect to the other CTI Server running on the other PG side.

In the Call Center configuration both Finesse Server URLs can be configured. The Connects Finesse Gadget is loaded from Salesforce and connects to one of the two Finesse servers. For more information on the Finesse failover behavior see its corresponding section

The following table shows the fallback behavior in case of an outage of one of the redundant components:

Component Outage	Fallback	Comments
Connects Finesse Gadget	-	The Connects Finesse Gadget is hosted within the Salesforce CRM. See section Salesforce CRM for more information.
Primary Finesse Server	Secondary Finesse Server	See section CRM Hosted Deployment failover for more information
CTI SRV A	CTI SRV B	Refer to chapter "CTI Failover" of topic "Cisco Finesse Failover mechanisms" in the "Cisco Finesse Administration Guide" of the corresponding Finesse Release: https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-maintenance-guides-list.html

CCX (CRM Hosted)

Redundant CCX Voice-Only CRM Hosted Deployment

In this deployment model, Finesse runs on the CCX servers that have a direct connection to the UCM cluster.

On CCX environments (or clusters) there is always only one running server declared as master. The secondary CCX server is declared as a slave and is in idle mode.

In the Call Center configuration, both Finesse Server URLs can be configured. The Connects Finesse Gadget is loaded from Salesforce and connects to one of the two Finesse servers. See section CRM Hosted Deployment failover for more information.

The following table shows the fallback behavior in case of an outage of one of the redundant components:

Component Outage	Fallback	Comments
Connects Gadget	-	The Connects Finesse Gadget is hosted within the Salesforce CRM. See section Salesforce CRM for more information.
Primary CCX Server	Secondary CCX Server	In case of a Finesse outage, see section CRM Hosted Deyployment Failover. Refer to chapter "Cisco Finesse High Availability Considerations" in the "Solution Design Guide for Cisco Unified Contact Center Express" of the corresponding CCX Release: http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/products-implementation-design-guides-list.html

Failover (CRM Hosted)

When an issue with the connected Finesse server occurs, the Connects Finesse Gadget tries to recover. If this is not possible the Connects Finesse Gadget tries to connect to the other Finesse server.

In the Call Center configuration, a secondary Finesse server and a timeout can be specified. The timeout determines how long the Connects Finesse Gadget tries to recover the active server. When the timeout is exceeded, the Connects Finesse Gadget then tries to connect to the other server.

There are three scenarios for how a failover can be carried out.

After the Connects Finesse Gadget encounters an issue with the connected Finesse server, the following can happen:

• The Finesse server is able to recover on time. This means the connection is reestablished to the same server.
• The configured time is exceeded before the Finesse server is able to recover. The Connects Finesse Gadget connects to the other Finesse server.
• Both Finesse servers are not available. The Connects Finesse Gadget starts with the last connected Finesse server. Then switches back and forth between the two servers until one is available.

If the Connects Finesse Gadget switches to the secondary Finesse server, it stays on this connection until another failover occurs. In order to switch back to the primary server, the browser must be restarted, or the local data in the settings menu of the Connects Finesse Gadget must be cleared.

Cisco Universal Queue Deployments

Component Outage

Redundant Cisco Universal Queue Deployment (w/o Voice channel)

This deployment also includes the voice channel. For the sake of simplicity, the figure above shows the Cisco Universal Queue deployment only, without Cisco Finesse and CTI. For additional information about the voice channel, see section CRM Hosted deployments - CCE.

In case of the b+s RoutingAdapter Ext-MRI failover, either the RoutingAdapter recovers or the MR PG automatically connects to the second Adapter.

Only one of the two CTI SRV is active at any given time. In case of a Voice PG failover, the Finesse server reconnects to the other CTI server.

The same applies to the MR PG. In case of a MR PG failover, the other MR PG reconnects to the active RoutingAdapter Ext-MRI.

The following table shows the fallback behavior in case of an outage of one of the redundant media channel components:

Component Outage	Fallback	Comments
b+s RoutingAdapter Ext-MRI A	b+s RoutingAdapter Ext-MRI B	1) The agents are still able to end, pause, and resume work items.2) The MR PG automatically connects to the b+s RoutingAdapter Ext-MRI B
MR PG A	MR PG B	The MR PG B automatically connects to a b+s RoutingAdapter Ext-MRI

Connection Lost

There are situations where the b+s RoutingAdapter Ext-MRI and the MR PG are active but the connection between components are lost.

Cisco Universal Queue Deployment - Connection lost to MR PG

If the connection between the the b+s RoutingAdapter Ext-MRI and the MR PG is lost the following happens:

• All tasks are dequeued from CCE
• The b+s RoutingAdapter Ext-MRI shuts down the Streaming API connection until the connection to the MR PG is re-established
• As soon as the MR PG connection is re-established the Streaming API connection is started and all the tasks are recoverd from Salesforce and then re-queued in CCE

Cisco Universal Queue Deployment - Connection lost to Streaming API

If the connection between the b+s RoutingAdapter Ext-MRI and the Salesforce Streaming API is lost the following happens:

• The tasks are not dequeued from CCE
• During the interrupt, new tasks which are put in the Salesforce queue have to wait until the connection is re-established
• As soon as the connection is re-established the missed messages from the Streaming API are processed (e.g. adding new tasks)

CTI Server

Failover Conditions

Please refer to the chapter CTI Failover of topic “Cisco Finesse Failover mechanisms” in the "Cisco Finesse Administration Guide" of the following Finesse Release: https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-maintenance-guides-list.html

b+s Connects Finesse Gadget Behavior

Depending on the current call state, the Connects Finesse Gadget behavior differs in the case of a CTI server failover.

General Information

1. Independently of the Cisco call type classification assigned to the ongoing call, when it is recovered from a failover, Cisco Finesse recovers it with the call type OTHER_IN. This can lead to altered (incorrect) call work item contents.

1.a. Wrong Call Work Item Indication. A recovered call is always declared as an Inbound Call

Wrong Call Work Item Identification

info

Exception: a routed call in state “Talking” or “Hold” and a direct call in state “Hold” will be recovered as “Conference Call”.

1.b. Wrong Call Participant Information. A recovered call has an (empty) ANI instead of a DNIS or a conference participant list.

2. The initial agent state is lost

2.a. The follow-up agent state would always be NOTREADY with ReasonCode 0.

3. The Wrap-Up information of an established call gets lost

3.a. No Wrap-Up state when ending the call (except optional requested => since Finesse 10.5)

3.a.i. Optional Wrap-Up: the button stays green, if an optional Wrap-Up was requested (available since product version >= 3.0)

3.b. The chosen Wrap-Up reason code stays available

4. A Wrap-Up state is not recovered

4.a. The follow-up agent state would always be NOTREADY with ReasonCode 0

5. A not-yet-established campaign call is not be recovered, but offered again later

6. The peripheral variable values get lost, but the ECC variables are recovered

caution

Exception: On a recovered conference call, the peripheral variable values will be recovered as well.

7. A ringing outgoing call will be recovered as an established call

info

This list is not final and depends on the Cisco CCE and Finesse version used. The above list was created using Cisco CCE & Finesse 10.0.

Agent experience

Approximately five (5) seconds after the CTI server connection is lost, Finesse sends an API event with the system status OUT_OF_SERVICE. Subsequently, the currently open handler is disconnected

Each request towards Finesse performed by the Connects gadget is responded to with an error until the second CTI server is active. Thus, the UI cannot respond anymore

• As soon as the second CTI server has taken over the operations, the limitations mentioned above apply
• Active calls cannot be ended from the Connects Gadget before the call is recovered by the second CTI server

AWDB

Refer to chapter AWDB Failover of topic Cisco Finesse Failover Mechanisms in the "Cisco Finesse Administration Guide" of the corresponding Finesse Release: https://www.cisco.com/c/en/us/support/customer-collaboration/finesse/products-maintenance-guides-list.html