Компании, активно использующие Битрикс24, понимают, насколько важна информация в рабочих чатах: переписка с клиентами, счета, отгрузки, файлы. Особенно, когда чаты составляют основу бизнес-процессов компании. Однако с развитием компании, бизнесу может стать тесно в облачной версии Битрикс24, поэтому возникает потребность перенести данные в коробку.
В этой статье расскажем как выполнить перенос чатов более 100 пользователей с сохранением хронологии, вложений и структуры диалогов. Задача осложнялась ограничениями API, жесткими сроками (2–3 недели) и необходимостью минимизировать downtime. Отметим, что организация рабочих процессов построена на многосторонних диалогах, в которых участвует около 30 человек.
Как поэтапно выполнялся перенос?
Процесс переноса чатов был организован следующим образом:
1. Создание мэппинга пользователей: разработка механизма сопоставления пользователей (создание мэппинга и скрипта).
2. Разработка скрипта для импорта чатов: создание основного инструмента для переноса данных.
3. Тестирование на нашей тестовой среде: выявление начальных проблем и ошибок (наша внутренняя среда + частичное тестирование).
4. Тестирование на DevStand клиента: выявление основных проблем и рисков (полное тестирование данных клиента).
5. Отработка замечаний и решение проблем: устранение ошибок и адаптация системы к требованиям клиента.
6. Параллельная разработка решения для дозагрузки: реализация механизма дозагрузки данных из-за срыва сроков.
7. Решение проблемы с интерфейсом Битрикс24: разработка скрипта для устранения проблем с сортировкой чатов.
Технические вызовы и решения
Оптимизация скорости загрузки
Изначально планировали грузить по одному пользователю за шаг, но:
-
У некоторых было слишком много чатов → тайм-ауты
-
Файлы замедляли процесс
Решение:
-
Разбили загрузку на 500 сообщений за шаг
-
Для чатов с файлами уменьшили размер партии
Проблема: новые сообщения во время импорта
Импорт занял несколько дней, а пользователи продолжали работать в облаке → часть переписки терялась.
Решение:
-
Механизм догрузки
-
Система запоминает ID перенесённых сообщений
-
После основного импорта загружает только новые данные (за последние 2 дня)
Баг с сортировкой чатов
После переноса диалоги отображались в случайном порядке.
Причина:
-
Bitrix24 добавляет системное сообщение с текущей датой при создании чата
-
Но мы загружали старые сообщения → конфликт дат
Решение:
Скрипт удаления первого системного сообщения в каждом чате
Теперь рассмотрим подробно как проходил процесс миграции данных
Прежде чем приступить к переносу чатов, необходимо было решить задачу переноса пользователей и других связанных сущностей.
Важнейшим элементом этого этапа было создание "мэппинга" - таблицы соответствия между пользователями в облачной и коробочной версиях. Без этого "мэппинга" корректная загрузка пользователей в чаты была бы невозможна.
После импорта пользователей и составления "мэппинга" мы перешли к импорту чатов. На каждом этапе этого процесса мы использовали "мэппинг" для проверки и обеспечения корректного сопоставления пользователей.
Перенос большого массива данных из облачного Битрикс24 в коробочный портал потребовал нестандартного подхода.
Главная сложность заключалась в технических ограничениях облачного Битрикс24:
-
Нет прямого доступа к БД — только REST API.
-
Строгие лимиты на запросы — не более 2 запросов в секунду.
-
Обязательная пагинация — нельзя получить все сообщения разом.
Пришлось использовать HTTP-запросы для порционной загрузки сообщений, но с учетом жестких сроков (2-3 недели), необходимо было оптимизировать процесс.
Мы реализовали схему, позволяющую эффективно извлекать и структурировать данные: создание чатов, сопоставление пользователей, добавление сообщений с сохранением всех вложений. Процесс был построен на использовании веб-хуков для получения диалогов каждого пользователя и последующей постраничной загрузке сообщений.
Представьте, что после переноса многолетней истории переписки с огромным количеством сообщений и файлов, каждый пользователь должен авторизоваться на DevStand и вручную проверить полноту и корректность своих чатов. Только после подтверждения всеми пользователями мы могли приступить к импорту на Production.
Однако у нас не было на это времени, поэтому ИТ-специалисты ограничились быстрой визуальной проверкой контекста диалогов и доступности вложений. После чего мы запустили импорт на Production.
Изначально мы планировали импортировать все данные по пользователям: один пользователь - один шаг импорта. Но у некоторых пользователей было слишком много чатов с огромным количеством сообщений.
Мы попробовали разбить задачу на более мелкие части: в ходе ряда попыток, мы пришли к разбиению переноса чатов на части, перенося по 500 сообщений за один шаг. Таким образом, в процессе проб и ошибок, мы нашли оптимальное решение, позволяющее обходить ограничения и успешно переносить данные.
Однако в чатах с большим количеством изображений и файлов приходилось уменьшать количество сообщений, загружаемых за один шаг. Мы искали оптимальный баланс между скоростью и стабильностью переноса, учитывая, что загрузка 500 текстовых сообщений занимает гораздо меньше времени, чем загрузка 500 сообщений с файлами. Поэтому, при выборе параметров загрузки приходилось учитывать этот фактор.
Отметим, что при импорте файлов важно учитывать расширение хранилища на стороне заказчика, чтобы места хватило для переноса всех данных.
Процесс дозагрузки чатов: почему был необходим
Импорт чатов занимал несколько дней, в течение которых пользователи продолжали использовать облачную версию Битрикс24. Это приводило к ситуации, когда переписка, созданная после начала импорта, не попадала в перенесенные данные.
Чтобы избежать потери данных, возникших в период импорта, мы разработали специальный скрипт "дозагрузки".
Он работает следующим образом: система запоминает идентификаторы всех перенесенных сообщений. После завершения основного импорта запускается процесс, который отфильтровывает уже загруженные сообщения и дозагружает только те, что были созданы за последние дни. Благодаря этому решению, к моменту перехода у пользователей коробочной версии Битрикс24 была полная и актуальная история переписки, что обеспечило комфортный и бесшовный переход.
Проблемы с интерфейсом: как разобраться с хаосом из тысячи сообщений
После успешной загрузки большого объема данных в Битрикс24 мы столкнулись с неожиданной проблемой в интерфейсе. Пользователи обнаружили, что диалоги перемешиваются в случайном порядке, что делало работу в системе крайне неудобной.
Отметим, что проблема была не в созданном коде, а в том, что при создании нового чата в Битрикс автоматически добавляется системное сообщение с текущей датой. При этом, мы загружали сообщения из прошлого, которые имели более старые даты. Из-за этого конфликта дат система некорректно сортировала диалоги.
Для решения этой проблемы был разработан скрипт, который удалял это первое системное сообщение в каждом чате. Это не нарушало логику работы системы, но при этом решало проблему с сортировкой диалогов.
После отработки всех замечаний и устранения проблем, наступал этап развертывания разработанного решения на Production-стенде. Важно отметить, что на этом этапе не происходило разработки как таковой, поскольку все скрипты и механизмы уже были созданы и протестированы. Задача заключалась в переносе скриптов на Production-стенд и запуске процесса импорта. После этого роль разработчика сводилась к постоянному мониторингу процесса, оперативному реагированию на возникающие проблемы и их решению для обеспечения бесперебойной загрузки данных.
Что мы имеем в итоге? Вся история переписки перенесена, файлы и хронология сохранены, пользователи не заметили перехода.
