Платформа ERA предоставляет широчайшие возможности для формирования отчетов, как коробочных, так и проектных. Система обрабатывает огромное количество данных, которые раскладываются по хранилищам.
При работе с данными, как правило, в платформе применяется один и тот же паттерн, говорящий о том, что есть текущее и архивное представление тех или иных сущностей.
Рассмотрим на примере звонка. Когда абонент звонит другому абоненту создается сущность, которую мы называем текущий разговор или другими словами connection. Пока абоненты разговаривают между собой, эта сущность претерпевает целую цепочку изменений, обретает характеристики. Этот же самый процесс спроецируем на слой данных. Когда абонент снимает трубку и набирает номер, создается экземпляр класса CallCenterCurrentConnections, и в дальнейшем по нему происходят несколько десятков изменений - изменяются значения его атрибутов, изменяется статус.
В тот момент, когда разговор завершается, мы уже имеем полную информацию о том, что там реально происходило, и копия этого текущего объекта заносится в архив. В архиве появляется новый объект - экземпляр класса ArchiveConnection, который по своей структуре почти полностью повторяет объект CallCenterCurrentConnections, а объект класса CallCenterCurrentConnections удаляется.
Рассмотрим как эти объекты хранятся в базах данных. Платформа имеет разные типы хранилищ. По умолчанию, для текущих объектов используется СУБД MNESIA, распределенная между серверами, отказоустойчивая и очень быстрая. А для хранения архивов используется СУБД PostgreSQL, причем в ней выполнено разделение на таблиц на отдельные части, с целью улучшить производительность.
По умолчанию мы все архивы данных хранятся в PostgreSQL с помесячным разбиением на периоды. Это означает, что когда мы делаем какой-нибудь запрос с поиском конкретного разговора или выборки разговоров, то PostgreSQL лопатит не всю гигантскую таблицу за многие годы работы платформы, а только тот месяц, который содержит предполагаемую выборку.
Для высоконагруженных проектов мы рекомендуем использовать связку Apache Kafka колоночную аналитическую СУБД ClickHouse, что существенно увеличит производительность всей системы.
Преимущество такого подхода к разделению хранилищ для текущих и архивных объектов состоит в следующем: Изменения, проходящие по текущим объектам, таким как connection, не нагружают СУБД PostgreSQL и не приводят к её фрагментированности. Вместо этого они сохраняются в MNESIA изменяются там необходимое количество раз, а потом в PostgreSQL уходит одна единственная готовая строчка. Строчка об архивном объекте апдейтится только один раз, когда мы смикшировали записанный разговор – в атрибут архивного объекта заносится информация о ссылке на запись разговора.
По похожему принципу работают не только connections. Несколько connection в связке образуют seance (Сеанс). Сеанс создается в момент, когда образуется цепочка коннекшенов, например осуществляется переключение звонка. Таким образом, если мы хотим посмотреть, а сколько в контакт-центр было входящих обращений по телефону, то мы уже смотрим не в таблицу connections, а в таблицу seances, и там точно можно определить, сколько их было.
У нас хранятся текущие и архивные вызовы очередей. В тот момент, когда вызов встает в очередь, неважно голосовой он или не голосовой, у него появляется ряд дополнительных полей, и мы их не пытаемся закинуть в connection или seance, а прямо храним в отдельном классе, который в Mnesia называется CurrentACDCalls, и из которого создается его архивный клон в базе PostgreSQL или в базе ClickHouse – ArchiveACDCalls.
Похожая ситуация со статусами пользователей. В MNESIA CurrentUserStates – текущий список всех статусов операторов. Под статусом мы здесь понимаем не только состояние готов, не готов на перерыве, на обеде, но также состояние его телефонной линии, доступен, свободен, занят. В PostgreSQL завершенные статусы пользователей – ArchiveUserStates. Таким образом можно определить и сколько в реальном времени операторов с указанием их статусов, и сформировать хронологический отчет о рабочем времени оператора, который покажет сколько времени, в каком статусе он находился в прошлом.
Если двигаться дальше и смотреть на работу исходящих компаний, например, или модулей WFM (Workforce management), то там похожий паттерн сохраняется.
После развертывания платформы из коробки доступно около двух сотен коробочных отчетов. В этих отчетах есть и информация о текущих звонках и об архивных.
Некоторые дашборды содержат информацию объединенную. Например, в первом столбце мы видим текущий расклад по звонкам, вызовам очередей, статусам операторов; Втором мы видим информацию за последний час, где система для нас объединяет и текущее, и архивное за последний час; В третьем и четвертом столбцах мы видим за последние сутки и за последний месяц – это уже только агрегированная выборка почасовая (за сутки), или посуточная (за месяц).
Платформа предоставляет широчайший REST API, с помощью которого можно обращаться к данным, совершенно не задумываясь о том, в каких СУБД они хранятся. Можно с помощью HTTP запроса получить абсолютно любую информацию по текущим или по завершенным объектам с фильтрацией, группировкой, агрегацией. В том числе этим же механизмом пользуются наши коробочные отчеты. Таким образом, если необходимо под проекты разрабатывать свои отчеты, то можно сделать встроенными средствами платформы.
При создании пользовательских отчетов можно использовать базовые средства Join. Например, если нужно обратиться сразу к нескольким таблицам, а такой пример можно наглядно посмотреть на наших отчетах “Разговоры по сотрудникам” и “Разговоры по операторам”, то эти отчеты сначала получают полный список сотрудников или операторов и потом к нему добавляют агрегированные выборки из таблиц разговоров. Здесь нет привычного для инженера SQL, но мы считаем, что это и здорово, потому что разговоры и списки пользователей могут храниться абсолютно в разных базах, когда без Join построить отчеты и не удастся.
Также мы предоставляем инженерам для формирования продвинутых отчетов и классический язык SQL. Если таблицы, в которых лежат данные, хранятся в базе данных PostgreSQL, причем в одной и той же, то вы при разработке инструмента в приложении Билдер можно выбрать тип источника данных SQL-запрос, и написать привычный классический SQL, в него будут автоматически подставлены входные параметры, если они есть.
У многих наших отчетов сверху есть панель инструментов и кнопка Фильтр, которая позволяет фильтровать звонки по результатам, направлениям, операторам, номерам абонентов. Все эти параметры также доступны как в наших выборках через API, так и в SQL-запросах. Таким образом, если среди двух сотен коробочных отчетов вы не нашли того, что вам нужно, инженеры в процессе внедрения могут создать любые проектные отчеты, в том числе с использованием ваших проектных классов. Например, если вы в приложении Билдер реализовали CRM систему, или систему учета заявок, то, конечно, комбинированные отчеты по звонкам и письмам или мессенджерам в привязке к вашим клиентам или заявкам, также могут быть реализованы.
Отчет, как правило, в нашем понимании это не является какой-то такой особенной сущностью. Это всего лишь один из контролов нашей объектной модели Билдера, который, как правило, содержит либо таблицу, либо диаграмму, либо и то, и другое, и часто содержит наверху фильтр, который задает какие-то критерии для выборки данных. В один отчет можно включить или один контролл, и несколько. Можно их расположить рядом, слева направо, сверху вниз, в нужных пропорциях. Можно их закинуть по разным вкладкам, и пользователь будет переключаться. Можно скомпоновать несколько отчетов в так называемый дашборд или такую панель приборов, где собрана целая куча разной информации, в том числе из разных источников данных.
Отчеты, как правило, предполагают только просмотр информации, но в некоторых наших отчетах, особенно по текущим, доступны и некоторые действия. Например, отчет по текущим статусам операторов позволяет супервизорам и наблюдать текущий статус оператора, и изменять его, делая оператора готовым или не готовым к приему звонков. Это действие можно выполнять как по одному оператору, так и по группе, предварительно отметив нужные элементы галочками. Например, отчет по завершенным разговорам позволяет не только посмотреть, кто кому и когда звонил, но также прослушать запись разговора, сохранить ее в виде файла или для инженерной отладки на момент внедрения открыть SIP-диаграмму звонка. И все это из одного и того же отчета за счет верхней панели инструмента.
Изучайте Платформу ЭРА. Сегодня в России она является одной из самых современных и технологичных инструментов для организации решений в области корпоративной телефонии, контактных центров, автоматических сервисов и других классов информационных систем.