это где?

В чатике выше, недели 2 назад обсуждали

хм. понятно. спасибо

Ребят, всем привет!

Имею 4-5 бизнес процессов, которые передают управление другу другу. Есть шаги когда надо прикреплять документы, вызовы внешних сервисов ну и много другое. В конечном итоге все складывается в большое число service и user tasks. Модель данных автивно используется практически на каждом шаге.

Думаю над дизайном, который во-первых позволит реализовать имеющиеся бизнес процессы, а во-вторых по мере роста системы позволит дополнять текущие и добавлять новые процессы без «огромного роста сложности». Ну и соответсвенно думаю над оценкой трудозатрат.

На камунде я еще не делал проектов, поэтому в голове пазл решения еще не складывается. Хотел с вами обсудить дизайн bpm решений с использованием камунды. Сложилось пока первое видиние, хотелось бы услышать услышать обоснованную критику и корректировки)

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

2) Модель данных. Т.к. ее как таковой нет в камунде, в отличие например от ibm bpm  и пеги, то возникает вопрос где она должна размещаться и каким образом ею управлять. В итоге пришел к тому, что с точки зрения храния это отдельная база рядом с базой камунды.
Что касается управления моделью, я вижу 2 варианта. Уже долго на эту тему думаю, но окончательно пока не получается разобраться с этим вопросом.

1. Модель может изменяться только камундой, при комплите user tasks и выполнении service tasks. То есть камунда для каждого шага извлекает необходимые данные модели, их изменяет при необходимости, в случае если никаких ошибок нет и все ок, обратно записывает измененные данные.
Из плюсов
- камунда полностью сама контролирует модель данных, делает валидацию и тд. , что добавляет уверенность в том, что никакие левые данные не попадут
- легко откатить изменения в модели, если что то пошло не так на шаге процесса
Из минусов
- в процесс через локальные переменные(или обычные) так или иначе придется просовывать все данные, которые передаются из форм для user tasks. А потом надо будет из процесса эти переменные вычищать.

2. Модель данных может меняться не только камундой при выполнении user и service taks, но и также же перед комплитом тасок и старта процессов.
Из плюсов
- нет необходимости загонять все данные в переменные процесса. Так как, при отправке данных с формы,  сначала будет изменена модель (например это будет фасад над камундой, в котором сначала идет обращение к модели для ее изменения, а потом вызов камунды по java api), а потом будет вызван старт процесса или комплит таски.  И камунда уже будет работать с последними данными.
Из минусов.
- часть ответственности за данные выносится из камунды в фасад. С одной стороны, это может повлечь за собой усложнение этого фасада вплоть до дублирования логики внутри камунды. С другой стороны возникает верояность попадания кривых данных с точки зрения процесса
- не понятно пока как осуществить полный откат изменений. Например модель изменили, далее передали управление камунде для комплита таски, и комплит не проходит по какой либо причине. В такой ситуации, на мой взгляд, надо вернуть модель в исходное состояние.

Интересно узнать что думаете по этому поводу. Возможно есть реализованные примеры,я бы с удовольствием на них глянул

3) Формы и юзер таски. Нужно пилить свой UI, так как на стандартном дальше hello world и туториалов не уехать.  Для работы с тасками скорее всего нужно будет пилить отдельный слой/сервис.
Который будет в случае get
- Для конкретного пользователя запрашивать с камунды активные таски.
- Для каждой таски подбирать его dto для формы. (заранее для каждой формы создается один dto или 2 dto(один для гета, другой для комплита))
- Заполнять dto на основании данных с камунды и с модели.
- Возвращать заполненную dto на фронт
В случае complite
— до конца еще не продумал, так как зависит от того как модель будет использоваться.
Но идея заключается в том, что аналогично, с фронта приходит заполненная dto для таски.
На беке на основании id таски определяется какой класс dto нужен и инициализирует его на основании полученного объекта.
И далее уже идет работа с камундой и моделью…

На мой взглдя подобный подход изначально трудозатратен, но в конечном итоге позволит сделать дружелюбный бекенд для UI.(можно будет вешать свою валидации, добавить свою аутентификацию, управлять тем, что должно отображаться на ui и возможно еще есть бенефиты, о которых еще не знаю ).  
На сколько это размуный подход? И делал ли уже кто-то так? Долго искал примеры, но так и не нашел что бы так где-то делалось.
+ есть у меня еще много вопросов по деталям, но думаю их лучше позже задать)

Ох мать

))

Вот тут мы обсуждали тему решений на камунде

Вообще по-моему все правильно написали

Хорошо себя показал вариант шаренной модели на уровне классов (или одно приложение вообще с 2 датасорсами), когда каждый делегат гетает по айдишнику данные каждый раз перед тем как исполнится

Спасибо, я посмотрел ваш доклад,правда после того как текст свой дописал)
Многих вещей, которые меня интересовали, не было, либо в скользь были рассмотрены)
Жалко доклад короткий был) А так я думаю вы могли очень многое рассказать

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

Надо бы poc накодить

Нету юзертасок в классическом понимании. Есть место, куда падают задачи из процессов. А оттуда они отдельным приложением забираются