Как синхронизировать задачи между двумя порталами Bitrix24

1. Зачем это вообще нужно

Типичная ситуация: интегратор ведёт проекты клиентов в своём Bitrix24, а каждый клиент живёт в собственном портале. Одна и та же задача существует в двух экземплярах: исполнитель отчитывается у себя, менеджер клиента смотрит статус у себя. Без синхронизации кто-то вручную копирует описания, переносит статусы и пересылает файлы — и рано или поздно копии расходятся: у клиента задача «в работе», у интегратора давно закрыта.

Решение — автоматический обмен: правка на любом из порталов доезжает до второго. Дальше три способа это получить, по возрастанию готовности.

2. Вариант «руками»: вебхуки + REST

У Bitrix24 есть REST API и исходящие вебхуки, поэтому первое желание — написать скрипт: ловим событие OnTaskUpdate, читаем задачу, пишем её во второй портал. Прототип на пару порталов собирается за день. Проблемы начинаются на второй неделе эксплуатации:

• Лимит REST. Облачный Bitrix24 разрешает порядка 2 запросов в секунду на портал. Синхронизация задач — это не один запрос: чтение задачи, чтение чек-листов, чтение вложений, запись, догрузка файлов. Несколько активных проектов легко упираются в потолок, и портал начинает отвечать ошибкой лимита — причём страдает не только ваш скрипт, а все интеграции портала сразу.
• События теряются и не повторяются. Событие Bitrix24 — это один HTTP-запрос без повторной доставки: ваш сервер был недоступен две секунды — изменение потеряно навсегда. В payload события нет значений полей, только ID объекта, поэтому событие в принципе нельзя использовать как источник истины — только как сигнал «сходи и перечитай».
• Конфликты одновременных правок. Пока ваш скрипт переносит правку слева направо, кто-то правит задачу справа. Без сериализации и контроля версий вы получите «эхо»: старое значение перезапишет новое, поле начнёт прыгать туда-обратно.
• Файлы и чек-листы. Вложения задач в Bitrix24 — отдельная подсистема (Диск) со своими идентификаторами; наивная пересылка ссылок не работает, файл нужно скачать и загрузить заново. Чек-листы вообще не порождают событий задачи — их можно отследить только регулярным сравнением.
• Статусы меняются особыми методами. Обновить статус задачи обычным tasks.task.update нельзя — для переходов есть отдельные методы (complete, renew, start…), и выбор метода зависит от текущего статуса цели.

Итог: «руками» оправдано, когда нужен односторонний перенос пары полей по одному проекту и есть кому поддерживать скрипт. Полноценный двусторонний обмен руками — это месяцы работы и постоянная эксплуатация.

3. Вариант «готовое решение»: что оно обязано уметь

Если берёте приложение из Маркетплейса, проверяйте по чек-листу — это ровно те места, где ломаются самодельные интеграции:

• обмен в обе стороны, а не экспорт в одну;
• перенос вложений и чек-листов, а не только полей задачи;
• защита от эха и конфликтов при одновременных правках;
• жизнь внутри лимита REST: контроль расхода квоты, а не «пока не забанят»;
• поведение при потере события: есть ли страховочный опрос;
• поддержка коробочного Bitrix24, если один из порталов self-hosted.

4. Как это устроено в BIC

BIC — сервис двусторонней синхронизации порталов Bitrix24 для интеграторов. Ключевые решения как раз закрывают список выше:

• Маппинг проектов. Синхронизируются только проекты, которые интегратор явно связал; сопоставление полей и стадий задаётся в маппинге — у каждого портала своя структура.
• Обе стороны, включая чаты задач. Задачи с полями, стадиями, вложениями и чек-листами плюс комментарии в связанных задачах — с защитой от петли.
• События + страховочный опрос. События Bitrix24 дают скорость (изменение доезжает за секунды), регулярный опрос гарантирует, что потерянное событие не превратится в потерянные данные.
• Контроль лимитов. Расход REST-квоты каждого портала считается и показывается в кабинете, темп опроса настраивается по каждому порталу отдельно.
• Коробка. Для коробочного Bitrix24 есть модуль Local App — запросы выполняются внутри процесса портала, минуя ограничение облачного REST.

5. Что проверить перед запуском любой синхронизации

• Какие проекты связываем. Синхронизировать «весь портал» не нужно почти никогда — определите список проектов и владельца этого списка.
• Кто ответственный на каждой стороне. На целевом портале задачи должны на кого-то назначаться — решите правило сопоставления людей заранее.
• Что с лимитами. Прикиньте объём: число задач, частота правок, размер вложений. Для облака бюджет — примерно 2 запроса в секунду на портал, и его делят все интеграции.
• Что считается источником истины при расхождении копий — и как решение обрабатывает одновременные правки.
• Как останавливать. Пауза и отключение должны быть штатными операциями, а не «выключим сервер».

6. Частые ошибки

• Доверять событиям как транспорту данных. Событие — сигнал, не данные: не пришло — никто не повторит.
• Игнорировать чек-листы и файлы при оценке объёма работы — обычно это половина всей сложности.
• Синхронизировать всё подряд. Чем шире охват, тем быстрее упрётесь в лимит REST и тем больше мусора поедет между порталами.
• Не планировать конфликтные правки. «Одновременно никто не правит» — правят, начиная с первой же недели.
• Забыть про коробку. Приёмы, работающие в облаке, на коробочном портале ведут себя иначе — от установки приложения до доставки событий.

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