БД Itgrix

Пользуясь опытом работы с крупными клиентами, у которых каждый звонок на счету, мы пересмотрели способ хранения данных в Itgrix для приближения к 100% успеху своевременной обработки всех звонков.

Начиная с версии Itgrix bx 3.13.0, файл состояния state.json заменён на собственную SQLite базу данных приложения state.db.

Страница интерфейса настрой "БД Itgrix"

Это предоставляет целый ряд преимуществ:

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

• Хранение результата выполнения каждого шага обработки звонка предотвращает дублирование данных в CRM даже если звонок обрабатывается повторно

• Звонки, при обработке которых возникли ошибки, автоматически переобрабатываются по расписанию

• Переобработка звонков по расписанию и до-обработка звонков при восстановлении работы приложения выполняются в отдельном потоке с меньшим приоритетом для обеспечения обработки текущих звонков без задержек

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

• Централизованное хранение актуальных данных звонков позволило уменьшить объём логирования по умолчанию

• Интерфейсы для работы с базой данных (в админке и в командной строке) позволяют специалистам техподдержки легко находить любые проблемные звонки и точечно применять специфические решения для каждой ситуации

• Данные об успешной обработке звонков позволяют быстро найти какие действия были выполнены с CRM на конкретном звонке или выяснить статистику по сценариям звонков

Про некоторые из этих изменений мы бы хотели рассказать подробнее.

Результаты обработки каждого звонка

Критически важное отличие от предыдущего способа работы с данными звонков состоит в том, что завершение обработки звонка более не приводит к удалению данных о звонке:

• если звонок обработан успешно, то он удаляется только через 7 дней;

• звонки с ошибками хранятся до 30 дней.

Вместе с содержанием звонка (номера, разговоры, время ответа и т.д.) теперь также сохраняется результат выполнения каждого шага обработки звонка, в том числе данные всех созданных и изменённых объектов в CRM или причины не выполнения шага обработки (например, если номер в чёрном списке).

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

Переобработка звонков по расписанию

Хранение звонков с ошибками в течение 30 дней даёт время на коррекцию ошибок при помощи автоматической переобработки, а данные об уже выполненных действиях предотвращают дублирование при переобработке.

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

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

Настраиваемый объём логирования

Ранее логирование данных звонков было организовано путём вывода всех данных звонка на каждом событии звонка. Это позволяло всегда знать самое последнее состояние звонка, независимо от того, в какой момент могла прерваться работа приложения. Но, в зависимости от настроек Asterisk, могут существовать звонки с сотнями событий, и с каждым событием объём данных звонка увеличивается. Иногда это приводило к росту объёма логов до нескольких гигабайт и даже к риску переполнения диска.

Новый способ хранения данных в state.db перезаписывает данные звонка на актуальные, вместо добавления данных, поэтому найти самое актуальное состояние звонка можно даже если данные звонка совсем не выводились в лог, и объём данных растёт гораздно медленнее.

Теперь доступно три варианта вывода данных звонка в лог:

• никогда,

• только в конце звонка (по умолчанию),

• на каждом событии (как ранее).

Настройка доступна в админке на странице настроек модуля.

Блок настроек частоты логирования данных звонка

Мы стремимся достичь 100% успешной обработки звонков с минимальными задержками. Новый способ хранения данных значительно приближает нас к этой цели, повышая надёжность работы приложения и скорость обработки звонков.

Будем рады вашим отзывам и предложениям по улучшению работы приложения!