Как бизнес-процесс в Битрикс24 ломал синхронизацию с 1С

Проблема

На облачном портале была настроена синхронизация CRM с 1С. Периодически обмен зависал: 1С отправляла изменение в Битрикс24, но не успевала дождаться ответа.

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

В итоге причина оказалась не в передаче данных между системами как таковой, а в автоматизации, которая запускалась в Битрикс24 после изменения CRM-элемента.

Где искал причину

Для начала я разделил сам обмен и то, что происходило в портале после получения изменения.

1С
↓
изменение CRM-элемента в Битрикс24
↓
автозапуск бизнес-процесса
↓
действия процесса
↓
ответ интеграции

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

На этом портале ответ на изменение возвращался слишком поздно для интеграционного сценария, и 1С переставала ждать завершения запроса.

Причиной оказался бизнес-процесс

В CRM был шаблон, настроенный на автоматический запуск при изменении элемента. Поэтому изменение, пришедшее из интеграции, запускало тот же процесс, что и обычное изменение пользователем.

Сам по себе такой автозапуск нормален. Проблемой стала комбинация двух факторов:

изменение из 1С
+
долгая автоматизация в CRM
+
ошибки внутри бизнес-процесса
=
слишком долгий ответ интеграции

То есть лечить только сторону 1С или увеличивать время ожидания было бы недостаточно. Сначала нужно было привести в порядок процесс, который выполнялся после изменения CRM.

Сначала исправил сам процесс

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

После исправления процесс стал отрабатывать предсказуемо, но для интеграционного сценария всё равно оставался слишком тяжёлым. Обмен с 1С не должен зависеть от того, сколько действий выполняет внутренняя автоматизация портала.

Как отвязал интеграцию от долгой автоматизации

В автоматически запускаемом бизнес-процессе я добавил проверку источника запуска. Если изменение пришло от интеграции, процесс не выполняет всю тяжёлую ветку внутри текущего запуска.

Вместо этого он через входящий webhook запускает отдельный экземпляр процесса с той же бизнес-логикой и завершает текущий процесс.

изменение из 1С
↓
автоматический БП на изменение
↓
проверка источника
↓
это интеграция?
├─ нет → обычное выполнение
└─ да
   ↓
   запуск отдельного БП через REST
   ↓
   завершение текущего БП
   ↓
   исходный интеграционный запрос больше
   не держит тяжёлую ветку процесса

отдельный БП
↓
долгая бизнес-логика
↓
завершение независимо от исходного обмена

Для запуска отдельного процесса использовался REST-метод bizproc.workflow.start. В него передаются ID шаблона, идентификатор CRM-документа и при необходимости параметры процесса.

POST /rest/.../bizproc.workflow.start

TEMPLATE_ID = ID шаблона
DOCUMENT_ID = CRM-документ
PARAMETERS = параметры запуска

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

Почему схема сработала

Битрикс24 умеет автоматически запускать бизнес-процессы при изменении CRM-элемента. Поэтому внешнее изменение может затронуть не только данные, но и связанную с элементом автоматизацию.

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

Метод bizproc.workflow.start создаёт отдельный экземпляр процесса и возвращает его идентификатор. В этом проекте такой отдельный запуск позволил отвязать дальнейшую тяжёлую обработку от первоначального изменения, пришедшего из 1С.

Что важно учесть

Нужен надёжный признак интеграции

Условие должно однозначно определять, что изменение пришло именно из 1С. Конкретный признак зависит от проекта: технический пользователь, специальное поле, параметр процесса или другой контролируемый маркер.

Нельзя допустить цикл

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

Повторный запуск должен быть безопасным

Интеграция может повторить запрос после timeout или сетевой ошибки. Поэтому тяжёлую обработку желательно делать идемпотентной: повторный запуск не должен дважды создавать документы, отправлять одно и то же уведомление или повторно проводить одну операцию.

Webhook — это секрет

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

Сначала исправление, потом разделение

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

Результат

После исправления ошибок бизнес-процесса и разделения интеграционного запуска с основной автоматизацией синхронизация перестала зависеть от длительности тяжёлого процесса.

В результате получилось разделить два разных требования:

1С должна быстро получить ответ на изменение

и одновременно

Битрикс24 должен выполнить всю нужную бизнес-логику

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

Для диагностики подобных проблем полезен журнал взаимодействий коннектора 1С: в нём можно сопоставить отправленные запросы, ответы и ошибки обмена с тем, что происходило в Битрикс24 в тот же момент.