Понял, спасибо за инфу

инциденты как Максим говорит - это камунда такая "Все у меня лапки, завите умных кожанных мешков"

Подскажите, коллега не успел подтвердить, что он не бот. Как можно его разбанить?

пусть еще разок попробует

Спасибо. Всё ок.

Подскажите плиз как возможно автоматизировать регресс при развёрнутой камунде на сервере?
Есть пока идея использовать апи камунды и дергать ресты для проверки! Насколько это рационально? Видел офиц доклады по тестированию, но они используют локальную камунду..

На сервере тестируют только то, что невозможно протестировать локально, а именно

а) подключения к сторонним системам (правильный ли URL, пропускает ли запросы брандмауэр и т. п.) и
б) взаимодействия с теми системами, которые нельзя замокать локально.

Все остальное можно и нужно тестировать локально.

1. Код сервис-тасков можно тестировать квадратно-гнездовым JUnit-ом. Если у Вас в диаграммах много скриптовых тасков, значит надо их убрать и переписать на Джаве.

2. Правильность диаграмм BPMN тоже надо проверять локально.

Вот инструмент для отображения тестового покрытия:

https://github.com/camunda-community-hub/camunda-bpm-process-test-coverage

Пример теста:  https://github.com/camunda-community-hub/camunda-bpm-process-test-coverage/blob/master/examples/junit4/src/test/java/org/camunda/bpm/extension/process_test_coverage/examples/OrderProcessTest.java

3. Если нужно тестировать какие-то спринговые штучки (аутентификацию, например), то для этого во время автоматического теста поднимают локальный Спринг Бут с Камундой и там все тестируют.

См.  https://docs.camunda.org/manual/7.15/user-guide/spring-boot-integration/testing/

Поэтому вопрос: Что именно Вы хотите тестировать на сервере? Почему?

В процессе много микросервисов и постоянно обновлять и запускать локально тестирование кажется довольно странным.
Развернут стенд на котором в любой момент можно обновить сервис и сразу запустить тесты.
Так же уже настроены интеграции с др ас.

Вы что хотите тестировать -- Камунду или микросервисы?

Микросервисы

Тогда бы я разделил задачу:

1. В Камунде Вы проверяете (локально), что ее сервис-таски отправляют правильные запросы в микросервисы и правильно обрабатывают ответы от микросервисов.

2. Микросервисы тоже тестируете локально (юнит-тесты и все такое).

3. На стенде тестируете правильность конфигурации (то, что Камунда обращается с правильным микросервисам по правильному адресу) и сетевую доступрость (Камунда и микросервисы могут общаться друг с другом).

Сейчас
П1 отсутсвует а за кем в идеальном флоу закреплено ?
П2 за разработчиками
А п3 тестируются задачи п1 и п3 на стенде выполняет тестировщик

Просто не очень понятно если разработчику нужно добавить переменную на процесс, он допиливает сервис при этом дописывает юнит тесты. И передаёт это тестировщика для выполнения п 1?

> если разработчику нужно добавить переменную на процесс, он допиливает сервис

Я не понимаю, почему добавление переменной в процесс как-то влияет на сервис.

Можете описать Ваш процесс с точки зрения бизнеса?

Выдача например кредитной карты.
В зависимости от определенных правил сервис должен формировать дополнительную одну переменную с разными значениями. юнит тесты разрботчика сработали ок.
Но при тестировании выяснилось что переменная верная но значение нет. И сообщение др сервису формируется неверное.
Дернув рестом все переменные проверил что в зависимости от правила она верная. Для работы сервиса все ок для интеграции ошибка. Или я путаю тёплое с мягким

> В зависимости от определенных правил сервис должен формировать дополнительную одну переменную с разными значениями.

Переменные процесса в Камунде должен менять только код сервис-тасок в Камунде.

Микросервис не должен напрямую что-то менять в Камунде. Микросервис может отправлять Камунде сообщения (correlate message), но не может менять переменные процесса.

В противном случае у Вас будут ненужные зависимости и как следствие проблемы с тестированием.

В приложении вариант реализации того, что Вы хотите.

Сервис-таска в Камунде отправляет запрос стороннему сервису.

Когда сторонний сервис обработал запрос, он вызвает correlate message по REST API Камунды.

https://docs.camunda.org/manual/7.15/reference/rest/message/post-message/

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

А в ней Вы ставите переменные как надо.

В стороннем сервисе Вам тогда будет достаточно проверить, что он правильно отправляет REST-запрос (это делается локально).

И Камунду тогда будет сильно проще тестировать.

Кажется вам там нужно внутри разобраться со всем и тесты и остальное... Некоторые вопросы являются организационными...

Не исключено ))

Добрый день! Мы умудрились при развёртывании камунды на кластере в формате spring boot контейнера начать ловить ошибку ENGINE-03070 Cannot resolve a unique process definition for key because it exists for multiple tenants при попытке старта процесса. Судя по форуму поддержки, это могло произойти из-за параллельного старта нескольких контейнеров. Нам сейчас проще вайпнуть базу и все перезапустить, но есть ли какой-нибудь способ избежать такой ошибки в будущем?