Deployment Guide

Solutions Pre-requisite

Hardware Sizing

For a simplex (single server) deployment, minimum and recommended hardware requirements are as follows:

For a redundant deployment, two servers of the same specifications (as mentioned above) are needed.

Software Requirement

Following are the prerequisites for setting up a Hybrid Chat solution under different deployment profiles. 

System Access Requirements

The following ports should remain open on the Firewall. The local security policy and any antivirus should also allow open communication on the following ports:

• <Client Application> is a machine running the client application of EF Connector. For server-based applications like Siebel, it’s Siebel Communication Server. For desktop-based applications, it’s the machine address of the agent desktop running the desktop application.
• In a redundant deployment, both EF Connector instances communicate with each other on the same TCP OpenWIre port 61616. In the table above, it’s mentioned as EF Connector (B) ⇒ EF Connector. 
• These are defaults set in EF Connector, but you can always change the default configuration.

Time Synchronization Requirements

An important consideration is time synchronization between related components. Communication between EF Connector, client applications, and Connector Server. If the system dates and times are not synchronized the system can produce unpredictable results. Therefore, please make every effort to adhere to the following time synchronization guidelines:

EF Connector Server and client applications should have their Time Zone and time configured properly according to the geographic region and synchronized.

In the case of docker deployment, every container should have valid time zones!

Deployment Modes

Non-Redundant / Simplex Mode Deployment

In simplex deployment, the application is installed on a single server with no failover support of EF Connector. However, the same EF Connector can still communicate with primary and secondary CUCM servers.

Simplex mode is useful for lab tests and commercial deployments at a smaller scale. The figure below explains the simplex mode of the Generic Connector.

High Availability (HA) / Duplex Deployment

Active-Passive (Primary / Secondary) Setup

To configure the Connector in Active-Passive mode, set the value of attribute “GRC_CONSUMER_PRIORITY” in the Connector configuration. For the Primary Connector, set the value of this attribute to “127” (without quotes). For the Secondary Connector, set the value of this attribute to “100” (without quotes).

The active-Passive mode has the following configurations.

Configurations for Site-1

Primary-AMQ: broker-1, Secondary-AMQ: broker-2

Generic Connector Configuration should look like this, For a detailed description of the GC please consult properties

Configurations for Site-2

Primary-AMQ: broker-1, Secondary-AMQ: broker-2, For a detailed description of the GC please consult properties. 

Failover Scenarios

The following table shows different failover scenarios and their impact on the Connector Clients.

Failover is handled in a way that if any component goes down, passive components take over in a seamless way. Also if both connectors went down at the same time, all the agents data will be lost!

Active-Active Setup

In this setup for both connectors, the primary amq URL for connector 1 will become the secondary amq URL for connector 2 and vice versa. All the remaining things will remain the same.

Configurations for Site-1

AMQ-1: broker-1, AMQ-2: broker-2

Generic Connector Configuration should look like this, For a detailed description of the GC please consult properties

Configurations for Site-2

Primary-AMQ: broker-1, Secondary-AMQ: broker-2, For a detailed description of the GC please consult properties. 

Generic Connector Configuration

Connector Configuration Parameters

Following are the CUCM configurations that can be set in the env file!

RANDOMIZE

AMQ_MSG_EXPIRY

30000

Deployment Steps

1. Download the deploy.sh file from here.
2. Place deploy.sh file inside some folder eg. Jtapi_Connector.

3. Run the following commands to start the procedure.

   Commands to execute deploy.sh file

   CODE

   cd /root/Jtapi_Connector
   bash deploy.sh

   

4. A cloned folder 'cucm_connector_deployment' can be seen on the command ls. 
5. Go into the cloned folder, where two folders can be seen.
   

   

6. Run the following set of commands to install ActiveMQ.

   Install ActiveMQ

   CODE

   cd Stand_alone_Active_MQ
   docker-compose up -d

7. After above command user can access admin console on a browser to confirm its availability.
   http://machine_ip:8161/admin/queues.jsp
   

   

8. After that run the following commands to edit the activemq configuration!

   1. Get the activemq imageid by following command

      CODE

      docker container ps -a

      

   2. Enter the following set of commands to reach to the activemq configuration file (activemq.xml), and set the urls as in the following image

      CODE

      docker exec -it c139b3018245 bash
      cd conf
      vim activemq.xml

      

9. If u are going for redundent deployment also follow steps mentioned here!

   

   Note: If you wanted to know about vim command, Here is the detail.

