а статус ответа какой?

404

Может все-таки доку почитать?
Process definition with given key does not exist. See the Introduction for the error response format.

присоединяюсь к вопросу по best practice.
Подскажите как camunda может пережить отключение от БД?
Отправлять сообщения с ошибкой в какой-нибудь mq брокер и далее проводить компенсацию
Или делать retry ?

Привет) а почему она будет слать отдельно коммит то при переключении? У нас работает всё на дефолтных настройках хикари и лишних коммитов вроде не было

если БД не доступна... то будет просто откат транзакции. И все.

А потому что такое поведение описано для драйвера pgjdbc
Когда DatasourceTransactionManager передёргивает autocommit с true на false, то реализация постресового метода пошлет commit;

Я этот вопрос в гитхабе pgjdbc уже успел обсудить

хм, интересно. не знал о таком

Попробую ссылку приложить на тред:
github.com/pgjdbc/pgjdbc/discussions/2453

> Хотел уточнить это только в комьюнити версии 7.15.0 ?

Если Вы имеете в виду запрос

https://docs.camunda.org/manual/7.15/reference/rest/process-definition/get-xml/

то здесь нет отличий community edition от enterprise.

Enterprise edition от community edition отличается только веб-приложениями и наличием Оптимайза. Если та или иная функциональность доступна только в Enterprise Edition, то в документации это помечено плашкой.

В одной из переменных XML, см. ответ из документации.

привет еще раз! может кто знает хитрость, как хранить свои кастомные свойства на уровне process definition?
у нас варианты такие :
- класть в properties - тут проблема в том что они лежат только в XML, ни в какую камундовскую таблицу не выкладываются
- зашифровывать их в какое то текстовое поле, например имя. но это колхоз и плохо поддерживается
- класть в деплоймент какой-нибудь json своего формата, но это не уровень process definition а уровень деплоймента, то есть надо самому следить за соответствием полей из json и процессов
- сделать свою таблицу - риск несогласованности
- добавить нужны колонки в таблицу - но как заставить камунду в той же транзакции писать эти поля?

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

Я никогда этим не пользовался, но в Моделере можно указать свойства в разделе Extensions.

да, это и есть первый вариант. но он для нас непроизводительный, потому что нужно парсить XML

Если не секрет, что зто за кастомные свойства с точки зрения бизнеса?

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

Почему эти поля не могут быть переменными процесса?

потому что они относятся не к процессу, а именно к его определению. и они изменяемые

Сколько у Вас этих особых полей в среднем на определение процесса?

Меньше 10, десятки, сотни...