Работа с бизнес-процессами в 1С:Предприятие 8.3 нередко преподносит сюрпризы, особенно на специфических релизах платформы, таких как 8.3.22.1750. Разработчики часто сталкиваются с ситуацией, когда код в обработчиках ПередСтартом или ПриСозданииЗадач кажется нерабочим: точки останова игнорируются, а попытки вызвать интерактивные окна приводят к критическим ошибкам. Проанализируем причины такого поведения и разберем способы решения этих проблем.
Одной из первых проблем, с которой сталкиваются программисты при отладке бизнес-процессов, является ошибка «Процедура или функция с указанным именем не определена (Предупреждение)». Выясним причину: модули объектов бизнес-процессов, включая все обработчики точек маршрута, выполняются строго на сервере.
В системе 1С:Предприятие существует жесткое разделение доступности методов. Рассмотрим основные моменты:
Предупреждение(), Вопрос(), ОткрытьФорму() доступны только на клиенте (тонкий, толстый или мобильный клиент).Если нам необходимо убедиться, что код в обработчике выполняется, вместо интерактивных методов следует использовать запись в журнал регистрации, используя групповую обработку объектов журнала, или вывод сообщений пользователю через Сообщить(). Рассмотрим пример правильной фиксации события на сервере:
Процедура ПередСтартом(Отказ)
// Вместо Предупреждение() используем запись в лог
ЗаписьЖурналаРегистрации("БизнесПроцесс.Старт",
УровеньЖурналаРегистрации.Информация,
ЭтотОбъект.Метаданные(),
ЭтотОбъект.Ссылка,
"Запущен процесс: " + Строка(ЭтотОбъект));
КонецПроцедуры
Часто возникает вопрос: почему метод Сообщить() работает в модуле объекта бизнес-процесса, а точки останова — нет? Проанализируем механизм работы сообщений. Когда код выполняется на сервере, платформа не выводит текст в окно сообщений мгновенно. Она накапливает все вызовы Сообщить() в специальный массив (буфер). После того как серверный вызов завершается и управление возвращается на клиент, этот массив передается клиенту, и пользователь видит все сообщения разом.
Важный нюанс: если бизнес-процесс стартует в рамках транзакции, которая завершается ошибкой, накопленные сообщения могут вообще не отобразиться. Именно поэтому использование Сообщить() не всегда является надежным способом отладки логики бизнес-процессов, для этих целей лучше использовать выгрузку журнала регистрации в Excel.
Ситуация, когда код очевидно работает (выводятся сообщения), но точка останова в конфигураторе не срабатывает, обычно связана с настройками отладки или спецификой исполнения кода платформой. Разберем основные шаги по исправлению этой ситуации:
Особое внимание стоит уделить обработчику ПриСозданииЗадач в первой точке маршрута. Рассмотрим ситуацию: пользователь нажимает «Старт», создается объект бизнес-процесса, записывается и тут же переходит к первой точке. Весь этот процесс может происходить в одной быстрой транзакции на стороне сервера.
Если точка останова не срабатывает именно в первой точке, попробуйте применить метод «принудительной остановки» для толстого клиента (если разработка ведется в нем), используя ВвестиСтроку() или Вопрос() внутри условия #Если ТолстыйКлиентОбычноеПриложениеТогда. Однако наиболее универсальным и современным методом остается использование Журнала регистрации.
Разберем пример диагностики выполнения обработчика задач:
Процедура ПриСозданииЗадач(ТочкаМаршрутаБизнесПроцесса, ФормируемыеЗадачи, СтандартнаяОбработка)
// Фиксируем факт входа в процедуру
ТекстЛога = "Обработка точки: " + ТочкаМаршрутаБизнесПроцесса.Имя;
Сообщить(ТекстЛога); // Для визуального контроля после выполнения
Для Каждого Задача Из ФормируемыеЗадачи Цикл
Задача.Наименование = "Обработать: " + ЭтотОбъект.Номер;
// Здесь можно добавить проверку заполнения критичных полей
КонецЦикла;
КонецПроцедуры
Как отмечают специалисты, релиз 8.3.22.1750 имел ряд зафиксированных ошибок, связанных с графической подсистемой. Это напрямую влияет на работу с Картой маршрута. Если конфигуратор закрывается с ошибкой Access Violation при попытке открыть схему бизнес-процесса, это является признаком программной ошибки платформы.
В таких случаях рекомендуется:
Подводя итог, можно сказать, что «неработающие» обработчики в 90% случаев оказываются работающими, но скрытыми от отладчика из-за серверного контекста или фонового исполнения. Внимательное отношение к контексту исполнения кода и использование журнала регистрации позволят успешно отладить даже самые сложные цепочки бизнес-процессов.