10. After amq installation, go back to the main repo directory 'cucm_connector_deployment'. And go into the connector folder 'Connector_Compose_Env'.
    

    

11. You can see the files like this.
    

    

12. Edit the env file and add the required configurations as explained here!

13. After adding configurations, run the following commands to install connector application:

    Test

    CODE

    docker-compose up -d

14. After successful execution of step 13, run the following command to check if the container is up and running!

    CODE

    docker container ps -a

    

ActiveMQ Configuration (Redundant Deployment Only)

ActiveMQ “Config” button opens the ActiveMQ configuration file %ACTIVEMQ%/conf/activemq.xml in your default text editor (e.g. notepad). 

Configuring Network of Brokers 

Settings for a network of brokers are mandatory for redundant deployment only. These configurations should however be done on one side only. 

ActiveMQ brokers should be configured to run as a network of brokers to communicate with each other both for Active-Active and Active-Passive deployment models.

1. Enter the following set of commands to reach the ActiveMQ configuration file (activemq.xml), and set the ActiveMQ Network brokers

   CODE

   docker exec -it <ContainerID> bash
   cd conf
   vim activemq.xml

   

   Note

   If you are using the command prompt, follow this link to copy the  ActiveMQ configuration in the file

   https://www.baeldung.com/linux/vim-paste-text#:~:text=We%20can%20use%20the%20%E2%80%9C%2Bp,for%20pasting%20outside%20of%20Vim

In activemq.xml, the “Network of Broker” configuration please add the following configuration mentioned in the screenshot below. There are 2 instances of <networkConnector> (i) for Queues, (ii) for topics, where you need to set the value of the URI parameter specifying other broker’s (site-B) address. 

Note: Make sure that the configurations are active on only one side. On the other side, it should remain commented out.

This commented tag looks like the following in the activemq.xml file:

If the above-commented configurations are not available in activemq.xml file then copy following and add it inside <broker> tag!
Note: Here the URI IP should be IP of the remote amq!

<networkConnectors>
	<networkConnector
    	name="T:broker1->broker2"
        uri="static:(tcp://192.168.2.162:61616)"
        duplex="true"
        decreaseNetworkConsumerPriority="true"
        networkTTL="2"
        dynamicOnly="true">
        <excludedDestinations>
        	<queue physicalName=">" />
        </excludedDestinations>

    </networkConnector>

    <networkConnector
    	name="Q:broker1->broker2"
        uri="static:(tcp://192.168.2.162:61616)"
        duplex="true"
        decreaseNetworkConsumerPriority="true"
        networkTTL="2"
        dynamicOnly="true">
        <excludedDestinations>
        	<topic physicalName=">" />
        </excludedDestinations>
    </networkConnector>
</networkConnectors>

After adding the above configuration, the user needs to restart the same service.

Run docker container ps -a and grab the id of amq service.

Run the following commands.

docker stop c139b3018245
docker start c139b3018245

The URI on site-A should point to site-B URI “static:(tcp://SITE-B:PORT)” to configure it in network bridge mode. 

For more information about configuring a network of brokers, see this article.

Frontend Deployment Guide

Preface

This document provides deployment details of the product as a standalone.

Prerequisites

Following are the prerequisites for the deployment of the CUCM Connector.

1. The user must have administrative rights.

Installation of  CUCM Connector 

This cucm connector can be deployed on any window server in any application server of the user's choice (IIS, Tomcat, etc). The following section lists the steps to deploy the application on an IIS server.

1. Download the cucm_connectorand extract. In the extracted folder,  Copy all the files and place them in the (c:\inetpub\wwwroot\JavaScript-CTI) or any desired directory. 
2. Open IIS. It can be opened by pressing window+R, writing inetmgr, and clicking OK. It will run IIS Manager.
   
   
   • Right-click on Sites to Add a new Site. 
     
     

     

     
     
     
   • Add new Site, Site name (cucm_connector).
                                    

     

     
     
   • Physical path (cc:\inetpub\wwwroot\cucm_connector).
   • Port, default value is 80 but any other value can be assigned.
   • Please follow this guide to install and configure the SSL certificates on IIS in order to run the cucm_connectoron HTTPS.

Configuration for CUCM Connector

• Open the new_config.js file located on `c:\inetpub\wwwroot\JavaScript-CTI\config.js` path.  Set the properties as per the below table.

• Update the configurations and save the file.
• Browse the configured FQDN and the application should be accessible as shown below.