всем привет!
можно ли вручную перенести процесс дальше? в системе есть данные для следующей активити, но почему-то закрутилось выполнение предыдущей.
в это время деплоили другие сервисы - возможно поэтому.
можно ли подложить сразу в БД камунды следующую, а зацикливщийся проставить как-то, как выполненный?

> можно ли вручную перенести процесс дальше?

В Enterprise Edition в кокпите можно двигать токен.

Дамы и господа камунданты,

У кого-нибудь было следующее неожиданное поведение?

Камунда присваивает экземпляру процесса числовой идентификатор (например, 135) вместо универсального уникального идентификатора (например, 98631715-0b07-11ec-ab3b-68545a6e5055).

Подробности см. https://stackoverflow.com/questions/69011609/why-does-camunda-generate-a-numeric-process-instance-id-instead-of-uuid

оно так работает в случае настройки
camunda.bpm:
 id-generator: simple

Спасибо.

Добавление config.setIdGenerator(new StrongUuidGenerator()); в конфигурационный класс решило проблему.

Юрий, Дмитрий, спасибо!
буду пробовать

Дмитрий, удалось решить проблему с процессами в multi engine ?

Нашли обходной путь -- перевесили listener на промежуточное событие (см. "Update 3" на https://stackoverflow.com/questions/68850500/why-does-camunda-attempt-to-execute-a-task-listener-in-the-wrong-process-engine ). Камунда пока разбирается с этим поведением (см. https://jira.camunda.com/browse/CAM-13829 ). Планировалось, что когда Камунда починит баг, промежуточное решение заменим на правильное.

Но после моего отпуска заказчик решил, что нужна несколько другая функциональность:

1. Когда запускается процесс в call activity, надо передать в ElasticSearch идентификатор запущенного процесса.
2. Запускаемый процесс должен находиться в отдельном движке и ничего не знать про ElasticSearch.

Стандартный механизм (spring eventing) не подходит. Стартовый listener на call activity не может знать идентификатор запущенного процесса, потому что когда listener вызывается, этот процесс еще не запущен.

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

Небольшая презентация о том, как загружать в Камунду диаграммы и код сервис-тасков без перезапуска приложения (с помощью Clojure)

Видео: https://youtu.be/U5bddT0l6go

Код: https://github.com/mentiflectax/camunda-repl

Добрый день, подскажите, откуда можно вытащить последнюю активити у процесса, который externally\internally terminated?

Привет. Только в истории по идеи

по идеЕ

спасибо, я учту)

у меня был делегат, который я удалил, но при завершении уже новых тасков камунда ругается. Cannot complete task 13927712: Unknown property used in expression: ${MyDelegate}. Cause: Cannot resolve identifier 'MyDelegate'. MyDelegate больше нет нигде коде, включая bpmn-файлы. Но тем не менее всплиывает такая хрень? Из гипотез то, что, возможно, камунда уже создала какую-то таблицу где зарезервировано место под этот делегат и ничего с этим не поделать. Как быть?

А точно стартуют процессы новой версии?

как это проверить? Я запуская через камунда апи: http://localhost:3000/engine/engine/process-definition/key/career-changes-implementation/start

Так это видимо у вас инстансы остались на старой версии процесса. Нужно смигрировать инстансы на новую версию вашего процесса

Ну либо удалить их)

я же запускаю инстанс после изменений