Использование memcached для BLF-панели в браузере

В этой статье будет описана разработка приложения для браузера отслеживающая в реальном времени статусы внутренних номеров и показывающая их на странице. Аналог BLF-панели телефона или же приложения FOP2.

Если вы используете телефонию, у вас есть несколько операторов, а возможно и целый КЦ (колл-центр) на несколько отделений и фирм. Как следствие, часто возникает ситуация, в которой клиент попадает не на того оператора, который нужен, или с которым он общался ранее и есть необходимость перевода звонка. Частично этот вопрос может решить функционал «перевода на ответственного», однако целевой оператор может быть не на месте или вовсе недоступен. Чтобы знать о целесообразности перевода существуют BLF панели телефонов, но не на всех моделях они присутствуют и не всегда удобно смотреть на телефонный аппарат. Также, на текущий момент многие используют софтфоны.

Существует распространенное приложение FOP2. Оно успешно и довольно просто интегрируется с программными АТС на базе asterisk, однако оно имеет закрытый код, и, как следствие, отсутствие возможности кастомизации и настройки под свои нужды.

В статье мы рассмотрим простейший пример создания панели индикации статусов операторов используя самые простые и распространённые инструменты.

Все инструкции тестировались на следующем оборудовании:

1. CentOS Linux release 7.5.1804
2. FreePBX 13
3. Asterisk 13.22.0
4. PHP 5.6
5. MariaDB 10.1.33
6. Asterisk manager interface (AMI)

Глобально приложение мало чем отличается от обычной системы «клиент-сервер», однако есть некоторые особенности, а именно то, что доступ клиента осуществляется не напрямую к AMI, а к внешнему сервису кэширования memcached, который и хранит нужные нам статусы.

Поскольку этот сервис не использует физический носитель, скорость обмена информацией достигает достаточно высокого показателя. Однако это же несёт и некоторые риски: при сбое, отключении электроэнергии или аварии все данные хранимые в memcached будут утеряны. Подробно останавливаться на описании сервиса кэширования и его конкуренте redis не будем. Достаточно пояснить какие функции он берёт на себя:

1. Хранение статусов данных об операторах
2. Обновление в реальном времени
3. Распределение нагрузки операторов

Поясним последний пункт. В большинстве приложений серверная часть при запросе от клиента инициирует новое подключение к сокету для получения данных в независимости от их вида: mysql или ami. Это соответственно умножает количество запросов и общую нагрузку на АТС пропорционально количеству пользователей приложения.

В нашем же случае соединение с MySQL и AMI поддерживается всего одно и постоянно. Достигнуть этого позволяет специальная программа-демон. В его задачи входит периодический опрос AMI на предмет статусов операторов и складирование результатов в кэширующую таблицу. И уже к ней будут подключаться клиентские стороны.

Перейдём ближе к теме.

Для начала разместим файлы из архива приложения в директории доступной для обращений из web-сервера. В нашем случае это:

Далее нам понадобятся учётные записи для работы с MySQL и AMI. Для этого нам необходимо добавить своих пользователей.

# nano /etc/<наименование_дистрибутива>.conf

В случае с FreePBX Distro это:

К сожалению, лайфхака подобного этому нет для AMI. Поэтому пользователя создадим вручную. Для этого открываем файл конфигурации любым текстовым редактором:

# nano /etc/asterisk/manager_custom.conf

Добавляем в конец данные, аналогичные приведённым ниже (с заменой логина\пароля):

Сохраняем изменения, закрываем файл и выполняем применение настроек. Но перед этим открываем консоль CLI.

# asterisk –rvvvv
CLI> manager reload

И проверим наличие нашего нового пользователя.

Всё готово. Теперь доступы необходимо перенести в файл конфигурации приложения. Открываем указанный файл и заполняем следующим образом:

Следующее, что нам нужно сделать, это установить и запустить сервис кэш-таблиц. Сделать это можно командой:

# yum install memcached

После установки сервис необходимо запустить и проверить его активность.

Далее выносим из архива файл-контроллер демона и размещаем в директории /etc/init.d/*. Даём ему права на выполнение.

# cd /etc/init.d/
# chmod a+x bigbro

Дадим небольшие пояснения. В папке с приложением есть файлы, которые можно вынести и использовать отдельно, а именно класс «демона» и его стартер.

Формально это и является основой всего приложения. Контроллер даёт команду стартеру, который инициирует демона. Тот создаёт PID файл для управления, и переходит в фоновый режим с прослушиванием сигналов системы.

Раз в некоторое время (1с. по-умолчанию) демон обращается к AMI и получает информацию о статусах устройств, после чего форматирует её и сохраняет в кэш-таблице.

Если всё настроено корректно, можно пробовать запускать приложение. Сделать это можно командой:

# service bigbro start

Проверить статус активности:

# service bigbro status

Остановить приложение:

# service bigbro stop

Проверить непосредственную работу демона можно через список активных процессов:

# ps aux | grep $(cat /var/run/bigbro)

Если всё корректно вы увидите примерно то же, что и на скрине выше.

Теперь можно, используя небольшой скрипт-вьювер можно проверить значения в кэш таблице:

Так же запустив постоянный вызов в реальном времени можно наблюдать за обновлениями таблицы:

И теперь можно открывать страницу, с ip вашего web-сервера, указывать путь, который вы задали при распаковке и если всё верно настроено: пользоваться приложением.