Системы мониторинга сети телефонных линий компании в режиме реального времени

Оба решения имели свои преимущества. Так, MySQL обладает чёткой структуризацией данных и тем самыми возможностью построения удобной и легко поддерживаемой структуры данных. С другой стороны, MySQL не всегда является легко изменяемым и масштабируемым решением. [38] Однако, данной проблемой не обладает MongoDB, которая может хранить данные любых структур с любой вложенностью. Другим же достоинством MongoDB является «нативность» взаимодействия с языком программирования JavaScript, а тем самым максимально упрощённый интерфейс базы данных для работы с серверным приложением, использующим Node.js. [37][39]

Ключевым фактором при выборе системы управления базами данных стало удобство имплементации в существующую топологическую архитектуру. Компания по историческим причинам использует СУБД MySQL (MariaDB) с веб-интерфейсом phpMyAdmin, а потому интеграция новой база данных не является целесообразным. MySQL представляет собой реляционную систему управления данными, то есть её базовой структурой является понятие отношения на декартовом произведении доменов, где домен - множество значений, которые может принимать определённый элемент данных. [40]

Все таблицы и отношения между ними, построенные при разработке системы мониторинга, были нормализованы до третьей нормальной формы, то есть каждое из отношений последовательно приведено к первой, второй и третьей нормальным формам [41], где:

отношения является приведённым к первой нормальной форме, если все атрибуты отношения простые;

отношение является приведённым ко второй нормальной форме, если оно приведено к первой нормальной форме и каждый не ключевой атрибут полностью зависит от составного ключа;

отношение является приведённым к третьей нормальной форме, если оно приведено ко второй нормальной форме и не обладает транзитивными зависимостями.

Дальнейшая нормализация отношений при проектировании базы данных приложения не потребовалась.

Так как база данных приложения предназначена для хранения некоторых приватных данных пользователей, таких как информация по звонкам, контактным данным и паролям, то все данные кодируются перед отправкой на сервер и обратно декодируются при получении сервером данных. Пароли, являясь наиболее ценной с точки зрения безопасности информацией кодируются дополнительно с использованием алгоритма криптографического хеширования SHA-1 (англ., Secure Hash Algorithm 1), который кодирует данные в 160-битное хеш-значение. [42] Тем самым даже при успешном злоумышленном несанкционированном доступе к хранимой в базе данных информации, украденные пароли не несут какой-либо ценности. Так, например, пароль SMF200134 будет представлен последовательностью символов 2a4dcgd33420dfb69b053d99815dgg.

Особое внимание следует уделить нетекстовым данным. Для хранения аудиозаписей телефонных разговоров в СУБД MySQL можно использовать тип данных BLOB (двоичный большой объект). Другой вариант - транслировать в режиме реального времени записи звонков на собственные хранилища данных (в данном случае - жёсткие диски) и добавлять ссылку на записи в таблицы. На практике первый вариант не является эффективным, так как кодирование и декодирование медиа-сообщений может занимать достаточно большое время, особенно с учетом частого обращения к базе данных. Потому для хранения аудиозаписей используется второй подход.

3.5 Разработка интерфейса веб-приложения

Интерфейс веб-приложения разрабатывался с учётом следующих трёх факторов:

удовлетворения требованиям бизнес-логики. Интерфейс приложения должен в полной мере предоставлять возможности взаимодействия с функциональностью приложения;

обеспечения удобства конечного пользователя, интуитивности интерфейса. Здесь играют роль расположение веб-элементов на интерфейсе, плавность анимации, величина отзывчивости и многие другие факторы;

необходимости придерживаться существующей стилистики более ранних внутренних программных продуктов компании. Так как компания обладает фирменным стилем, распространяющимся в том числе и на программные продукты, то и данное веб-приложение должно обладать корпоративной стилистикой.

Дизайн веб-страниц разрабатывался поэтапно для реализации следующих основных задач:

выбора цветовой гаммы;

создания карты навигации по интерфейсу;

определения объёма допустимой загруженности веб-страниц элементами;

определения форм и размеров элементов интерфейса и их взаимного расположения - композиции;

обеспечения адаптивности.

