DK
как только накопится количество токенов на завершающих сообытиях, равное количеству инстансов, мультиинстанс отстрельнеёт от себя токен
Size: a a a
2020 August 11
DK
при это некоторые интсансы его продолжат жить
S
Интересно. Пойду почитаю матчасть. Куда тогда посоветуете направить ветку уведомления?
DK
В просто завершающее событие
S
Ок, посмотрю, спасибо 🙏 а что на счёт разрастания схемы в таком юзкейсе? Это вообще нормальная практика?
DK
нормальная, главное чтобы у каждого квадратика был смысл бизнесовый и будет норм
DK
обычно нормальные процессы честные - это 10-15 процессов по 20-30 шагов
S
Ок, спасибо
DK
завезли багфиксы, в частности удаление толстых деплойментов https://jira.camunda.com/browse/CAM-12187?jql=issuetype%20%3D%20%22Bug%20Report%22%20AND%20fixVersion%20%3D%207.14.0-alpha2
2020 August 12
Доброго времени суток, товарищи знатоки. Правильно ли я понимаю, что процесс, который начался в пуле DEPO_1 автоматически не продолжиться в пулах DEPO_2 или DEPO_3? Что flow между пулами носит исключительно информативный характер? И чтобы запустить процессы в пулах DEPO_2 или DEPO_3 из пула DEPO_1 нужно воспользоваться, например, Message Events?
т.е вот будет правильней?
DK
правильно, но зачем
правильно, но зачем
зачем разбивать на пулы?
DK
ага
S
Больную тему трогают
ага
задача - "оживить" схему наподобие той которая на первом скриншоте. Дошел до этапа когда должны были запускаться процессы в других пулах и ... они не запустились) пошёл читать и понял что-то тут не так и надо использовать хотя бы message events. Если есть какие-то другие [намного более правильные] практики, то готов выслушать
скриншоты - это для примера, реальная схема больше
DK
поводов для использования мессаджей и межпроцессного взаимодействия должно быть разделение ответственности между пулами. Но ответственность бизнесовая. Каждый отдельный процесс должен иметь законченную ценность сам по себе.
DK
Альтернатива - callactivity, более простая, особенно если из вызываемого процесса надо назад результат получить