Возьмите сборку с j2ee сервером и деплойте туда war сборки с новым процессом и делегатами

Или 2 контейнера поднимите, и обновляете их по очереди

Кнопка в модделере добавляет только xml-ку, код не добавляет.

Nick, Denis, спасибо, подтвердили мои предположения. Вариант с  j2ee сборкой и в класторе, то придётся сначала кидать новые делегэйты в deploy папку на каждом узле, и только потом деплоить новую модель..

Всем привет!

Ребята есть те кто отказался от камундовских групп и реализовал что-то свое?

А чем не подходят группы?

Вообще, там же везде можно писать выражения. У нас в candidate group написан вызов бина - маппера, который маппит наше внутреннее имя на AD группу. Это позволяет на разных средах разные группы использовать. Не подойдёт?

Всем привет🖖🏼
Кто-нибудь использовал уже: https://github.com/pinussilvestrus/camunda-modeler-wakatime-plugin/blob/master/README.md
?

Nikolay @trekhlebov вы стандартные группы используете? :)

Стандартные группы хорошо подходят для разграничения доступа к самой Camunda. Разработчики, админы, поддержка и др. Эти группы чаще всего подгружаются из Active Directory, кот. уже используется на предприятии.

Однако, когда нужно выделить небольшие или даже временные группы в рамках работы конкретного бизнес-процесса, то их лучше сделать с помощью атрибутов Candidate Users, Candidate Groups и заполнять их во время исполнения экземпляров упомянутого бизнес-процесса.

Например, вызывать (Rest) какой-нибудь микросервис по работе со штатным расписанием.

Такая своеобразная альтернатива user teams в IBM BPM.

Свой отдельный сервис для юзер тасков, и соответственно, групп. Т.к. камунд много и они независимые, а юзеры те же самые

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

На пример, есть тысячи экземпляров в разных точках процесса, который может длится до нескольких лет, после деплоя новой версии, запущенные экземпляры должны АВТОМАТОМ перейти на новую версию и продолжить выполнение процесса согласно новой модели.? Любые идеи очень приветствуются.

Есть хуки postdeploy, на которые можно свой код повесить

Автомиграция процессов — спорно.

Так в чем вопрос?

@PostConstruct
 public void startProcess() {
   runtimeService.startProcessInstanceByKey("loanRequest");
 }

вот оно

Ну, много всего. В новой версии процесса могут появиться новые переменные, которых не было в старой - с этим надо что-то делать. Если вы используете переменные-объекты или структуры, которые в новой версии процесса поменялись - с этим надо что-то делать.
Если сервисы, с которыми общается бизнес-процесс, поменяли API (и для этого вы обновили процесс), то опять же надо верифицировать данные, которые процесс передаёт, получает и обрабатывает.
Условно... В процессе версии 1 у вас на старте есть паспортные данные и ИНН, но нет СНИЛС клиента. В процессе версии 2 появляется СНИЛС. Значит его надо для уже активных инстансов процесса откуда-то взять.

то есть да, план миграции теоретически (и практически) можно создать