Коллеги, здравствуйте.

Суть задачи:
Имеются два бизнес-процесса. Одна из точек маршрута первого процесса имеет вид ВложенныйБизнесПроцесс, при инициализации в ней задачи создаются несколько экземпляров второго процесса (сделано для независимой адресации и чтобы проще было РЛСы накладывать, а также для большей универсальности механизма). Необходимо отследить завершение всех вложенных процессов, и только после этого выполнить ведущую задачу. Проблема в том, что ведущая задача автоматически уходит на выполнение при завершении любого из вложенных процессов. Если проверяю в событиях перед/при выполнении ведущей задачи с установкой флага отказа, то откатывается вся транзакция, в том числе и выполнение задачи вложенного процесса и, как следствие, завершение вложенного процесса.

Вопросы:
1. Правильно ли создавать несколько вложенных процессов для одной задачи? В ДО для каждого экземпляра вложенного процесса создается отдельная задача, но я не знаю, насколько верен такой подход, ведь ФормируемыеБизнесПроцессы - Массив, и я полагал, что платформа должна отследить завершение всех вложенных процессов перед тем, как выполнить ведущую задачу.
2. Действительно ли задача уходит на выполнение при завершении любого процесса и не отслеживается завершение всех процессов? Не исключена возможность того, что у меня она где-то уходит на выполнение принудительно, но однозначного ответа в документации я не нашел.
3. Можно ли где-то впилиться в пределах одной транзакции между завершением вложенного процесса и выполнением ведущей задачи и принудительно, но красиво зафиксировать транзакцию раньше, чем она дойдет до события ПередВыполнением ведущей задачи?

Версия платформы 8.2.19.130.

Заранее спасибо за Ваше участие.

(0) точки разъединения и слияния посмотри, может будет достаточно.
Самый хитрый способ - вставляем элемент "Ожидание" и делаем петлю "Если все процессы завершены" да - продолжаем, нет - возвращаемся к элементу "Ожидание"

(1) Интересненько, но как-то костыльно, ведь ведущая задача выполнится к моменту входа в этот новый элемент (если я правильно понял, что речь об еще одной точке маршрута с условием), а у меня помимо исполения задач есть еще и наблюдение, то есть, наблюдатели по ведущему процессу получают сводную информацию по вложенным процессам, если ведущая задача в этой точке не выполнена

(1) Точки разделения подразумевают предопределенный набор точек маршрута, тогда как у меня речь о динамическом формировании однотипных параметризуемых сущностей с независимым параллельным выполнением (по сути, асинхрон, только в другой плоскости). Сколько будет вложенных процессов - неизвестно и неважно. Как они завершатся, также не важно, нужно только отследить, чтобы они завершились все, так как на следующей точке уже идет сводный анализ результата выполнения предыдущей задаче.

надо на карту добавить разделение и слияние, тогда ни чего искать не надо - оно само контролирует.

ну, либо, перед выполнением искать и отказывать

(2) так на точке разделения создаём кучу БП, на точку слияния они придут сами одновременно (ну или как получится) контроль возложен на основной БП

5+ Разделение - ничего нет - Слияние, в Разделении создали БП в Слиянии получили результат их работы

(4) (5) То есть, ПредыдущаяТочка ---> ТочкаРазделения ---> ТочкаВложенныхПроцессов ---> ТочкаСлияния ---> СледующаяТочка?
И тогда платформа начнет контролировать весь массив вложенных процессов? Сейчас попробую, спасибо.

У точки разделения есть только одна исходящая линия

(4) >> перед выполнением искать и отказывать
В этом случае откатывается вся транзакция, в том числе и выполнение задачи вложенного процесса, что не должно расцениваться, как ошибка

(4) (5) Получается так, что на карте маршрута нужно задать несколько выходов из точки разделения, тогда как у меня только одна. Вы предлагаете наплодить гвоздями несколько болваночных точек? В таком случае, я мысленно аплодирую такому решению.

(10) Пробуй без ТочкаВложенныхПроцессов
Прямо в разветвлении генерируй столько БП скольку нужно и стартуй их, в слияние основной БП приедет, когда завершатся все созданные БП

11+ только признак укажи что это подчинённый БП, сейчас не помню, поле что-то типа "ведущий БП" у подчинённого

(11) (12) Ненене, что-то далеко Вас занесло, коллега) Это явный костыль)

(13) Это штатный механизм, костыль был в (1) - ручное ожидание всех БП

+13 Причем не будет работать, потому что точка разделения тупо стартует все следующие точки маршрута (по крайней мере, в этой версии платформы), никак на них не влияя, и уж тем более абсурдным выглядит утверждение "создай процессы в точке разделения". Тут или я не лыжник, или лыжи не смазаны.

И подчинение указывается в точке маршрута, от вида которой Вы здесь же и предлагаете отказаться, что тоже выглядит сомнительно.

(14) Динамика, понимаете? Я не могу заранее в карте маршрута указать, сколько именно у меня будет вложенных процессов, их может быть один, два, десять, триста в зависимости от аналитики ведущего процесса.

+16 И платформа штатно подразумевает создание нескольких вложенных процессов для одной точки маршрута, так где же здесь костыль, если речь идет о поиске возможности отследить этот самый штатный момент завершения вложенных БП, если уж платформа сама не соизволит свою штатную фичу штатно отработать? Или же лучше нагородить левых бессмысленных ветвлений с точками создания вложенных процессов, которые, на самом деле, не вложенные процессы. и дать платформе думать, что это простой набор параллельных задач? В таком случае есть решение куда проще - на той же точке маршрута генерируем несколько ведущих задач, и они автоматом сгенерируют под себя по одному процессу, и не толкнется ведущий процесс дальше, пока не завершатся все ведущие задачи, при неодходимости просто условие поставить, которое будет отслеживать завершение всех ведущих задач.
Но не к этому стремимся же, речь идет о прямом наследовании один-ко-многим, если платформа подразумевает возможность генерирования нескольких вложенных процессов для одной задачи, то должна быть возможность и отследить выполнение так же в рамках одной задачи.

(17) тут надо пробовать, логика примерно такая: создаём подчинённые БП на точке разветвления и ожидаем их на точке слияния. Основной задачи, вроде, может и не быть - её роль выполняет вложенный БП.

(18) Что Вы вкладываете в понятие "создаём подчинённые БП на точке разветвления"? Можете меня просветить, я немного не понимаю этого утверждения, потому что уверен, что на точках разделения нет событий, и они не имеют отношения к вложенным процессам.

>> Основной задачи, вроде, может и не быть - её роль выполняет вложенный БП
Что, простите?

(19) Давно с БП не возился, подзабыл.

(20) В любом случае, спасибо за предложенные варианты =)

Ап

Ответы на два основных вопроса:

1. Для одной задачи должен быть строго один вложенный процесс.
2. В методе ПриСозданииВложенныхБизнесПроцессов используется массив для оптимизации создания - событие вызывается один раз для всего пула задач, созданных на данной точке, и массив ФормируемыеБизнесПроцессы генерируется в соответствии с массивом ФормируемыеЗадачи.

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