В системе 1С:Документооборот 2.1 (ДО 2.1) механизм бизнес-событий является одним из самых мощных инструментов для автоматизации процессов. Однако стандартных событий не всегда достаточно для реализации сложной логики. Часто разработчики сталкиваются с необходимостью отслеживать специфические изменения в документах, например, заполнение дополнительных реквизитов, и на основании этого запускать или корректировать бизнес-процессы. Рассмотрим подробно, как работают детекторы, как написать свой код и какие нюансы следует учитывать при реализации.
Для начала разберем, что такое детектор в контексте 1С:Документооборот. Детектор — это специализированный алгоритм (код), который проверяет наличие определенных условий в базе данных. В отличие от подписок на события, которые срабатывают мгновенно при записи объекта, детекторы работают асинхронно.
Процесс обработки выглядит следующим образом:
Обработка бизнес-событий запускается по расписанию (обычно раз в минуту).Истина, в регистре сведений Произошедшие бизнес-события создается запись.Такой подход позволяет снизить нагрузку на пользователя при сохранении документа, так как тяжелые расчеты выносятся в фоновое задание.
Рассмотрим практический пример создания детектора. Предположим, нам нужно отслеживать окончание срока действия приказа для автоматического создания задачи ответственному. Главная задача детектора — найти объект, соответствующий условию, и убедиться, что событие по нему еще не регистрировалось.
Проанализируем пример функции детектора:
Процедура СоздатьСобытиеОкончанияСрокаДействияПриказа(Результат, ПараметрыВозврата) Экспорт
Результат = Ложь;
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ВнутренниеДокументы.Ссылка КАК Ссылка,
| ВнутренниеДокументы.Ответственный КАК Ответственный
|ИЗ
| Справочник.ВнутренниеДокументы КАК ВнутренниеДокументы
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПроизошедшиеБизнесСобытия КАК ПроизошедшиеБизнесСобытия
| ПО ВнутренниеДокументы.Ссылка = ПроизошедшиеБизнесСобытия.Источник
| И (ПроизошедшиеБизнесСобытия.ВидСобытия = &ВидСобытия)
|ГДЕ
| НЕ ВнутренниеДокументы.НеДействует
| И ВнутренниеДокументы.ВидДокумента = &ВидДокумента
| И НАЧАЛОПЕРИОДА(ВнутренниеДокументы.ДатаОкончанияДействия, ДЕНЬ) = НАЧАЛОПЕРИОДА(&ДатаОкончанияДействия, ДЕНЬ)
| И ПроизошедшиеБизнесСобытия.Идентификатор ЕСТЬ NULL
|
|УПОРЯДОЧИТЬ ПО
| ДатаОкончанияДействия УБЫВ";
Запрос.УстановитьПараметр("ВидДокумента", Справочники.ВидыВнутреннихДокументов.НайтиПоНаименованию("Приказ", Истина));
Запрос.УстановитьПараметр("ВидСобытия", Справочники.ВидыБизнесСобытий.НайтиПоНаименованию("Окончание срока действия приказа", Истина));
Запрос.УстановитьПараметр("ДатаОкончанияДействия", ТекущаяДата());
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Если Выборка.Следующий() Тогда
Результат = Истина;
ПараметрыВозврата.Вставить("Источник", Выборка.Ссылка);
ПараметрыВозврата.Вставить("Автор", Выборка.Ответственный);
КонецЕсли;
КонецПроцедуры
Разберем важные моменты в этом коде:
ПроизошедшиеБизнесСобытия по ссылке.ПроизошедшиеБизнесСобытия.Идентификатор ЕСТЬ NULL: Без этой проверки детектор будет находить один и тот же документ при каждом запуске регламентного задания, создавая бесконечное количество событий. Проверка на NULL гарантирует, что событие с данным видом для этого документа еще не создавалось.ПЕРВЫЕ 1: Детекторы в ДО 2.1 за один проход регистрируют одно событие. Система будет вызывать детектор до тех пор, пока он возвращает Истина. Это позволяет обрабатывать очередь объектов постепенно.Часто детекторы хотят использовать для "обхода" ограничений системы. Рассмотрим ситуацию: необходимо запустить процесс по шаблону, где часть задач привязана к дополнительным реквизитам. Если реквизит не заполнен, 1С:Документооборот не даст запустить процесс, выдав ошибку "Исполнитель не указан", даже если эта задача должна быть пропущена по условию маршрутизации.
Вместо сложного удаления задач через детекторы, проанализируем более изящные способы решения этой проблемы:
Выясним, как можно использовать подмену исполнителя. В шаблоне процесса для "проблемной" задачи установим исполнителем Автора документа или специально созданную роль "Технический исполнитель". Поскольку автор всегда заполнен, система позволит стартовать процесс. Далее, используя условие маршрутизации, мы проверяем заполненность нужного нам дополнительного реквизита. Если реквизит пуст — процесс идет по ветке в обход этой задачи. Если заполнен — задача создается, а ее исполнитель меняется программно в обработчике или через автоподстановку.
Проанализируем возможности скриптов. В версии КОРП можно использовать программные вставки прямо в схеме комплексного процесса. В точке действия "Перед стартом" можно прописать код, который проанализирует дополнительные реквизиты и, если исполнитель не определен, установит флаг пропуска этой задачи или подставит администратора для разбора ситуации. Это исключает необходимость регистрации лишних бизнес-событий.
Поскольку детекторы работают постоянно в фоне, неправильный код может существенно замедлить работу сервера. Рассмотрим рекомендации по оптимизации:
Предупреждение или Сообщить) приведет к ошибке. Для логирования используйте ЗаписьЖурналаРегистрации.Подводя итог, можно сказать, что детекторы в 1С:Документооборот 2.1 — это эффективный инструмент для создания реактивной бизнес-логики. Главное правило при их написании: всегда проверять факт существования события в регистре и минимизировать нагрузку запроса на базу данных.