The Uptivity suite uses a service bus model for designing and implementing communication between the mutually-interacting software applications that make up Uptivity. A third-party application, RabbitMQ, is used as the service bus for Uptivity. RabbitMQ is open source, easy to use, and runs on all major operating systems.
RabbitMQ must be installed on at least one server per customer site. This server, which includes one or more Erlang nodes, is sometimes referred to as a RabbitMQ broker. The following Uptivity functionality is dependent on RabbitMQ:
- Audio Recording — communication between CTI Core
The software component that provides the PBX/ACD integration and makes call recording decisions based on customer-defined recording schedules. and the API An acronym for Application Program Interface. An API facilitates interaction between software components and specifies how they should interact. service requires RabbitMQ - Screen Recording — start/stop screen recording commands from CTI Core to the Screen Capture Client service requires RabbitMQ
- API Server — start/stop blackout commands from API Server to the Screen Capture Client service requires RabbitMQ
- State Sourcing for API — this service monitors the state of an Uptivity system and creates periodic "snapshots" that can be used by the API Server service on startup, allowing for quicker and better recovery from system failures
- Post Interaction Manager (PIM) — this service handles processing of recordings after a call ends, and communicates with CTI Core, Transcoder, and Analytics Manager (if applicable) using RabbitMQ
|
Begin installing RabbitMQ now, or continue in this topic for more information about this installation step. If you are upgrading RabbitMQ, see Upgrading RabbitMQ before continuing. |
RabbitMQ Communication Model
The following is a high-level look at general RabbitMQ terminology and how it applies within Uptivity:
- Producer — an application that sends messages (for example, CTI Core)
- Queue — a buffer that stores messages awaiting a consumer
- Consumer — an application that receives messages (for example, API Server)
- Exchange — directs messages from producers to the appropriate queue
For example, CTI Core (producer) generates a message that a call has started which should be recorded. The RabbitMQ exchange picks up the message and directs it to the appropriate queue for API Server (consumer) to receive. API Server can then issue the command to start recording.
System Design and Federation
When installing to a multi-server system, a best practice is to install a cluster of at least three RabbitMQ servers (or nodes) per customer site. This redundancy can protect against system failure due to RabbitMQ being unavailable. However, the nodes must be configured to correctly handle connectivity loss. This system design is not available for all implementations.
The Uptivity Sales Engineer will determine which server(s) should host RabbitMQ when designing the system. RabbitMQ nodes are meant for LAN-based (not WAN-based) use, and should be configured to communicate only with other nodes at the same geographic location.
RabbitMQ can be used by Uptivity even if it is installed on a non-Uptivity server. This may prove helpful in single-server Uptivity stand-alone installations, where additional RabbitMQ nodes could potentially be installed on other customer servers that reside on the same LAN as the Uptivity server.
Federation
If necessary, a RabbitMQ system can be configured to communicate between different geographic sites over a WAN. In a federated RabbitMQ system, RabbitMQ nodes have been configured to communicate with other RabbitMQ nodes in another geographic site across a WAN.
A multi-site Uptivity system will need to be federated if Screen Capture Clients on one site receive screen recording commands (and screen blackout commands) from CTI Core on a remote site (that is, on a separate LAN).
When communicating blackout commands in a federated system, the WAN's latency may result in sensitive data being captured. For this reason, it is preferable to have an API server on each site.
Federating RabbitMQ enables communication between remote RabbitMQ sites. To federate RabbitMQ in Uptivity, you must install federated exchanges.
The federation exchange installer creates a federated exchange and an upstream exchange. An upstream exchange links a federated exchange to an exchange on a remote RabbitMQ broker. (A remote RabbitMQ broker is a broker that is hosted on a separate LAN.) When an upstream is created, the local RabbitMQ broker receives all of the messages published to the exchange on the remote RabbitMQ broker (via the federated exchange).
An upstream only establishes one-way communication (from a remote broker to the local broker). For two-way communication, an upstream must be created on each of the two brokers that you want to connect.
For Uptivity, you must establish two-way communication between the Uptivity site that is hosting all of the required recording services and any dependent recording site. A dependent recording site is a site that must receive recording commands from a service on a remote recording site.
The exchange that handles local messaging is named recording. The federated exchange is named fed.recording.
Not all multi-site implementations require federation. Whether the Uptivity implementation is for audio recording or screen recording, a multi-site system does not need to be federated if each site hosts all of the required recording services.
Federated RabbitMQ instances should be secured by a VPN connection.
For more information about configuring RabbitMQ for federation, see Enable Federation and Installing Federation Exchanges.
RabbitMQ Web Portal
Once RabbitMQ has been installed and configured for an Uptivity system, its web portal can be used to verify configuration and monitor messaging activity. The web address for the portal is always localhost:15672.
The following tabs provide useful information:
- Overview — provides a dashboard-style view of the RabbitMQ cluster
- Exchanges — displays all exchanges configured for the RabbitMQ cluster
- Queues — displays all messaging activity within the RabbitMQ cluster
Upgrading RabbitMQ
You might need to upgrade RabbitMQ if you are upgrading the version of your NICE Uptivity system, or you might only need to upgrade the version of RabbitMQ that your NICE Uptivity system is using.
Before you can upgrade RabbitMQ, you must first uninstall the current versions of RabbitMQ and Erlang that your system is using. For more information about uninstalling RabbitMQ and Erlang, see Uninstall RabbitMQ and Erlang.
Note that if your system uses SSL for RabbitMQ, you need to regenerate your keys and reconfigure your system to use SSL after you have uninstalled your current versions of RabbitMQ and Erlang.
RabbitMQ Exchange Installer INI File
The cc_rabbitexchangeinstaller.ini file contains configuration settings for RabbitMQ exchanges used in Uptivity. This file is provided by Uptivity Development and should not require any configuration at the time of installation. For more information about the INI File Settings, see Rabbit Exchange Installer INI File Settings.
|
|
Begin tasks to install and configure RabbitMQ >>
|
