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

как это пофиксить, кто сталкивался?

Так БП тоже передавай из узлов в центр

(1) очевидный вариант, но он не подходит.
хотелось бы обойти.

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

(2) в (1) единственно правильный вариант.
БП может быть изменен, удален, и т. п. Все эти изменения также должны мигрировать.

"придет 3 копии бп с разными выполненными задачи в центр" // Если у тебя каждый раз разная последовательность выполнения каких-то трех задач приводит в итоге каждый раз к разному состоянию БП, то что-то у тебя не так с БП...

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

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

(6) интересная идея

(7) Ну ты же понимаешь, что в каждом из узлов БП не пройдет через точку слияния, т.к. будет выполнена только одна из трех задач.
А чтобы в центре БП пошел дальше, нужно выполнить последнюю задачу там. При загрузке этих всех задач в режиме загрузки (ОбменДанными.Загрузка = Истина) у тебя БП и не сдвигается...

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

(6) если задача без привязки к БП, то как он поймет какой БП они должны двигать? Делать параллельную связь задачи с БП?

<придет 3 копии бп с разными выполненными задачи в центр и нефакт что там он прочухается и пойдет дальше.>
И что? Это будет не три копии БП а три этапа состояния БП. Все равно  в итоге сохранится только последнее изменение. Если конечно обмен правильно обрабатывает коллизии.

(9) насчет режима загрузки очень интересно.
Надо попробовать будет.
И кстати когда в целях эксперимента в центре дернул на выполнение каждую из 3 выполненных задач - кусок после слияния затроился. Что как бы говорит и том что можно дернуть любую задачу?

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

"можно дернуть любую задачу?" // Смотря что у тебя там повешено на каждую из задач - возможно, в какой-то из них будет специфичный для интерактивного выполнения код, который в узле не выполнился, а в центре - должен.
Поэтому "подергать" нужно все задачи, что прилетают из узлов

(9) ну и получишь увеличение времени обмена на время выполнения задачи.

короче, вы я так понял любители геморроя

(14) Ну, если уж хочется красиво и без задержек в обмене, то вроде уже описал ранее - обмениваться не самими задачами, а объектами-маркерами-сигнализаторами. Отвечая на (10), то конечно маркер нужно будет связывать с реальной задачей, а после обмена шерстить маркеры и дергать реальные задачи

(13) после слияния просто создаются новые задачи - и создалось 3 набора этих задач. На сами задачи по выполнению ничего не навешено.

Ну, либо обмен задачами еше вынести в отдельный план обмена для исключения влияния ошибок при загрузке на другие обменивающиеся объекты

(17) Ну вот это и есть косяк, некритичный, конечно - ведь БП ведет себя согласно схеме и при выполнении последней из задач он создает следующие задачи.
Чтобы такого не было, нельзя сначала записывать в режиме загрузки три выполненные задачи, а потом их уже еще раз выполнить - контролируй при загрузке все самостоятельно. Как враиант - если это последняя задача перед точкой слияния, то выполняй только ее...

*если это последняя _выполненная_