Комментарии 13
Может быть есть вариант повторить на Camunda Hello Calculator
Желательно как и в примере: ничего не устанавливая и без использования временного trial (закончен).
Один знакомый говорил, что он может на экселе написать операционную систему, но зачем? Конечно, можно запилить калькулятор на любом BPM-движке, но едва ли в этом есть смысл.
А что конкретно вам не понравилось в статье, за что минус-то?
Конечно, можно запилить калькулятор на любом BPM-движке, но едва ли в этом есть смысл.
Приведенный мной пример - это аналог Hello world для WFE-систем (Camunda и прочее).
Hello Calculator for WFE не только числа складывает, он и ролевой состав показывает (реализации), а также его примирение (см. п.12 Монитор экземпляров).
Набор подобных примеров - hello Calculator позволил бы наглядно и в сравнении продемонстрировать простоту и быстроту создания приложений на каждой WFE.
А что конкретно вам не понравилось в статье, за что минус-то?
Я уже и не помню, когда вообще последний раз ставил минус. О чем Вы? А вообще как узнать, кто минусует?
Представьте типичную ситуацию, когда из нескольких процессов вызывается один и тот же подпроцесс. Как вы поймете, к какому родительскому процессу относится данный экземпляр подпроцесса? Смотреть по parent_id не очень удобно, проще использовать бизнес-ключ.
Если я правильно понял, бизнес-ключ определяет у нас объект, вокруг которого вертятся процессы? Договор, заказ, накладная и тд?
В таком случае, не появится ли неопределенность при попытке идентифицировать по бизнес-ключу процесс-родитель для подпроцесса, если по одному объекту будут запущены 2 процесса, каждый из которых вызовет одинаковый подпроцесс?
Например, проект договора одновременно на согласовании и на ознакомлении, вызываем из каждого подпроцесс внесения изменений в договор. Теперь, если наши подпроцессы будут искать папку и мамку, то найдут 2 процесса с разными parent_id и одинаковым бизнес-ключом. Разве не так?
Да, вы правы. Если запущено два процесса и они вызывают один подпроцесс, то возникнет неоднозначность, придется делать более сложный запрос, одним бизнес-ключом не обойтись. Но это скорее гипотетическая ситуация. Едва ли в процессе ознакомления вносят изменения. Но не суть важно.
Идея в том, что лучше иметь бизнес-ключ, чем не иметь.
распределенные транзакции не работают.
Громкое заявление. У нас распределенные транзакции работают замечательно в связке с камундой. Правда потребовалось свой транзакционный менеджер написать.
Про распределенные транзакции не мои слова, это говорит Бернд Рюккер, сооснователь и главный технолог Camunda. Можно с ним поспорить, конечно. Но для начала лучше глянуть его статью Достижение согласованности без менеджеров транзакций.
Возможно, для вашей задачи это эффективное решение - использовать свой менеджер транзакций. Но это выглядит сложно. Почему бы просто не использовать компенсации в BPMN? Можно получить тот же результат, но штатными средствами.
Но для начала лучше глянуть его статью Достижение согласованности без менеджеров транзакций.
Где ничего не сказано о том почему распределенные транзакции между двумя+ бд не работают. Есть ссылка на статью, в которой так же ничего особо не раскрывается. Написано только в том же ключе - "не работают!" и дальше идет разбор подходов, которые помогают как-то жить без транзакций.
Но это выглядит сложно.
Реализовать такое для платформы было не просто — это факт. Но прелесть в том, что это позволило использовать camunda в микросервисной архитектуре где бизнес‑данные управляются в одном микросервисе, а движок работает в контексте другого микросервиса. При этом разработчикам не нужно на каждом шаге думать об обработке целого вороха сценариев когда что‑то может пойти не по плану. И самое прекрасное — распределенные транзакции никоим образом не мешают использовать все те «безтранзакционные» подходы вроде саг, там где это уместно.
Насколько я понимаю, вот эта сложность работы с транзакциями, когда кругом микросервисы, была одной из побудительных причин, почему появилась Camunda 8 с новым движком Zeebe, где вообще нет реляционной СУБД. То есть, проблема распределенных транзакций реально существует и нельзя проектировать процесс, не принимая это во внимание.
Можно ли резюмировать нашу мини-дискуссию следующим образом? ---
Не стоит полагаться на штатные механизмы обработки распределенных транзакций в вашем процессном приложении, потому что это несет риски несогласованности данных. Но, если есть на то ресурсы и квалификация, эту проблему можно решить кастомной разработкой собственного менеджера транзакций.
Согласны?
Camunda на проде: восемь типичных ошибок