Обработка ошибок в бизнес-процессах

Бизнес-процесс, который тихо остановился на середине, хуже, чем отсутствие автоматизации: сотрудники думают, что заявка в работе, а она висит. В Битрикс24 нет отдельного блока try-catch, поэтому устойчивость процесса закладывают на этапе проектирования — проверками, тайм-аутами и запасными ветками. Разберём практику.

Почему процессы падают и зависают

Сбои бизнес-процессов делятся на две группы: падения (процесс останавливается с ошибкой) и зависания (процесс жив, но бесконечно чего-то ждёт). Причины у них разные.

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

Проверка данных на входе

Большинство падений устраняются до опасного действия — проверкой того, что данные вообще пригодны. Первым же блоком после старта ставят действие «Условие», проверяющее заполненность и корректность ключевых полей.

• обязательные поля не пустые (оператор «не пустое»);
• сумма — положительное число;
• дата окончания не раньше даты начала;
• ответственный назначен и активен.

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

Тайм-ауты и эскалация

Зависание на действии ожидания — самая частая жалоба. Лечится тайм-аутом: действия «Ожидание ответа сотрудника» и согласования поддерживают предельный срок, по истечении которого процесс идёт по запасной ветке.

1. задаём срок ожидания, например 2 рабочих дня;
2. если ответа нет — срабатывает ветка эскалации;
3. в ней уведомляем руководителя или переназначаем задачу заместителю.

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

Ошибки внешних вызовов

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

• после вызова проверяйте код ответа и содержимое в переменной результата;
• при ошибке — пауза и повтор через действие в цикле со счётчиком попыток;
• после N неудач — уведомление ответственному и остановка с понятным статусом.

Простой шаблон повтора: переменная Попытка, цикл с условием Попытка < 3, внутри — вызов, проверка результата и действие «Пауза». Так временный сбой сети не роняет весь процесс.

Уведомления и запасные ветки

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

• в каждой ветке возврата — сообщение инициатору с причиной;
• в ветках эскалации — уведомление руководителю;
• для критичных процессов — отдельное оповещение администратора портала.

Хорошая практика — единый служебный обработчик ошибок: параллельная или финальная ветка, которая при любом нештатном исходе пишет запись и шлёт уведомление. Так ни один сбой не остаётся незамеченным.

Права доступа и версии шаблона

Две неочевидные причины «необъяснимых» сбоев — права и версионность. Процесс выполняется от имени запустившего (или автозапуск — от системного пользователя), и если прав на действие нет, оно молча не отрабатывает. Проверяйте, что у инициатора есть доступ на изменение элемента и создание задач.

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

Итог

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

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