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

Есть несколько вариантов. Эвентбейзд гейтвей, complex gateway, таска с завершающим эвентом. От кейса наверное зависеть будет как лучше) в данном кейсе лучше это вне процесса держать

Спасибо,  скорей всего на другом сервере запускается где нет классы

Уважаемые, подскажите как быть, есть потребность редактировать описание процесса в java, нужно удалить стрелку

ServiceTask currentServiceTask =(ServiceTask)modelInstance.getModelElementById(id);
 
currentServiceTask.removeChildElement(outgoingFlow);

далее по коду используем fluent builder, добавляем нужные элементы
BpmnModelInstance modelInstance = currentServiceTask.builder()
….done()
После сохраняем новое описание процесса
processEngine.getRepositoryService().createDeployment()
.addModelInstance("newDefinition.bpmn20.xml", modelInstance)
.deployWithResult()
 
На последнем шаге получаем ошибку связанную с тем что в xml в блоке BPMNDiagram остается след удаленного обьекта(пути)
«no bpmnElement referenced in <bpmndi:BPMNEdge id="Flow_1wrj511_di"»

Вопрос как обойти эту ситуацию:
1)      Можно ли удалить самим fluent builder-ом?
2)      Можно ли удалить modelInstance полностью?
3)      можно ли игнорировать этот warning при сохранении
по гайду currentServiceTask.getOutgoing().remove(outgoingFlow) тоже не работает

не прошло и 10 лет!!!
(эм... или прошло? нет, всё-таки не прошло - в 2013-м году завели тикит :))

в следующем релизе Камунды планируют добавить поддержку то ли Liquibase, то ли Flyway - какого-то одного из этих средств; какого именно - пока не ясно

если интересно последить или даже внести свой ценный вклад ценным комментарием, это тут:
https://jira.camunda.com/browse/cam-1038

Счастье-какое! Ура!👍👍👍

хм, так они же и так выкладывают миграции

а в ямл camunda:
 bpm:
   database:
     schema-update: false

получалось их без изменений использовать в liquibase или flyway?

ага, вот ща используем

в ликвибейз

мне не удавалось (приходилось допиливать), сейчас попробую объяснить, почему:

- допустим, мигрирую версию движка камунды с 7.13 на 7.14

кейс №1: везде, где это приложение будет разворачиваться с чистого листа (например, интеграционные тесты в составе самого приложения, тесты в CI-пайплайнах, новые тестовые стенды), не надо накатывать скрипты, так как движок Камунды создаст схему БД при старте приложения, если в БД нет камундовских таблиц

кейс №2: везде, где это приложение уже было развёрнуто (тестовые стенды и прод), надо накатить SQL-скрипты, а уже потом стартовать приложение с новой версией (7.14) в данном примере

а вам как удалось разрулить эти два кейса в liquibase без допиливания скриптов?

мы скрипты не при поднятии пода гоняем, а при билде

и сама апликуха не гоняет миграции, они отдельным пайпом гоняются при поднятии версии

то есть на самих подах отключено создание схемы камунды и прочее, настроен коннект к бд.

то есть запускали вручную для конкретного тестового стенда и прода?
типа где-то нажать кнопку "накатить эти скрипты конкретно на это окружение (тестовое или прод)"

Я смотрю на dockerhub уже появилась 7.15.0 без чёрточки алфа, как раз проверю как это будет с переходом

ну не вручную, пайпы катают всё, согласно ансиблу, при повышении версии апликухи.

ansible не знаю, но общую картину понял - скрипты отдельно от приложения; где-то есть список или признак окружений, на которые надо накатить скрипты при билде