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

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

1. Приход события по модели, если ты прошел шаг 1 и перешёл в этапу два, событие 1 всегда пролетает мимо ибо уже не ждёт процесс его. 2. Вернуться на шаг назад было нормально не возможно. В итоге процесс, который был последовательным вначале, чтобы заработать превратился в event dispatcher. То есть стояла одна точка, event message, которая вызывала все из себя. Только так оно работало вперёд назад. Во вторых, когда процедура отрабатывала и не возвращалась в евент точку, любое событие с веб интерфейса игнорировалось, хотя в зиби можно было установить ttl и проблема решалась , событие не пропадало

Но вывод из этого, модель все равно выраждалсь в обычный routing веб бакенд. Работало конечно медленнее чем обычный бекенд из-за накладных расходов камунды или зиби. Вообщем где-то так.

Мы в ближайшее время планируем реализовать схему "управления" фронтом из процесса на основании двух переменных. Первая шаг процесса и вторая массив возможных выходов, он же массив id сообщений, которые можно послать в текущий шаг процесса, что бы двинуть его дальше. Переменные устанавливаем и сбрасываем в листнерах. После запуска процесса фронт через подписку получает текущее состояние процесса. К шагам привязана отрисовка экранов. К управляющим элементам передача сообщения в процесс. У фронта нет знания о переходах между страницами. Он всегда опирается на текущее состояние процесса. По этой же схеме легко делается подхват процесса. Нашлинужный экземпляр, зачитали состояние и отобразили нужный экран.

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

Главное вовремя уволится

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

Мы пару месяцев сношались с разными вариантами, в итоге ничего лучше как оторвать одно от другого не придумали (:

Есть где посмотреть архитектуру со стейтмашиной и камундой?

Все сразу, и то и другое)? 😭

Вариант 1

1. На сервере есть endpoint, который принимает от клиента информацию о состоянии (например, текущая страница визарда).

Этот endpoint возвращает клиенту, например, перечень страниц визарда, куда можно пойти с текущей страницы (с учетом текущих данных).

2. Сервер определяет это на основании информации о разрешенных переходах, которая может выглядеть так:

val AllowedTransitions = mapOf<Bp1AddCmdState, List<Bp1AddCmdState>>(
                NEW to listOf(WAITING_FOR_COMPANY_URL),
                WAITING_FOR_COMPANY_URL to listOf(WAITING_FOR_CONTACT_DATA_TYPE, CANCELING),
                WAITING_FOR_CONTACT_DATA_TYPE to listOf(WAITING_FOR_EMAIL, WAITING_FOR_CONTACT_FORM_URL, CANCELING),
                WAITING_FOR_EMAIL to listOf(WAITING_FOR_NOTE, CANCELING),
                WAITING_FOR_CONTACT_FORM_URL to listOf(WAITING_FOR_NOTE, CANCELING),
                WAITING_FOR_NOTE to listOf(SAVING_DATA_IN_CAPSULE, CANCELING),
                SAVING_DATA_IN_CAPSULE to listOf(END),
                CANCELING to listOf(END),
                END to listOf()
                )

Из состояния NEW можно перейти в состояние WAITING_FOR_COMPANY_URL.

Источник: https://github.com/mentiflectax/altruix-is/blob/master/src/main/kotlin/cc/altruix/is1/telegram/cmd/bp1add/Bp1AddCmdAutomaton.kt

Это старый код телеграм-бота, в котором было реализовано некое подобие визарда.

Вариант 2

1. Таблица переходов хранится на клиенте. У нее есть версия.

2. Время от времени клиент обращается к серверу и передает текующую версию таблицы переходов на клиенте.

3. Если на сервере версия таблицы переходов больше (новее), чем на клиента, то клиент скачивает новую версию.

Примечание: Это может работать только, если изменяться может последовательность переходов, но не сами страницы (содержимое отдельных частей визарда).

Соответствие `AllowedTransitions` можно легко преобразовать в файл для dot и сделать диаграмму переходов для менеджеров.

Таблицу переходов можно также отобразить как направленный граф. Например с помощью JGraphT.

https://jgrapht.org

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

Какие тогда ещё могут быть камни преткновения, если нет движения назад?

Сдаюсь)

Хочу разобраться с этими вопросом, т.к. ещё не работал в подобных архитектурных решениях)

holy war :) Camunda vs wizards :P

А чо ваши мобильщики говорят?

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

> Какие тогда ещё могут быть камни преткновения, если нет движения назад?

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

Если задачу можно решить с помощью таблицы переходов (или графа) и 1-2 endpoint-ов, то зачем городить хозяйство из

1. Камунды (включая все возможности выстрелить себе в ногу -- см. настройки job executor-а),
2. базы данных для нее,
3. конвейера CI/CD специально под Камунду,
4. моделера (в котором, кстати, есть тонкости и возможность совершить ошибки, которых нет в простой таблице переходов)?

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

В Камунда есть DMN таблицы, в которых можно сохранять правила переходов