сейчас несколько штук, в перспективе думаю максимум 10

Тогда я бы подумал про DMN-таблицу.

Входное значение — process definition key.

Выходные значения — эти 10 параметров для конкретно этого процесса.

Если строк в этой таблице не очень много и если Вам не нужна экзотика (например, обращение к этой таблице в listener-е по 400.000 раз в день), то это может быть решением.

DMN-таблицу можно версионировать. Выходные значения можно использовать в определении процесса.

DMN, да, я про нее не подумал.. спасибо, подумаю в этом направлении

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

а про это решение не знаете? оно реально вообще? Оверрайдить sql скрипт вставки в таблицу и расширить класс processDefinition

> - добавить нужны колонки в таблицу - но как заставить камунду в той же транзакции писать эти поля?

Я против того, чтобы лезть во внутренности Камунды или ее базы без крайней необходимости.

Например, всегда есть риск, что через 10-20 лет надо будет развернуть Ваше приложение на новой машине и кто-то забудет сделать эти изменения в базе данных Камунды.

Есть масса альтернатив. Можно сделать отдельный REST endpoint, которому Вы передаете process definition key, а он отдает JSON. Сделать это можно либо на Джаве, либо средствами СУБД (Оракл такое умеет, если не ошибаюсь).

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

На мой взгляд, оба этих варианта надежнее, чем что-то менять в базе Камунды.

Кстати решение с кастомными свойствами может не быть проблемным в плане производительности.

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

=> Я бы опытным путем проверил, есть ли сущетвенные тормоза при хранении Ваших данных в кастомных свойствах.

да, но эти свойства хранятся в BLOB

согласен что в случае добалвения своих столбцов в таблицу мы очень сильно зависим от версии камунды и от наката миграций

Есть еще вариант — вынести эти особые поля из Камунды.

То есть — когда Вы запускаете процесс в Камунды, Вы извне передаете значения этих полей как переменных процесса.

Допустим, есть банк. У него есть общий процесс. Одна из входных переменных — вид процесса (открыть кредитную карту, закрыть счет и т. п.). Вид процесса передается извне. В зависимости от значения этой переменной вызывается соотв. подпроцесс.

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

вообще эти поля нужны не в момент запуска процесса

а грубо говоря всегда

поэтому удобнее их хранить на уровне самих дефинишенов

может быть вам подойдет отдельная база данных, в которой вы можете создать свои таблицы и подключить второй DataStore в спринге?
я бы 100 раз подумал, но как вариант )

у нас есть свои таблицы, но мы стремимся уменьшать их количество ..

нашел на форуме похожий вопрос
https://forum.camunda.org/t/global-variable-of-process-definition/11682
тоже пишут про отдельный сторадж..

отдельный сторадж ..

Если уже есть свои таблицы с нужными данными, почему нельзя их заиспользовать?