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