В CRM Битрикс24 был настроен сценарий, который отправляет сообщения сотруднику в чат и дополняет логику через REST-действие (пример — вызов im.message.add). Долгое время цепочка работала стабильно: робот выполнялся, сообщение уходило, процесс двигался дальше.
После сезонного всплеска активности (возврат команды после праздников, резкий рост обращений и автоматизаций) один из роботов начал вести себя странно: ошибок нет, но выполнение стопорится на REST-действии, а следующие шаги не запускаются.
В чем была проблема
Симптом выглядел как «сломанный запрос»: робот выполняется, рядом крутится индикатор загрузки, но процесс зависает — сообщение перед REST-роботом отправляется, а после него уже нет. Это особенно сбивает с толку, потому что в журнале нет явной ошибки: ни ACCESS_DENIED, ни неправильных параметров, просто бесконечное ожидание.
На практике такой сценарий часто возникает, когда:
- сервис приложения временно отвечает медленнее (например, из-за повышенной нагрузки на сервере разработчика);
- в роботе не настроено корректное ожидание ответа;
- робот запускается не от того пользователя, у которого есть нужные права для действия/контекста.
Почему стандартных инструментов может быть недостаточно
Когда нужно «просто найти данные и подставить их в робот», логичным первым шагом обычно становится приложение уровня «Поиск элементов Списка по любым полям» — оно закрывает типовой запрос “как найти запись и вернуть значения”. Но в кейсах, где важны права выполнения, таймауты, поведение REST-вызова в очереди роботов и работа с JSON-структурой параметров, стандартные «поисковые» решения упираются в ограничения: они не контролируют, кто именно выполняет действие и как долго робот будет ждать ответа.
Поэтому для нестандартной диагностики и устойчивой автоматизации логично использовать более универсальный инструмент — «REST API — методы РЕСТ Битрикс24 и JSON в роботах и БП», где вы управляете самим вызовом, параметрами и сценариями ожидания.
Решение задачи
В этом кейсе сработали две настройки, которые часто недооценивают при сборке REST-роботов.
1) Указать, от чьего имени выполняется REST-робот
В настройках робота есть поле «Запускать от имени». Если робот запускается от пользователя без нужных прав, поведение может быть “тихим”: не всегда вы увидите явную ошибку, особенно если зависание происходит на уровне ожидания ответа/выполнения запроса. В разборе кейса рекомендация была простой: поставить запуск от имени администратора (или пользователя с гарантированными правами для нужного действия).
Важно: да, тогда сообщение может уйти «от администратора». В обсуждении всплыл нюанс, что у im.message.add нет отдельного параметра “отправитель”, и отправка идет от того, кто выполняет метод. Поэтому здесь обычно выбирают компромисс: либо админ как исполнитель, либо выделенный технический пользователь с правами, принятый в компании как “бот/сервис”.
2) Обязательно поставить период ожидания ответа — 10 минут
Ключевой момент: если в REST-действии не задан период ожидания, робот может «висеть» бесконечно, ожидая завершения. А в дни, когда сервис приложения отвечает медленнее обычного, это превращается в массовую остановку процессов.
Практика из кейса: выставить период ожидания 10 минут. Тогда даже при временных зависаниях:
- робот не блокирует цепочку навсегда;
- процесс либо дождется ответа, либо пойдет дальше по логике автоматизации, вместо полного стопа.
В обсуждении отдельно отмечалось, что минимальный период ожидания в интерфейсе может быть 5 минут, но для устойчивости при нагрузке лучше закладывать 10 минут.
Пример логики подхода на стартовом запросе
В CRM-роботе выполняется REST-вызов метода im.message.add с параметрами в JSON, где указывается DIALOG_ID (например, чат) и MESSAGE (текст с подстановками полей CRM и переносами строк). После этого по сценарию должны идти следующие роботы, но при проблеме цепочка останавливалась именно на REST-шаге, пока не были выставлены:
- запуск от имени пользователя с правами (админ/техпользователь);
- период ожидания ответа 10 минут.
Результат
После корректировки настроек и перепривязки прав (в кейсе также фигурировало обновление приложения и повторная настройка доступа) робот снова начал стабильно отрабатывать: сообщение ушло, зависание исчезло, процессы перестали останавливаться на REST-действии.
Вывод
Если REST-робот в Битрикс24 “раньше работал, а теперь зависает без ошибок”, начинать стоит не с переписывания параметров запроса, а с двух проверок:
- кто выполняет робота (права пользователя критичны);
- какой таймер ожидания ответа задан (для устойчивости — 10 минут).
Именно эти настройки помогают переживать пики нагрузки, когда приложение/сервер временно отвечает медленнее, но бизнес-процессы должны продолжать работать предсказуемо.
(1 оценок, среднее: 5,00 из 5)
Загрузка...