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

ну в обычных последовательных операциях это не необходимо но в последней операции перед paralell jon это по сути правило

но все равно лучше убрать канкаренси в принципе) чтобы откатываться нигде не нужно было)

ну иногда я его использую именно так

Добрый вечер, может кто по этому апи подсказать, в чем смысл запрос пихать вовнутрь запроса?

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

Хм... может проще поэксперементировать с API? Посмотреть как оно работает? И подумать нужно ли оно вам или как это можно использовать?

да я пытаюсь идею понять... )

Да очень просто, иногда ты не знаешь эти айдишники, но знаешь критерий отбора

Ну и запросов меньше, работает быстрее

а одновременно передавать и список ид и вложенный это норм?

Норм

Дамы и господа камунданты,

Кто-нибудь сталкивался со следующей проблемой?

Есть три движка:

1. core-workflow
2. core-processes
3. domain-hello-world

Процесс из core-workflow запускает процесс из core-processes, который в свою очередь запускает процесс из domain-hello-world.

У call activity в процессе из core-processes установлены listener на начало и завершение активности. Listener DomainProcessStartFinishTaskListener находится в core-processes.

Перед стартом процесса из domain-hello-world listener отрабатывает как надо.

А когда процесс в domain-hello-world завершается, в движке domain-hello-world вылетает ошибка -- класс DomainProcessStartFinishTaskListener не найден.

Почему-то Камунда пытается вызывать этот listener в движке domain-hello-world (где его нет и не должно быть), а не в core-processes (где он есть).

Код всего этого хозяйства есть на https://github.com/dptij/task-listener-problem .

Вопрос на форуме Камунды: https://forum.camunda.org/t/why-does-camunda-attempt-to-execute-a-task-listener-in-the-wrong-process-engine/29570/2

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

А каким образом вы запускаете процессы в другом движке? *нет желания включать комп, извините

Через tasklist запускаю один процесс, в нем call activity. Она запускает процесс в другом движке.

Если включен режим deployment-aware (а он включен во всех трех движках), то Камунда теоретически должна сама понимать, где какой процесс запускать.

Собственно, она правильно понимает, где выполнять процессы.

Проблема только с этим listener-ом.

Хм... а call activity в каком потоке запускает дочерний процесс? А главное как и в каком треде передается управление при завершении дочернего процесса родительскому?

Это хорошие вопросы. Завтра я со специально обученным человеком буду разбираться с этим багом, спрошу про это.

Не могу ответить на Ваши вопросы, т. к. не так хорошо знаю внутренности Камунды.

В трех движках кроме запускающего приложения (класс с методом main) и кода listener-а нет никакого кода. Только три BPMN-файла.

Поэтому все, что связано с потоками происходит где-то в недрах Камунды.

А чего вы пытаетесь добиться раскидывая процессы по движкам?

Формально: Выполнить требования архитекторов.

По существу:

1. Есть два вида функциональности -- общая для всех процессов и предметная.

Заказчик хочет, чтобы разработчики предметных процессов (таких как `domain-hello-world`) могли делать свои процессы,

а) не думая о технических деталях и
б) не мешая другим таким же.

В настоящем проекта в core-processes находится, например, код для сбора статистики. В ряде случаев, в т. ч. при старте и завершении предметного процесса, нужно отправить данные в другую систему. Для этого нужен listener.

2. У заказчика есть старый движок на базе BPMN, который встроен в их системный ландшафт. Камунда должна сосуществовать с этим старым решением и поэтому работать с другими системами также, как оно.

Из-за этого есть определенные требования к тому, как вызываются процессы.

3. Заказчик хочет, чтобы

а) кокпит,
б) REST engine и
в) сами процессы

были в отдельных движках, чтобы при необходимости можно было поднять дополнительные ноды ОпенШифта.

Поэтому есть core-workflow с кокпитом, но без REST engine. Есть core-processes с REST engine, но без кокпита. И есть domain-hello-world у которого нет ни кокпита, ни REST engine.

Компания Камунда в такой архитектуре не нашла ничего неправильного.