Вы переменную опишете в моделере, она сохранится в XML файле, который собственно и содержит BPMN диаграмму.
Или я не понял проблему, которую вы пытаетесь решить.

Или я хочу странного :) Спасибо.

А интересная идея  - параметризованный bpmn
Может иметь смысл для того чтобы подстраивать поведение в разных средах (dev/test/prod)
Можно моделер допилить)
Но подстановку надо делать перед деплоем в камунду

И для твиканья переменных в Java лезть не надо

Добрый день!
У нас есть Camunda внутри Spring Boot. Было требование поддерживать одновременно несколько версий одного и того же процесса. Для этого сделали bpmn-модель для каждой версии отдельно. Например, Process_1_v1.0.bpmn и Process_2_v2.0.bpmn. Стартуют процессы по самописному endpoint, который определяет нужную версию процесса и запускает его посредством runtimeService.startProcessInstanceByKey().
Под нагрузкой столкнулись с такой проблемой: в какой-то момент приложение перестало отвечать на запросы. Ошибка - HikariPool-1 - Connection is not available, request timed out after 30000ms.. Увеличили connectionTimeout и maximumPoolSize. Приложение проработало дольше, но в скором времени резко упала производительность, время отклика доходило до получаса. При этом пул соединений с бд переполнен не был и ошибок не получали.
Буду рад любым советам и рекомендациям по решению проблемы

название файлов никак не влияет на название processdefinition

а это влияет

если они одинаковые в разных файлах, то будут перетераться

про версии надо идти читать мануалы ну или просто идишники переправить

У нас, видимо, разные версии camunda-modeler. У меня вот так

а, я думал вы файлы переназвали

Коннекшены не освобождаются, надо выяснить причину

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

Коннекшены, я так понимаю, которые camunda делает для startProcessInstanceByKey? Не подскажете, как лучше это узнать?

А у вас процессы большие длинные? В них есть точки asynchronous continuation?

Коннекшены для обращения к бд. Проще всего через actuator, prometheus, grafana на стороне коннекшн пула и стороне бд

Да, достаточно большие. И async-и тоже присутствуют

Ну тут да, нужно метрики смотреть. Причин может быть много

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