у вас синхронные процессы?

Наверно можно, но такой вариант (другой сервис ждет завершения всего процесса, а не отдельной активности) кажется мне проблемным. Процесс может отрабатывать долго. Почему выбрано такое решение? Почему сторонний сервис не может запустить процесс, а потом, в конце процесса, Камунда оповестит сервис, что процесс закончился?

Ну plugin слушает historydata process instance end event, и в redis делает publish message, gate делает subscribe redis и получает инфу об ответе. Все асинхронно

Просто гляньнюте код, там 50 строк прагин

ну, для сервиса это выглядит как одна синхронная операция. Сервисов много и они stateless (это BFF)

Да для внешней системы это выглядит как обычный rest запрос

об этом речь? https://github.com/MaximMonin/camunda-plugins/blob/master/java/camunda-process-end-plugin/src/main/java/camunda/plugin/processend/ProcessEndEventHandler.java

Какие причины использовать для этого Камунду? Почему нельзя сделать просто endpoint  в Spring Boot (без Камунды)?

Да

камунда в данном случае выглядит как оркестратор саг

иначе надо будет самому писать эту логику по запуску и откату/компенсации

ну и камунда вроде как гарантирует, что ничего не потеряется (каждый шаг записывается в БД)

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

Или переделать сервис, чтобы он не ждал Камунду.

подскажите, а вот если я использую камунду и загружаю некоторый json. У меня есть сервис, который этот json валидирует и сохраняет, либо выдает информацию об ошибках в json-е. И сразу же после сохранения json-а должно запуститься следующее действие. Как это правильно организрвать?
Я должен прокидывать json в камунду, она его в мой сервис, после того как он ответит, она будет запускать следуюший сервис, правильно?

Ну у меня похожая задача, я рассматривал сначала zeebe но он сыроват, и немного медленне камунды по тестам работает пока. Там том же железе, поэтому сделал через камунду

Ну можете прокидывать json, а если оно большое, то можно использовать redis с timeout, а в переменной хранить ссылку на редис, а не сами данные. Но если вам нужно видеть именно сами данные в истории то храните из прямо в переменной.

> Как это правильно организрвать?

Я бы сделал так: Валидацию JSON-а вообще убрать из Камунды.

1. Вы делаете endpoint, который получает JSON.

2. Код, прикрученный к этому endpoint-у проверяет валидность JSON.

Если проверка прошла успешно, то

2.1. запускает процесс в Камунде (но не ждет его завершения),
2.2. получает от Камунды идентификатор запущенного процесса и
2.3. отправляет в ответе код 200 и идентификатор из шага 2.2.

Если JSON не валидный, то возвращает ошибку (код 500, например).

3. В Камунду попадает только валидный JSON.

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

> сервис, который должен принимать json теперь должен знать и о существовании камунды

Сервис должен знать только адрес REST-движка Камунды, по которому он будет отправлять валидные JSON-ы.