Здравствуйте!

А какая задача стоит? Для чего именно нужны повторные запросы?

Что бы, если моргнула сеть. И camunda повторна пошла делать запрос на изменение состояния сервиса (rest api) то сервис смог понять, что он уже это делал и ответить нормально, а не ошибкой допустим. В качестве такого ключа используется activity instance ID

Даже нажать на кнопку "Далее" в форме быстро несколько раз, вылезает ошибка

Лучше уж на processInstanceId заложиться

Активити иснанс новый на каждое выполнение элемента схемы

Действительно лучше использовать process instance ID.

А если по-хорошему, то я бы сделал этот сервис идемпотентным, чтобы можно было использовать стандартный механизм повторных попыток Камунды ( https://docs.camunda.org/manual/7.15/user-guide/process-engine/the-job-executor/#retry-time-cycle-configuration ).

У нас не чистая задача визарда. Есть бизнес-процесс оформления продукта это основное. При этом процесс может начаться в одной системе, а доталкивать его будет другая. Обработкой процесса могут заниматься разные бизнес-роли. В него подмешиваются функции визарда (2 переменные процесса). И фронт становится не зависимым от процесса. Его остаётся научить реагировать на состояние процесса и всего. При этом процесс остаётся в своих рамках. В тех двух переменных указываются шаги процесса и id сообщений, а не названия страниц, скажем.

Если бы через API камунды можно было бы начитать возможные граничные события, то и эти переменные бы не понадобились. Просто начитываем состояние и учим фронт реагировать. Но это к сожалению сделать через API нельзя.

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

Возможно, я чего-то не понимаю, но я не вижу, зачем здесь Камунда.

Есть банковский продукт, который нужно оформить. Процесс оформления растянут по времени и в нем участвуют несколько бизнес-ролей сотрудников. Это не вотчина камунды?!

Допустим, этот продукт -- кредит.

В обработке заявки участвуют разные бизнес-роли.

В BPMN-процессе не должно быть ничего, связанного с тонкостями отображения во фронтенде.

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

А фронтенд уже сам будет решать, какие страницы и как показывать на основании данных из этой отдельной базы.

Такой подход может работать.

А вот делать что-то на фронтенде в зависимости от переменных процесса Камунды -- сомнительно.

Альтернатива: Фронтенд может через REST engine Камунды запрашивать у Камунды те или иные данные по экземпляру процесса.

Ну я так и писал. Просто в одну переменную кладу код шага процесса, в другую массив возможных id сообщений, которыми можно протолкнуть процесс далее. Это всё артефакты процесса. Если бы это можно было начитать всё через API камунды, то конечно было бы проще. Код текущего шага вроде как можно, но я решил запихнуть в переменную, не будет проблем с переименованием в схеме. А вот возможные сообщения, которые ожидает процесс в данной точке начитать нельзя через API. Особенно если подключены граничные события message boundary.

И получается фронт сам решает что отобразить в зависимости от текущего состояния процесса

При этом получается универсальный механизм. Я могу создать в куче мест процесса граничный message с одним и тем же названием ProductSelect, скажем. А на фронте отображать кнопку возврат к выбору продукта, если в текущем состоянии в массиве вернулся ProductSelect. Не вернулся значит не отображаем кнопку. По нажати кнопки в процесс отправляется сообщение ProductSelect и процесс переходит к соответствующему шагу. Далее фронт начитывает в очередной раз состояние процесса и видит, что оно уже другое и рисует экран с выбором продукта. При этом на фронте нет карты переходов, есть простая зависимость отобрази экран, если текущий шаг процесса такой-то.

Выше, когда я пишу процесс, подразумеваю экземпляр процесса конечно же.

Описанное Вами решение по моему ощущению чревато проблемами. Я бы так не делал. Камунда не рассчитана на то, что Вы хотите сделать. BPMN не рассчитан на описание вещей, связанных с пользовательским интерфейсом.

По моему опыту, BPMN-диаграммы имеют тенденцию разрастаться даже если в них нет деталей пользовательского интерфейса (как в Вашем случае).

Кажется, что Ваше решение усилит связность между серверной частью (Камундой) и фронтендом (фронтенд должен знать о том, как работает процесс в Камунде). Это не очень хорошо.

Что, если через несколько лет надо будет сделать клиент, который работает по принципиально другой логике, нежели нынешнее мобильное приложение? Означает ли это, что в BPMN-диаграмму надо будет добавить элементов для 2 клиентов?

Выбор, конечно, Ваш, но я бы серьезно посмотрел альтернативные решения (см. выше в этом чате).

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