Cisco Finesse is a next-generation agent and supervisor desktop designed to provide a collaborative experience for the various communities that interact with your customer service organization. It also helps improve the customer experience while offering a user-centric design to enhance customer care representative satisfaction.
For IT professionals, Cisco Finesse offers transparent integration with the Cisco Collaboration portfolio. It is standards compliant and offers low cost customization of the agent and supervisor desktops.
Cisco Finesse provides:
Cisco Finesse is built to provide the optimal user experience for agents. The key tenets of the Finesse approach are:
Finesse has versions for both Unified Contact Center Enterprise (UCCE) and Unified Contact Center Express (UCCX). For the common features between the two deployments, the REST API and the JavaScript Library API are the same. Therefore, applications or gadgets developed using the Finesse APIs will work on both deployments.
For more information about the Finesse product, see http://www.cisco.com/c/en/us/products/customer-collaboration/finesse/index.html
The above diagram shows the relationships between the various components and services between the client, Finesse, and UCCE in an enterprise deployment. There are other components and services that are not shown since they are not of direct relevance. The legend below the diagram depicts the various protocols used in this deployment.
Finesse consists of the following set of web applications that is hosted on its own Tomcat instance, called Cisco Finesse Tomcat:
3rdpartygadget: A repository for third-party gadgets.
The Shindig web application from Apache serves the gadget container running on the Finesse desktop. This is a third-party component based on the OpenSocial Gadget specification.
The CCE Realm is an in-memory component that caches credentials and user information for authentication purposes.
Cisco Finesse Notification Service is an instance of an OpenFire server, running as a separate process on the platform, that provides event notification from the Finesse server to any client is subscribed to that resource. The Finesse Tomcat server communicates the events that need to be dispatched to the client via XMPP messages to the OpenFire server.
For web applications, a BOSH (Bi-directional streams Over Synchronous HTTP) channel should be opened to the OpenFire server, which is used to dispatch events from the OpenFire server to the browser.
Please see the Cisco Finesse Notification Service section below for more details.
The Unified Communications Manager (UCM) interface is also shown in the above diagram as it provides telephony controls between UCCE and UCM via the JTAPI protocol.
The above diagram shows the standard deployment of Finesse servers in Enterprise deployments.
The Finesse server is always deployed as a 2-node pair in Enterprise deployments, with each node in the pair configured with the addresses of the PG pair in UCCE that is hosting the CTI service. At any instant in time, both nodes of the Finesse cluster connect to the same side of the PG (either Side A or Side B). It is not possible for the 2 nodes of the Finesse cluster to connect to separate instances of the PG. If a CTI connection failure is detected by the Finesse server either at initialization or during runtime, both nodes of the Finesse cluster will fail over to the other side of the PG.
A Finesse desktop client can be instantiated off either one of the Finesse servers. The servers always operate in active-active mode in Enterprise deployments and keep their internal user and dialog state in sync via the events received via the CTI interface. Clients obtain information about both the servers in the Finesse cluster, and monitor the status of the servers throughout the lifetime of the client session. Clients can dynamically initiate failover to the other server and recover their state if they detect connectivity or server issues with the server they are currently connected to.
In Express deployments, the internal architecture of Finesse is identical to that of Enterprise deployments, except that Finesse does not run on a distinct VM/server. The Cisco Finesse Tomcat service, which hosts all of the web applications delivering Finesse functionality, runs as a co-resident service on the UCCX VM. The Finesse web application still functions as a CTI client to the CTI server that is now hosted on the UCCX engine in the same VM. The OpenFire server that is used to dispatch events to the browser is renamed as the Cisco Unified CCX Notification Service, but provides the same functionality as in Enterprise deployments from the Finesse perspective. However, it is shared with other applications hosted on UCCX.
In Express deployments, user authentication is done via the AXL interface provided by Unified Communications Manager, as user identity and profile information is managed by the UCM. UCM, in turn, may interface with a Microsoft Active Directory server for user management. Therefore, the caching realm for user identity information in this case is a different implementation as compared to Enterprise deployments.
The above diagram shows the standard deployment of Finesse in Express deployments.
Since UCCX uses the active-inactive deployment model, Finesse also mirrors this behavior in Express deployments. Finesse is active only on the node where CCX engine is Master, and follows the engine mastership. Users can log in only to the Finesse server that is currently active. If they attempt to log in to the inactive Finesse server, they will be automatically redirected back to the active Finesse server. Each Finesse server in this model connects only to its own local CTI server instance. UCCX ensures that CTI server is active and allows client connections only on the node where CCX engine is the master.
Cisco Finesse provides REST APIs for performing agent and supervisor actions programmatically. These REST APIs are easy to use, modeled after HTTP, and works in thick and thin client integrations. The Finesse Developer Guide explains the details for each of the API's, but here is a high level description of the API functionality:
Cisco Finesse Notification service is an instance of OpenFire server, running as a separate process on the platform, that uses XMPP protocol as the data communication channel and encoding mechanism for dispatching user and dialog events to the client via a seemingly asynchronous mechanism. Events to be notified to the client from the Finesse Tomcat service are dispatched to OpenFire via the Smack client library using XMPP as the data communication channel.
For web applications, in order to send the events to the browser, which communicates only via the HTTP protocol, the XMPP payload needs to be encapsulated within the HTTP protocol. This encapsulation is known as BOSH (Bi-directional streams Over Synchronous HTTP). The BOSH endpoint in the browser is implemented by a JavaScript XMPP Library. The Finesse desktop uses the Cisco Ajax XMPP Library (also called CAXL), but any JavaScript library can be used. The advantage of using BOSH to communicate to the OpenFire Server in a browser environment is that it uses the browser's native communication channel (HTTP) and no other ports need to be opened in the firewall between browser and server.
Since HTTP is a request-response protocol, the BOSH client in the browser works by sending a HTTP request to the BOSH server (OpenFire) asking for any outstanding events. If there are no events to send, the request is kept pending for a certain period of time instead of returning immediately with an error or an empty payload. If events arrive at OpenFire from Finesse during this time, it is sent as a HTTP response to the pending HTTP request. The BOSH client receives these events and immediately fires the next HTTP request to OpenFire for the next set of events. If, on the other hand, the timer expires before any events are available to be dispatched, a HTTP response with a heartbeat message is sent back to indicate the liveness of the OpenFire server to the client. This explains why the event dispatch from the Finesse server to the browser appears to happen in a "seemingly asynchronous manner".
Gadgets that are built to run on the Finesse desktop don't have to worry about the details of the BOSH communication channel as this is already setup by the Finesse desktop container before the gadgets get loaded. The events are made available to the gadgets via the Cisco OpenAjax Hub, which implements a publish-subscribe mechanism in the browser. The OpenAjax hub can be used by gadgets to communicate with each other in a purely asynchronous manner (Please see the Finesse out-of-the-box Desktop section below for more details).
Third party web applications that run inside a browser context and make use of the Finesse APIs need to setup a BOSH channel to the Finesse Notification service for the reasons mentioned above. The details of setting up a BOSH connection using third-party Javascript libraries can be found in the Finesse Developer Guide.
Third party applications that run as traditional thick clients (Java, Python clients, etc.) can use XMPP directly to the Finesse Notification service for asynchronous reception of events. Examples of using XMPP directly can be found in the Finesse Developer Guide.
The Finesse desktop is an implementation of the OpenSocial Gadget framework (Shindig) that serves as a container for hosting OpenSocial gadgets. The container has been significantly enhanced to provide the infrastructure required for communicating with Finesse Notification service via BOSH/XMPP, so that gadgets (whether Cisco or third-party) hosted on the desktop do not have to deal with the intricacies of the BOSH connection setup. The events published via the BOSH tunnel are made available to all gadgets via the publish-subscribe mechanism implemented by the Cisco OpenAjax Hub, which is a Javascript library.
Finesse Gadgets are OpenSocial gadgets, which is an XML document that defines metadata for an OpenSocial Gadget container. The gadget are essentially mini web pages or applications that are placed within the Finesse desktop. This approach is particularly useful for contact center agents because this gives them access to all of the applications that they need to service calls inside of a single application, Cisco Finesse.
Finesse comes with a couple of out of the box gadgets such as the team performance gadget, but often times, customers have specific requirements that are not available on the Finesse desktop. To alleviate that problem, Cisco Finesse provides a Finesse JavaScript Library API to make it easy to build custom gadgets.
There are many sample gadgets available for developers to use as an example and base for their custom gadgets.
Third party gadgets can be hosted on either the Finesse server (via the 3rdpartygadget web application) or on an external web server. Gadgets can also make REST requests to services hosted on external servers using the Finesse Javascript Library API. To avoid browser cross-origin issues, such requests are proxied via the backend Shindig web application. It is the responsibility of third-party gadgets to implement their own authentication mechanisms for third-party REST services.
Finesse is built for developers. It provides two types of APIs:
There are three paths for customization:
The best way to really understand Cisco Finesse is to try it for yourself. Please proceed to the Getting Started page to learn just how easy it is.