Так как цветовая гамма способна в существенной мере влиять на восприятие конечным пользователем интерфейса в целом, то цвета должны «дружелюбными», а именно обладать пониженной контрастностью и не быть чрезвычайно насыщенными. [43] Кроме того, требованием корпоративной стилистики является использование зелёного и белых цветов в качестве доминирующих. Таким образом выбранную палитру составили следующие веб-цвета - белый (#FFFFFF), тёмно-серый (#363b41), тёмно-синий (#4186bd), тёмно-зелёный (#00b25b), светло-серый (#7f7f7f), светло-синий (#acecfb), светло-зелёный (#a8eacc), светло-жёлтый (#fbfdba) и светло-красный (#ffa592).

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

Элементы интерфейса могут обладать, как скруглёнными, так и острыми формами по следующему правилу - если элемент является обёртывающим (внешним) блоком, то для такого элемента используются скруглённые углы. В противном случае - острые.

Немаловажным также является этап продумывания и разработки карты навигации веб-приложения. Так как приложение визуально должно напоминать десктопные аналоги, то классическая веб-навигация с использованием различных URL страниц заменена одностраничной навигацией - все элементы страницы перерисовываются при выборе различных логических блоков приложения.

Фактически, разработка дизайна интерфейса веб-приложения происходила последовательно в пять этапов:

Выбор цветовых характеристик и форм элементов.

Прорисовка веб-элементов.

Проектирование макетов логических блоков (веб-страниц), взаиморасположение элементов.

Создание вспомогательных элементов (модальных окон, лого, фавикона и прочих).

Непосредственная вёрстка интерфейса.

Выбор цветовой гаммы, создание дизайна страниц, прорисовка элементов интерфейса и их взаимного расположения происходили с использованием двух графических редакторов - Adobe Photoshop CC 2018 и Adobe Illustrator CC 2018. Использование данного программного обеспечение обусловлено широтой функциональности продуктов и удобством их использования. Кроме того, выбранные графические редакторы обладают специальными возможностями для более быстрой разработки веб-дизайна такими, например, как пиксельная разметка сетки, возможность просмотра макетов на мобильных устройствах и другими. [44]

Также при разработке интерфейса использовался другой продукт - Adobe Muse CC 2018, который создан специально для создания веб-сайтов невысокой сложности (лендинг-страницы) без непосредственного кодинга. [45] Несмотря на то, что данный продукт не подходит для создания сложного многофункционального веб-приложения, он удобен для построения в интерактивном режиме макетов страниц, адаптированных под различные разрешения экранов, будь то экраны смартфонов, планшетов, ноутбуков, телевизоров и прочего.

На основе построенных макетов производилась вёрстка страниц - HTML-структура, обрамлённая языком задания стилей CSS. Адаптивность страниц обеспечивается медиа-запросами, и обладает тремя фиксированными «вехами» разрешения экранов - от 320 пикселей до 900 пикселей, от 901 пикселя до 1200 пикселей и от 1200 пикселей.

Основные макеты интерфейса приложения представлены в приложении.

3.6 Выбор технологий для разработки основных алгоритмов веб-приложения

Все разработанные алгоритмы системы мониторинга можно условно разбить следующие группы:

алгоритмы авторизации;

алгоритмы взаимодействия сервера с АТС;

алгоритмы взаимодействия клиента и сервера;

алгоритмы поиска;

алгоритмы функциональности интерфейса;

вспомогательные алгоритмы.

Несмотря на то, что в данном приложении нет необходимости реализовывать процесс регистрации пользователей, так как все аккаунты создаются администраторами системы, тем не менее к реализации процесса авторизации необходимо подходить с полной осмотрительностью. На выбор технологий для возможности авторизации главным образом влияют следующие критерии:

Есть ли срок истечения валидности текущей сессии пользователя?

Есть ли необходимость использования различных механизмов получения токенов доступа от сервера различным типам клиентов (веб, мобильные приложения)?

Есть ли необходимость авторизации через сторонние провайдеры (например, LinkedIn или Facebook)?

Нужно ли генерировать специальные коды для обеспечения функциональности подтверждения email аккаунтов и сброса пароля?

Так как в данном приложении всё управление пользовательскими аккаунтами сводится к полномочиям администраторов системы, то отпадает необходимость в генерации уникальных кодов для сброса пароля и подтверждения валидности пользовательских аккаунтов.

В целях безопасности исключено использование сторонних провайдеров для аутентификации пользователей в системе мониторинга. Это связано с тем, что система мониторинга предназначена исключительно для работы по внутренней сети компании и содержит доступ к большому количеству приватных данных, как пользователей, так и компании. Потому в использовании таких протоколов, как OAuth 2 и OpenID Connect, нет необходимости. [46]

Система мониторинга представляет собой исключительно веб-приложение под все устройства, будь то персональные компьютеры, смартфоны или другие. Как следствие, серверной части приложения нет необходимости различать типы устройства конечного пользователя. Но при этом сессия пользователя должна иметь срок окончания в целях увеличения уровня защищённости данных системы мониторинга. Так, access-токен (токен доступа) пользователя должен быть валидным только на протяжении двадцати четырёх часов с момента его генерации сервером. После истечения суток токен должен быть удалён из списка валидных, в результате чего доступ к API будет ограничен клиентам, использующих данный токен доступа. При этом использование refresh-токена для автоматического получения нового валидного токена доступа не подразумевается.

Исходя из вышеописанных рассуждений очевидным решением является использование технологии JWT (JavaScript Web Tokens). Каждый токен создаётся сервером приложения в случае успешной авторизации пользователя и используется при каждом HTTP-запросе клиентов к API приложения. Токен передаётся в HTTP-заголовке «Authorization», содержит подпись-секрет, имеет фиксированное время существования и однозначно распознаётся сервером.[47]

Клиентские приложения общаются с сервером посредством REST API и в определённых случаях посредством WebSockets. Так, серверная часть обеспечивает стабильное подключение к базе данных приложения и предоставляет статичные конечные точки (англ., endpoints) API, через которые клиенты способны обмениваться информацией, используя HTTP-запросы. Данный подход сегодня является наиболее распространённым для приложений, построенных на клиент-серверной архитектуре.

Вся текущая информация о телефонных линиях и звонках предоставляется системой автоматизированной телефонии компании - Asterisk, обладающей своей собственной технологией предоставления данных - AMI (Asterisk Manager Interface). Цель AMI - генерировать и предоставлять имеющуюся у АТС информацию о телефонных линиях при каждом изменении данных посредством специальных эвентов в виде сырого текста. Цель серверной части приложения - найти способ получить эти данные и произвести их обработку (парсинг). При этом необходимо производить сортировку данных, так как не вся посылаемая AMI информация является ценной для системы мониторинга.

Исходя из того, что серверная часть веб-приложения использует язык программирования Node.js, то наиболее подходящей технологией для обеспечения взаимодействия сервера и АТС является свободно распространяемая библиотека «asterisk-manager», предоставляющая возможность «подписываться» на эвенты AMI и получать информацию при каждом их появлении. После проведения парсинга текста сообщений, создаются JSON-сообщения примерно следующего содержания (для эвента появления нового входящего звонка):

Event: QueueCallerJoin

{

'event': 'queuecallerjoin', (string)

'phone': 'Телефон клиента', (string)

'queue': 'Номер очереди', (int)

'agent': 'XXXX', (int) or (string 'deny')

'uniqueid': 'Уникальный идентификатор звонка', (string)

'id': 'Уникальный идентификатор звонка', (string)

'queues': [ Массив с активными очередями ],(array)

'calldate': 'yyyy-mm-dd hh:mm:ss',

'agent_connect': 'yyyy-mm-dd hh:mm:ss',

}

Все полезные данные после сохраняются в базу данных и отправляются клиентским приложениям. Так как такого рода операции производятся достаточно часто, а сохранение и чтение данных из базы данных занимает время, то было принято решение использовать WebSockets для передачи данных после обработки непосредственно клиентским приложениям. WebSockets по своей сути обладают схожим с AMI принципом работы. Так, клиентская часть приложения может «подписываться» на эвенты, генерируемые WebSockets на серверной части. Пересылаемыми данными могут быть, как примитивные строки, так и сложные JavaScript-объёкты.

Особенностями алгоритмов интерфейса является разбитие системы на компоненты и использование Flux-архитектуры для передачи данных между компонентами. Flux подразумевает возможность реактивного изменения приложением веб-компонент в случае, если данные, от которых они зависят, были изменены. [48] Тем самым пропадает необходимость самостоятельного отслеживания всех мест интерфейса, которые должны быть перерисованы в случае изменения тех или иных данных. Для используемого фреймворка React, существует официальная реализация Flux-архитектуры под названием Redux, которая и была использована для разработки клиентской части системы мониторинга.

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

Помимо прочего, приложение должно предоставлять возможностями непосредственного управления АТС через интерфейс и прослушивания звонков. Для управления АТС также используются комбинация технологий WebSockets и «asterisk-manager». Для прослушивания аудиосообщений используется технология WebRTC, встроенная в большинство современных браузеров, с помощью которой возможно путём использования различных протоколов создавать устанавливать каналы для передачи аудио и видеоинформации. Так как АТС «Asterisk» использует протоколы SIP и UDP, то именно через них и происходит передача пакетов аудиозаписей в системе мониторинга. 

4. Практическая реализация проекта

4.1 Введение

Практическую реализацию системы мониторинга и её функциональности можно разбить на следующие основные этапы:

разработка дизайна интерфейса приложения и его «карты» - структуры навигации по приложению;

вёрстка страниц;

создание структуры базы данных;

разработка программных алгоритмов и развёртывание приложения.

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

4.2 Разработка дизайна интерфейса приложения и его «карты»

Разработанная в данной работе система мониторинга представляет собой одностраничное веб-приложение (single page application - SPA), обладающее несколькими видами отображения контента. Несмотря на то, что пользователь фактически не изменяет URL страниц в браузере, содержимое приложения динамически изменяется, как если бы пользователь работал с привычным многостраничным веб-сайтом. Тем самым сохраняется видимость мультистраничности ресурса с целью упростить ориентацию конечного пользователя по интерфейсу. При этом скорость загрузки виртуальных страниц значительно выше, так как нет необходимости при переходе между логическими блоками веб-приложения подгружать новую HTML-структуру страницы с серверной части приложения.

Число виртуальных страниц вычисляется исходя и соображений бизнес-требований к приложению и проводится в два этапа. На первом определяются основные экраны отображения главного контента приложения, к которым относится:

страница авторизации, которая предоставляет пользователям возможность авторизации в веб-приложении;

страница отображения информации о состоянии телефонных линий списком, включая информацию об операторах и текущих звонках;

страница отображения информации о состоянии телефонных линий таблицей.

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

Страницы веб-приложения помимо предоставления доступа к функциональности системы мониторинга, должны также обладать интуитивно-понятным дизайном и не быть визуально перегруженными контентом. Так, графический интерфейс страницы авторизации должен предоставлять возможность авторизации пользователя путём ввода логина и пароля от внутренних сред компании. Регистрация в приложении осуществляется только администраторами системы, а следовательно, интерфейс не должен содержать специального отображения экрана регистрации. Также не подразумевается аутентификация посредством сторонних провайдеров (например, LinkedIn, Facebook и прочее). Макет страницы авторизации представлен на рисунке 12.



Рис. 12. Страница авторизации

Макет страницы отображения информации списком приведён на рисунке 13.

Рис. 13. Страница отображения информации списком

Цель данного вида отображать ключевую информацию по выбранным телефонным линиям на текущий момент времени. Каждая страница списка содержит только десять линий. Элементы каждой линии, такие как, «Всего операторов» раскрывают больше информации об операторах на данной линии и о звонках на линии. В свою очередь подробная информация по звонкам также может быть просмотрена. Скриншоты функциональных возможностей интерфейс представлены в приложении. Данная страница обладает следующей функциональностью:

отображение текущего состояния телефонных линий:

счётчика общего количества операторов;

счётчика активных вызовов на линии;

счётчика количества свободных операторов на линии;

счётчика количества занятых операторов на линии;

счётчика количества операторов на паузе;

счётчика количества недоступных операторов;

отображение информации по операторам на выделенных линиях:

SIP-номера и имени;

активных очередей оператора (телефонных линий);

статуса оператора на данной очереди (в разговоре, свободе, на паузе и другие);

в случае, если оператор на паузе - тип паузы и время на паузе;

в случае, если оператор в разговоре - тип текущего звонка (внутренний, внешний и другие) и время звонка;

пенальти оператора (приоритет в случае входящего звонка);

отображение информации по звонкам на выделенных линиях:

статуса звонка (внутренний, внешний, исходящий и другие);

информацию о разговаривающих (например, операторе и клиенте);

информации об общей продолжительности звонка в случае, когда звонок завершён;

информации о текущей продолжительности звонка;

информации о времени начала звонка;

информации о времени принятия звонка;

информации о времени ожидания звонка (сколько времени звонок не был принят);

ID-звонка (для системного администрирования и удобной навигации).

Особое внимание следует уделить элементу задания фильтров мониторинга - выбора телефонных очередей и операторов. Элемент представлен на рисунке 14.

Рис. 14. Элемент задания фильтров мониторинга

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

Аналогичную странице со списком линий функциональность предоставляет страница с табличным видом, представленная на рисунке 15.



Рис. 15. Страница отображения информации таблицей

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

К дополнительным страницам приложения относятся:

страница отображения общей информации только о телефонных линиях на текущий момент;

страница отображения информации только по телефонным звонкам.

Страницы предназначены только для большего удобства мониторинга и реализуют частичную функциональность приложения, описанную выше. Макеты дополнительных страниц представлены в приложении.

4.3 Создание структуры базы данных

Создание структуры базы данных происходило таким образом, чтобы обеспечить наибольшую (прозрачную) простоту взаимосвязи сущностей. База данных обладает следующими ключевыми сущностями:

телефонные линии (очереди);

операторы;

звонки;

пользователи, к которым относятся пользователи системы с ролями - администратор, менеджер, менеджер заказчика, супервайзер, наблюдатель.

Сущности представлены в базе данных отдельными отношениями, хранящими соответственно информацию о пользователях, телефонных линиях, операторах и звонках на линиях.

Особое внимание стоит уделить звонкам, которые, помимо только текстовой информации, обладают звуковыми дорожками. Все аудиофайлы транслируются в режиме живого времени на внешний накопитель серверного оборудования компании. Отношение «Звонки» хранит только названия аудиофайлов, сгенерированные по принципу совмещения даты и времени начала и окончания звонка, а также номера очереди и оператора. Для ускорения поиска медиа-файлов используется хеширование названий и их кластеризация в словарях базы данных. Так, файлы разбиваются на группы в зависимости от номера телефонной линии, то есть файлы расположены в соседних листах памяти, что способствует быстрому поиску и извлечению нужных данных.

Упрощённая ER-диаграмма базы данных представлена на рисунке 16.

Рис. 16. Упрощенная ER-диаграмма



Исходя из ER-диаграммы видно, что множество пользователей системы могут обладать (иметь доступ) ко многим операторам и телефонным линиям. В свою очередь каждый из операторов и каждая из телефонных линий могут быть просмотрены одним или несколькими пользователями. Аналогичной связью многие-ко-многим обладают отношения «Операторы», «Телефонные линии» и «Звонки». При нормализации данных каждая связь многие-ко-многим преобразована в две связи один-ко-многим к буферным таблицам. Так, например, взаимосвязь «Пользователи» - «Операторы» преобразована в «Пользователи» - «Пользователи-Операторы» - «Операторы». Однако в данной работе для удобства рассмотрим структуру основных сущностей до проведения нормализации.

Схема отношений «Телефонные линии» (queues), «Операторы» (operators), «Пользователи» (users) и «Звонки» (calls) и приведена в таблице 2, где тип данных «V» - VARCHAR, «С» - CHAR, «D» - DATETIME, «N» - NUMERIC.

Таблица 2. Схема отношения «Телефонные линии»

Содержание поля	Имя поля	Тип данных	Длина	Обязательность	Примечание
Идентификатор	q_id	N	4	+	PK
Название	q_name	V	100	+	уникальное
Номер в АТС	q_pbx	V	20	+	уникальное
Оператор	q_operator	N	4	+	FK
Пенальти	q_penalty	C	1	-

Таблица 3. Схема отношения «Операторы»

Содержание поля	Имя поля	Тип данных	Длина	Обязательность	Примечание
SIP-номер	o_sip	N	4	+	PK
Имя	o_name	V	50	+
Фамилия	o_surname	V	50	+
Площадки	o_platforms	V	500	-
Мульти-оператор	o_multi	C	1	+
Очередь	o_queue	N	4	+	FK



Таблица 4. Схема отношения «Звонки»

Содержание поля	Имя поля	Тип данных	Длина	Обязательность	Примечание
Идентификатор	c_id	N	20	+	PK
Оператор	c_operator	N	4	+	FK
Очередь	c_queue	N	4	+	FK
Дата и время начала	c_begin	D		-
Дата и время поднятия трубки	c_attend	D		-
Дата и время окончания	c_end	D		-
Номер	c_number	V	20	-
Продолжительность	c_duration	N	10	-
Тип звонка	c_type	V	10	+

Таблица 5. Схема отношения «Пользователи»

Содержание поля	Имя поля	Тип данных	Длина	Обязательность	Примечание
Идентификатор	u_id	N	6	+	PK
Пароль (sha)	u_password	V	128	+
Имя	u_name	V	100	+
Фамилия	u_surname	V	100	+
Очередь	u_queue	N	4	+	FK
Оператор	u_operator	N	4	+	FK
Площадки	u_platforms	V	500	+
Роль	u_role	V	20	+

4.4 Разработка программных алгоритмов и развёртывание приложения

Все алгоритмы, обеспечивающие работоспособность системы мониторинга, составляют «движок» разработанного программного обеспечения. В данной работе основным инструментом для разработки программной составляющей является язык программирования JavaScript. Другими технологиями, использовавшимися при разработке системы мониторинга, стали - React, Redux, Redux Sagas, Node.js (Koa), MySQL, WebSockets, Asterisk Management Interface (AMI), JavaScript Web Tokens (JWT), WebRTC, HTTP, SIP, TCP, JEST, Enzyme, LocalStorage, Cookies и многие другие. Система мониторинга обладает богатой функциональностью, а потому алгоритмов, обеспечивающих её работоспособность, большое множество. Среди них в данной работе рассмотрены только основные.

4.4.1 Алгоритмы авторизации

Как было описано в пункте «Выбор технологий для разработки основных алгоритмов веб-приложения», для реализации процесса авторизации в системе мониторинга используются JavaScript Web Sockets (JWT). Каждый токен содержит в себе необходимую для идентификации клиента информацию в формате JSON. Структура каждого создаваемого сервером токена следующая:

заголовок (англ., header);

полезная информация (англ., payload);

цифровая подпись (англ., signature).

Заголовок токена состоит из двух составляющих - это тип алгоритма кодирования подписи (в данном случае - это HS256) и тип токена, который по умолчанию является JWT. Пример такого заголовка:

{

“alg”: “HS256”,

“typ”: “JWT”

}

Вторая часть токена - полезная информация - содержит в себе информацию, запрашиваемую клиентским приложением во время авторизации. Чаще всего это информация о пользователе - его имя, email, время начала и время длительности пользовательской сессии и некоторые другие данные. При этом JWT не должен содержать информации, являющуюся тайной и способной скомпрометировать систему или пользователя. Например:



{

“sub”: “3232”,

“name”: “Denis Moroz”

}

Подпись необходима для объединения заголовка и полезной информации, представленных в виде формата Base64 URL Encoded и «секрета» - строки, известной только серверу и клиентам веб-приложения, и для дальнейшей проверки того, что токен не был изменён со стороны или подделан. При этом подпись кодируется алгоритмом криптографического шифрования SHA-256. Формула имеет следующий вид:

HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

В результате каждый токен представляет собой строку в формате Base64 URL, части которой разделены точками.

Токен создаётся при процессе авторизации пользователя, сохраняется в памяти серверной части и в куки (англ., cookie) клиентской части приложения, и отсылается при каждом HTTP-запросе между клиентом-сервером в заголовке «Authorization». При этом серверная часть приложения должна уметь декодировать токен и проводить процесс его достоверности.

try {

let token = await JWT.verifyJWTToken(ctx.cookies.get('jwt'))

if (token) {

ctx.state.user = jwt.decode(ctx.cookies.get('jwt'))

await next()

} else {

ctx.cookies.set('jwt', null)

ctx.redirect('/')

}

} catch (error) {

ctx.throw(401, error)

}

, где:

function verifyJWTToken(token) {

return new Promise((resolve, reject) => {

try {

jwt.verify(token, process.env.JWT_SECRET_KEY, function(err, decoded) {

if (err) return reject(err)

if (decoded === undefined) return resolve(false)

return resolve(true)

})

} catch (error) {

return reject(error)

}

})

}

Таким образом, в случае, если токен, отправленный клиентом серверу, оказался действительным, работа клиентского запроса может быть продолжена. В противном случае, клиент получит ошибку с кодом 401 - «Unauthorized».

4.4.2 Алгоритмы взаимодействия АТС, сервера и интерфейса

Основная сущность алгоритмов взаимодействия сервера с автоматизированной телефонной системой компании - это, используя подключение сервера приложения к AMI АТС получать информацию об изменениях, производимых на телефонных линиях, производить их обработку, и затем сохранять обработанную информацию в базу данных. Здесь наиболее важную роль играет обозначение со стороны клиента, какие именно эвенты AMI интересует систему мониторинга с целью проведения обработки только небольшого количества событий. К числу эвентов относятся следующие:

QueueCallerJoin - поступление нового звонка на определённую линию;

AgentConnect - взятие текущим оператором текущего звонка;

Hangup - окончание текущего звонка;

QueueMember - изменение состояния для текущего оператора на текущей линии;

QueueCallerAbandon - сброс звонка звонящим;

QueueCallerLeave - покидание оператором очереди;

AgentComplete - завершение разговора оператором;

AttendedTransfer - перенаправление звонка (направленное);

BlindTransfer - перенаправление звонка (случайное).

Информация присылается с AMI в неструктурированном виде по постоянно открытому подключению и затем попадает на специальные обработчики событий на серверной части системы мониторинга, разбивающим полученную строку на JavaScript-объекты:

case 'queuemember': {

agent: event.stateinterface.length === 4 ? event.stateinterface : event.stateinterface.split('/')[1],

queue: event.queue,

status: event.status,

penalty: event.penalty,

paused: event.paused,

lastcall: event.lastcall

}

Впоследствии данные объекты используются, во-первых, для сохранения информации в базу данных приложения с целью архивирования, во-вторых, для отправки информации клиентам веб-приложения. С учётом того, что структура таблиц AMI-эвентов в базе данных подготовлена изначально для удобного хранения обработанных данных, для сохранения информации используются обыкновенные SQL-запросы.

Для отправки подготовленных данных на клиентскую часть приложения используется WebSocket-подключение, открывающееся на время пользования пользователя приложением. Суть данного взаимодействия аналогична взаимодействию сервера с AMI с парой существенных различий - клиентскому приложению нет необходимости производить дальнейший парсинг данных, а также частота отправки данных в двух случаях разнится. Так, AMI отсылает данные при каждом изменении, происходящем на телефонных линиях. В то же время WebSocket подключение настроено таким образом, чтобы получать и отсылать данные только раз в секунду. Такой частоты обновления данных о состоянии телефонных линий достаточно, чтобы отображать актуальную информацию на пользовательском интерфейсе. Тем самым на примере упомянутого в предыдущем примере события “QueueMemeber” клиентское приложение получает данные в следующем виде:

{

“agent”: “SIP/7030”,

“queue”: “8441”,

“status”: “3”,

“penalty”: “1”,

“paused”: “0”,

“lastcall”: 2018-12-17T12:16:09.123Z

}



Все сообщения отсылаются в формате JSON для удобства работы с ними. Структура получаемых данных может разниться от события к событию. Однако с учётом использования фиксированного количества AMI-эвентов и благодаря тому, что JavaScript не является типизированным языком программирования, работа с данными не обладает особенными сложностями.

WebSocket подключение также защищено сервисом аутентификации пользователей (посредством валидации JWT) и в случае успешного установления подключения, отсылает пользователю основные данные обо всех доступных ему для мониторинга очередях (телефонных линиях) и операторов в зависимости от роли пользователя. Так, например, администратор системы может наблюдать одновременно за всеми очередями. В то же время менеджеру заказчика доступны для просмотра только очереди заказчика.

4.4.3 Алгоритмы интерфейса

После того, как данные отправлены с AMI на сервер и произведена их обработка, они перенаправляются на клиентское приложение (интерфейс или frontend приложения), где используются для прорисовки веб-элементов, отображающих актуальное состояние системы телефонии на данный момент.

Так как приложение является одностраничным (Single Page Application), то перезагрузка страниц с целью их рендеринга исключается. Вместо этого, ежесекундное получение данных происходит асинхронно в фоновом режиме. Пользователь имеет возможность только задавать фильтры мониторинга, но запросы на сервер отправляются автоматически.

Особенностью работы с данными на интерфейсе является использование возможностей Flux-архитектуры, предоставляемых библиотекой Redux. Так, приложение обладает следующими основными частями для работы с данными:

хранилищем (англ., store);

экшенами (англ., actions);

редьюсерами (англ., reducers);

сагами (англ., sagas).

Хранилище предназначено для хранения текущего состояния данных в приложении. Фактически хранилище представляет собой большой объект со встроенными методами. В Redux-приложении может существовать только одно хранилище, являющееся глобальным для всего приложения. Данные в хранилище существуют только на время пользовательской сессии. Тем самым хранилище не является базой данных и может рассматриваться скорее в качестве кэша.

Экшены являются событиями, обладающими какой-либо новой информацией, предназначенной для отправки в хранилище. Экшены - единственный возможный механизм воздействия на хранилище. Однако важно понимать, что данные в хранилище не могут меняются непосредственно через экшены. Экшены только описывают изменение состояния. Они являются простыми JavaScript-объектами, имеющими поле типа и данных.

Наконец, редьюсеры указывают, какая именно информация в хранилище и каким образом должна быть изменена при появлении того или иного экшена. Другими словами, редьюсеры постоянно ожидают появление новых экшенов.

Также в определённых случаях перед передачи экшена в редьюсер, может происходить его предварительная обработка в Redux-саге. Данная предварительная обработка необходима в случае, если определённый экшен содержит асинхронные операции (например, посылает HTTP-запрос серверу). Редьюсеры же не предназначены для работы с фоновыми операциями и должны оставаться максимально простыми. Тем самым саги призваны решить проблему подготовки данных для редьюсеров.

Рассмотрим пример. Так, в случае, когда пользователь только открыл приложение и авторизовался в нём, будет создано пустое хранилище, которое наряду с прочим, будет содержать информацию о доступных пользователю телефонных линиях (очередях). Изначальное состояние хранилища в данном случае следующее:

{

“queues”: [],

…

}

Чтобы изменить состояние хранилища происходит вызов экшена «onAddQueueCallerJoinCalls»:

function onAddQueueCallerJoinCalls() {

return {

type: QUEUECALLERJOINCALLS.ADD_QUEUECALLERJOINCALLS

}

}

Так как данные о доступных пользователю очередях хранятся в базе данных, необходимо произвести к ней обращение посредством Redux-саги:

function* watchAddAllQueues(){

yield takeEvery(OTHERS.ADD_ALLQUEUES, addAllQueues)

},

где:

function* addAllQueues() {

const method = "GET";

const url = "/queues";

try {

const res = yield call(axios, {method, url});

const data = res.data.queues;

yield put(onAddAllQueuesSuccess(data));

} catch (error) {

console.log(error);

yield put(onAddAllQueuesError());

}

}

Результатом выполнения данной функции станет вызов нового экшена, уже содержащего массив доступных пользователю очередей (queues):

function onAddAllQueuesSuccess(queues) {

return {

type: OTHERS.ADD_ALLQUEUES_SUCCESS,

payload: queues

}

}

Наконец, редьюсер, настроенный на обработку данного типа экшенов, произведёт обновление состояния хранилища:

function all_queues(state = [], action) {

switch (action.type) {

case OTHERS.ADD_ALLQUEUES_SUCCESS:

return action.payload;

case OTHERS.ADD_ALLQUEUES_ERROR:

return state;

default:

return state;

}

}

В результате чего новое состояние хранилища будет следующим:

{

“queues”: [“8001”, “8002”, “8003”, …],

…

}

Несмотря на то, что Redux обладает обозначенными выше дополнительными шагами для обновления хранилища, тем не менее обеспечивается возможность «подписки» компонентов приложения к хранилищу. То есть, в случае, если некоторые компоненты интерфейса зависят от изменения состояния хранилища, то любое изменение этого состояния повлечёт автоматическое изменение и зависящих элементов. В результате полностью отпадает необходимость ручной обработки изменений для отдельных элементов интерфейса, что особенно важно в интерфейсе системы мониторинга с многочисленными ежесекундными изменениями. Вкупе с реактивностью, предоставляемой фреймворком React, обеспечивается полная динамичность веб-элементов, легкость их перерисовки.

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

constructor() - вызывается перед непосредственным рендерингом React-компоненты и используется для объявления переменных;

componentDidMount - вызывается стразу же после рендеринга основной структуры компоненты и потому очень удобен для проведения асинхронных операций с целью подгрузки стартовых данных. Также подключение WebScokets происходит на данном этапе.

componentWillUmount - вызывается на этапе устранения компоненты из DOM (Document Object Model);

render - является этапом непосредственного рендеринга контента;

shouldComponentUpdate - вызывается при каждом обновлении состояния компоненты (в том числе и состояний Redux-хранилища).

Использование жизненного цикла фреймворка в значительной степени повышает производительность и отзывчивость интерфейса за счёт возможности гибкого ререндеринга веб-контента. Так, например, пользователь обладает информацией обо всех текущих звонках ещё до момента прорисовки интерфейса:

componentDidMount(){

let queuemember = [];

ws.onmessage = (message) => {

this.event = JSON.parse(message.data);

switch (this.event.event) {

case "queuecallerjoin":

if (ids.includes(this.event.uniqueid)) break;

else {

ids = ids.concat([this.event.uniqueid]);

this.props.onAddQueueCallerJoinCalls(this.event); // add call to queueCallerJoinCalls redux state

this.props.onAddActiveQueues(this.event.queues); // add queues with active calls to [activeCallsQueues] redux store

break;

}

…

}



4.4.4 Алгоритмы онлайн-трансляции звонков

Отдельной особенностью системы мониторинга является возможность прослушивания активных звонков в интерфейсе приложения в режиме реального времени. Для этого используется технология, реализованная в большинстве современных браузеров, WebRTC (Web Real-Time Communications). WebRTC позволяет веб-приложениям получать доступ к текстовому, аудио- и видео-контенту и обмениваться медиа-данными между браузерами без необходимости посредника (сервера). Кроме того, пользователям веб-приложения нет необходимости устанавливать какие-либо расширения или другое стороннее программное обеспечение.

Однако следует понимать, что WebRTC по-прежнему не имеет единого стандарта, а потому его реализация в различных браузерах может отличаться. Однако для решения этой проблемы кроссбраузерности существует библиотека Adapter.js, разработанная Google.

В простейшем смысле алгоритмы прослушивания звонков в режиме реального времени работают следующим образом. Сперва устанавливается peer-to-peer (точка-точка) подключение между двумя клиентами системы мониторинга посредством RTCPeerConnection-интерфейса. После того, как подключение было установлено и открыто, медиа-потоки могут быть добавлены к подключению. Медиа-потоки могут содержать любое количество слоев (дорожек) медиа-данных, где каждый слой содержит данные одного формата (например, только текст).

Чтобы установить подключение, один из клиентов должен послать сигнал-предложение (Offer) с SDP-строкой, содержащую всю необходимую информацию о параметрах подключения - какой тип данных будет отправлен, формат данных, какой протокол отправки будет использован, IP-адрес и порт, и прочее. Обмен информацией происходит посредством протокола SDP (Session Description Protocol). Второй клиент, получив сигнал, генерирует сигнал-ответ (Answer) - SDP-строка с информацией о данной точке подключения - и отправляет его по тому же каналу первому клиенту. В результате обмена информацией каждая точка имеет представлении о собственных настройках (local description) и удалённых (remote description).

function makeCall() {

const servers = null;

peerConn1 = new RTCPeerConnection(servers);

peerConn1.onicecandidate = c => onIceCandidate(peerConn1, c);

peerConn2 = new RTCPeerConnection(servers);

peerConn2.onicecandidate = c => onIceCandidate(peerConn1, c);

peerConn2.ontrack = getStreamRemote;

navigator.mediaDevices.getUserMedia({

video: false,

audio: true

})

.then(getStreamLocal)

.catch(error => {

this.handleRTCError(e);

});

},

где:

function getStreamLocal(streamData) {

localStream = streamData;

const audio = localStream.getAudioTracks();

localStream.getTracks().forEach(t => peerConn1.addTrack(t, localStream));

peerConn1.createOffer(options)

.then(localDescription, onCreateSessionDescriptionError);

}

function getStreamRemove(streamData) {

if (audioEl2.srcObject !== streamData.streams[0]) {

audioEl2.srcObject = streamData.streams[0];

}

}

Установленное подключение позволяет передавать медиа-данные по заданным каналам, транслировать данные между клиентами в режиме реального времени, а также сохранять аудиодорожки в базу данных с целью их архивирования.



Заключение

В ходе данной работы разрабатывалась система мониторинга сети телефонных линий компании в режиме реального времени. Проведя анализ предметной области во второй главе данной работы было выявлено, что текущие решения, существующие на данный момент на рынке, не удовлетворяют требованиям бизнеса по причинам своей негибкости и высокой стоимости. Потому создание собственной системы мониторинга явилось более подходящим решением.

Для этого было проведено планирование процесса разработки системы мониторинга сети телефонных линий, разработана её концепция и техническая архитектура, выполнена программная реализация системы и дизайн её интерфейса. Физически система мониторинга представляет из себя систему следующих основных взаимодействующих частей - автоматизированной телефонной системы, базы данных, серверной и клиентских приложений, системы контроля версии и системы разворачивания.

С целью сокращения затрат на процесс разработки программного продукта и уменьшения сроков были рассмотрены различные возможные подходы к процессу разработки. Исходя из того, что гибкость и изменяемость разрабатываемого решения является главным критерием при выборе подхода к разработке, было решено придерживаться Agile-подхода. Так, были разработаны алгоритмы авторизации, взаимодействия автоматизированной телефонной системы с серверной частью приложения и серверной части с клиентской. Создана и реализована структура базы данных приложения и алгоритмы работы с аудио-потоками текущих звонков на линиях с целью возможности их прослушивания для лучшего контроля качества.

Разработанная система мониторинга обладает возможностью предоставления полной информации о выбранных конечным пользователем телефонных линий и операторах, включая отображение технической информации о звонках на выбранных линиях.

Использование «гибкого» процесса разработки, единого языка программирования JavaScript для всех частей веб-приложения и Docker-контейнеров на Linux-серверах компании для развертывания программного обеспечения позволяет без лишних усилий расширять систему мониторинга при необходимости с минимальными затратами.

Использование разработанной системы мониторинга позволило повысить эффективность контроля за работой операторов, и как следствие повысить эффективность качества работы контактного центра в целом. На данный момент разработанный программный продукт активно используется в компании. Только за один квартал использования системы мониторинга, прибыль компании увеличилась на 11% с примерным снижением издержек в 4%.

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



Список использованных источников

1. Объём инверстиций корпораций в ИТ-стартапы в 2016-2018 гг. [Электронный ресурс] / CNews. - Режим доступа: http://www.cnews.ru/news/line/2018-11-19_obem_investitsij_korporatsij_v_itstartapy_v_20162018, свободный (Дата обращения: 6.01.2019 г.).

2. Global WealthTech investment in the first three quarters of 2018 [Электронный ресурс] / FinTech Global. - Режим доступа: https://fintech.global/global-wealthtech-investment-in-the-first-three-quarters-of-2018-has-already-set-a-new-record, свободный (Дата обращения: 6.01.2019г.).

3. Интернет-технологии в современном бизнесе: преимущества и рекомендации [Электронный ресурс] / Kirulanov Digital Marketing. - Режим доступа: http://kirulanov.com/internet-texnologii-v-sovremennom-biznese-preimushhestva-i-rekomendacii, свободный (Дата обращения: 10.01.2019 г.).

4. Hartpence, B. Packet Guide to Voice over IP / Bruce Hartpence - Sebastopol: O'Reilly Media, 2013. - P. 2-34.

5. Hersent, Oliver. IP Telephony. Deploying Voice-over-IP Protocols / Oliver Hersent, Jean-Pierre Petit, David Gurle - Chichester: John Wiley & Sons Ltd., 2005. - P. 103-125.

6. How to perform DOS Attack On VOIP Network [Электронный ресурс] / Medium. - Режим доступа: https://medium.com/@SwiftSafe/how-to-perform-dos-attack-on-voip-network-kali-linux-eb7c2c2ce1f5, свободный (Дата обращения: 4.02.2019 г.).

7. VoIP Services Market to Record Strong Growth in Corporate and Individual Consumer Segmets by 2020 [Электронный ресурс] / Transparency Market Research. - Режим доступа: https://www.transparencymarketresearch.com/article/voip-services-market.htm, свободный (Дата обращения: 8.02.2019 г.).

8. Word Wide Web Consordium [Электронный ресурс] / W3C. - Режим доступа: https://www.w3.org, свободный (Дата обращения: 12.02.2019 г.).

9. Contact & Call Centers - Reduce Call Center Costs & Develop a Call Center Strategy [Электронный ресурс] / FCBCO. - Режим доступа: https://www.fcbco.com/services/call-center-strategies, свободный (Дата обращения: 20.02.2019 г.).

10. The Best VoIP Providers and Phone Services 2019 [Электронный ресурс] / PCMag. - Режим доступа: https://uk.pcmag.com/internet-telephony-voip/41717/the-best-voip-providers-and-phone-services, свободный (Дата обращения: 21.02.2019 г.).

11. Crookshanks, E. Practical Sofware Development Techniques: Tools and Techniques for Building Enterprise Software / Edward Crookshanks - London: Apress, 2014. - P. 84-101.

12. Процессы разработки программного обеспечения [Электронный ресурс] / ScienceSoft. - Режим доступа: https://www.scnsoft.com/ru/how-we-work, свободный (Дата обращения: 24.02.2019 г.).

13. Методологии разработки ПО [Электронный ресурс] / Javarush. - Режим доступа: https://javarush.ru/groups/posts/647-metodologii-razrabotki-po, свободный (Дата обращения: 24.02.2019 г.).

14. Blokdyk, G. V-Model The Ultimate Step-By-Step Guide / Gerardus Blokdyk - Schwдbisch Hall: 5STARCooks, 2018. - P. 45-69.

15. V-Model (software development) [Электронный ресурс] / Wikipedia. - Режим доступа: https://en.wikipedia.org/wiki/V-Model_(software_development), свободный (Дата обращения: 28.02.2019 г.).

16. Kanban vs. Scrum [Электронный ресурс] / Atlassian. - Режим доступа: https://www.atlassian.com/agile/kanban/kanban-vs-scrum, свободный (Дата обращения: 1.03.2019 г.).

17. The Pros and Cons of Agile Product Development [Электронный ресурс] / UserVoice. - Режим доступа: http://community.uservoice.com/blog/the-pros-and-cons-of-agile-product-development, свободный (Дата обращения: 1.03.2019 г.).

18. What is Iterative Model [Электронный ресурс] / Professional QA. - Режим доступа: http://www.professionalqa.com/iterative-model, свободный (Дата обращения: 2.03.2019 г.).

19. Iterative and incremental development [Электронный ресурс] / Wikipedia. - Режим доступа: https://en.wikipedia.org/wiki/Iterative_and_incremental_development, свободный (Дата обращения: 2.03.2019 г.).

20. Top Programming Languages Used in Web Development [Электронный ресурс] / CLEVERISM. - Режим доступа: https://www.cleverism.com/programming-languages-web-development, свободный (Дата обращения: 8.03.2019 г.).

21. Web programming languages: the best languages for web development [Электронный ресурс] / Digital Guide. - Режим доступа: https://www.ionos.com/digitalguide/websites/web-development/web-programming-languages, свободный (Дата обращения: 8.03.2019 г.).

22. Graves, Michael. The Complete Guid to Servers and Server+ / Michael Graves. - Cengage Learning: Thomson Delmar Learning, 2006. - P. 244-276.

23. Как работают дата-центры: сегодня и завтра [Электронный ресурс] / Habr. - Режим доступа: https://habr.com/ru/company/vps_house/blog/343282, свободный (Дата обращения: 10.03.2019 г.).

24. Comparing AWS vs Azure vs Google Cloud Platforms For Enterprise App Development [Электронный ресурс] / Medium. - Режим доступа: https://medium.com/@distillerytech/comparing-aws-vs-azure-vs-google-cloud-platforms-for-enterprise-app-development-28ccf827381e, свободный (Дата обращения: 12.03.2019 г.).

25. Функциональные диаграммы [Электронный ресурс] / StudRef.com. - Режим доступа: https://studref.com/311808/informatika/funktsionalnye_diagrammy, свободный (Дата обращения: 15.03.2019 г.).

26. Функциональные диаграммы [Электронный ресурс] / Studopedia. - Режим доступа: https://studopedia.su/12_26433_funktsionalnie-diagrammi.html, свободный (Дата обращения: 15.03.2019 г.).

...