Еще вопрос: Ребята а как вы решаете вопрос с "membership" пользователей? Стандартная камундовская "Groups" негибкая. Приходиться в группу писать объект + роль. Например: OBJ_NEW_YORK_MANAGER
Еще вопрос: Ребята а как вы решаете вопрос с "membership" пользователей? Стандартная камундовская "Groups" негибкая. Приходиться в группу писать объект + роль. Например: OBJ_NEW_YORK_MANAGER
Свои инпут атрибуты + шаблон юзер таски, чтобы не забыть их заполнять.
Это подход, кстати, как юзер таска - законченная пользовательская активность, только тут законченная активность сервиса. В любом случае в камунде бизнес процесс, и каждый кубик это не код из if-ов, а результат для бизнес процесса.
Ребята кто как использует History Time to Live? Вы по окончанию процесса скидываете в какую-нибудь другую БД/систему? Или не заморачиваетесь и все храните в history?
Только вместо базы эластик. Хотя сейчас на одном проекте делают вообще по другому. Христом тоже отключен и сразу через логи по патернами в эластик. JMS типа старый век.
Интересный топик. Я вот считаю что оркестровку микросервисов делать на « камунде из коробки» нельзя. Она не имеет нужного интерфейса и его надо делать на уровне Java api