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

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

7.16 релизнулась? Неделю назад на 7.15 перешли..

В депенденси уже есть

в 7,16 liquibase ммм

DockerImage уже неделю назад лежат. Но официально выпуск сегодня

В простом случае статус определен однозначно в процессе в конкретной таске как значение переменной status. В более сложных случаях, например возврат на условную таску "Ввод данных", если для нее нужно различать первичный ввод или корректировка, то как раз в процессе будет ветвление, в котором однозначно можно установить нужный статус.
Мы тоже не отдаем эту логику в код, иначе потом концов не найдешь. Камунда - управление, код - исполнение.
А чисто визуально, для удобства, пишу названия статусов под тасками прямо на диаграмме.

а, ок, тогда выходит одинаково делаем

Добрый вечер.
Дмитрий не нажал кнопку на запрос от бота за определенное время и бот его забанил.
Убрал из бана 🙂
Теперь главное Дмитрию после присоединения к группе нажать на кнопку, когда бот обратится к нему в группе )

Понял, спасибо!)

Обновился на продактион. Все норм работает. Если честно там почти ничего не поменялось с 7.15, ну существенного. Половину фич релиза касается интерфейса Enterprise версии или особых применений. Проблемы могут быть только у того кто использовал Nashorn Javascript

Да, уже тоже протестировал, база накатывается без проблем

Доброго всем дня!
Подскажите, у меня в процессе есть 2 сервис таска и к ним привязан один java класс для обработки. То есть получается дублирование.
Насколько это грубая практика в контексте BPM?

2 таски делают одно и тоже?

Да

Но зачем?)

Очень плохая

Вынесите общий код в сервис, а у каждой таски должен быть сугобо один делегат

Который является мостиком между камундой и обычным кодом

(всегда мечтал так ответь на вопросы по программированию)