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

ну я честно говоря сначала так и подумал 😂
но у каждого проекта свои тонкости

имхо процессы (обработчики) меняются намного чаще чем протоколы (камунда или AMQP)

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

Согласен на все сто.

А нет, не на сто. Неправильно понял😂
У нас наоборот, обработчики практически не изменяют своё поведение, а вот процессы развиваем и меняем регулярно.

Ну я как раз это имел и ввиду)) неправильно выразился

Там очередь на БД. И это внутренняя очередь.
Если хотите делать что-то внешнее и глобальное, то это уже другой слой.

Не, у меня по другому.
Листенер единственное и всё.
Если хочется MQ интеграцию, то включить можно, если хочется ресты и лонгпулинг, то выключить нужно.
Листенер смотрит что пришла заявка на сервистаск и пишет сообщение в очередь, воркер читает очередь и если его задача, то делает лок и выполнение, потом завершает ее. Это пока MQ+Rest MQ вместо пуллинга, и Rest на завершение.
Думаю попробовать добавить полностью MQ. Т.е. вместо пуллинга и на завершение.

ну тут вопрос - зачем это нужно? что вы пытаетесь достичь навернув еще одну очередь над очередью

то что очередь на бд это коненчо не айс, но она не перестает быть очередью

я думаю что для UserTasks реально лучше работать через очереди, а вот с ServiceTasks непонятно ye;ty ли этот оверхэд

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

Это разные слои.
Для сравнения: апи для сервисов бэк2бэк и апи для сервисов фронт2бэк.

Всем привет, а есть какой то аналог simple zebee monitor, для camunda?

C Zeebe я не работал, но на первый взгляд Zeebe Simple Monitor — это аналог кокпита в Камунде.

Zeebe имеет Camunda Operate который похож на camunda cockpit.  A simple monitor он типа opensource и довольно глючный.

Я что-то угорел и не могу вспомнить, подскажите, - non interrupting event subprocess может сколько хочешь раз вызываться по факту каждого нового event?

Привет. Да, вроде так.
Мы даже переменную проставляем специально, чтоб два раза не реагировать(

спасибо, так и есть, проверил