Комментарии 37
Я не понял для чего нужна комунда
мы как-то внутри команды собирали встречу, дабы решить, так в каких моментах таки использовать камунду, если кратко, то.
много взаимодействий между микросервисами
много шагов
нет фронта
Это очень краткая выжимка, возможно, напишу статью об этом
Для визуализации процессов (алгоритмов) что бы схематически обрисовать как есть сейчас и как будет в будущем после оптимизации процессов. Удобно как для бизнеса, так и для разработчика, которым видно стартовое событие с исходными данными, так и конечный результат(завершающее событие).
Для визуализации процессов (алгоритмов) что бы схематически обрисовать как есть сейчас и как будет в будущем после оптимизации процессов. Удобно как для бизнеса, так и для разработчика, которым видно стартовое событие с исходными данными, так и конечный результат(завершающее событие).
Спасибо за статью. Camunda редкостная гадость потому что параллельно программной логике вносит дополнительный путь исполнения что затрудняет разработку и отладку. Уйдет в прошлое как gwt.
Спасибо, что было интересно. Не соглашусь, что Camunda редкостная гадость, если честно, я была такого же мнения, но после многочисленных шагов принятия, могу сказать, что в определенных моментах она прямо хорошо ложится на процесс
Камунда хороша в оркестрировании бизнес процессов на микросервисах. Вместо саги и еще десятка паттернов, чтобы приготовить устойчивый и удобный бизнес процесс в микросервисах - можно ограничится централизированным процессом, котороый НИЧЕГО не знает о самих микросервисах, а лишь двигается вперед. Микросервисы знаю малую часть контекста процесса ввиде каких-то взаимодействий. То есть мы остаемся в рамках микросервисов, имеет всякие возможности по типу логирования, откатов процесса, обработки ошибок и тд и те и все в 1 месте. Крайне удобная штука, если у вас сложные бизнес-процессы внутри продуктов, где при прохождении 1 процесса взаимодействуют десятки микросервисов. Ну а так да - с ней очень долго разбираться и это реально боль, а еще визуальный редактор - он сразу вызывает срах и панику) Но по факту очень хорошая вещь в простроении сложных процессов с компенациями и устойчивостью
UPD: на счет дебага - тут тоже плюс за камундой тк все можно трейсить(и ошибки и логи и все все, в микросервисах в целом сложно отлавливать ошибки, с ней чуть попроще)
Temporal рулез, камунда мастдай.
Любой BPM фреймворк нацелен на то, чтобы ввести уровень абстракции для дальнейшего переиспользования больших блоков процесса и эффективного развития процессов. Даже если вы работаете на уровне небольших приложений есть выгода от использования BPM. Например, визарды, заполение форм можно сделать с помощью BPM или workflow.
В случае встроенного BPM отладка такая же как в обычном приложении. Если BPM серверный, то либо удаленная отладка, либо как в любом распределенном приложении. Опять же хороший тон - присать тесты на процесс перед заливкой и проблем будет значительно меньше.
Про тесты, да, это действительно невероятно удобно.
Вы данные храните в единой базе данных или они у вас размазаны по икселькам, json на удаленной стороне и в очереди сообщений? Почему тогда путь выполнения вы разделяете на программный и камундный?
Про переиспользование, а что камунда сама по себе работает, без кода со стороны приложения?
Смотрите, в камунде есть процесс variables, ограничение по ним вроде 4 мегабайта, но могу ошибаться. Так что в этих переменных мы храним uuid и другие технические данные. Поясню, если мне надо достать какую то информацию из базы данных и что то с ней сделать, то я получаю uuid из process variables, и у же по нему достаю нужные мне информацию. То есть вся основная информация хранится в базе данных.
Отладка в камунде это боль, так как контекстом то она не рулит, а рулят микросервисы и действительно это превращается в туже боль отладки микросервисов, особенно если кто то решил намельчить и использовал один паттерн микросервис- одна таблица. А по хорошему то надо, чтобы вся бизнес логика жила в одном sub домене core домена, тогда и проблемы не будет.
Тесты писать безусловно надо, поделитесь как на камунду вы тесты пишите?
Привет, как понимаете боевой код дать не могу, очень постараюсь написать туториал, но пока хотя бы приложу ссылку, по которой мы учились писать тесты
https://github.com/camunda-community-hub/camunda-8-examples/blob/main/twitter-review-java-springboot/src/test/java/org/camunda/community/examples/twitter/TestTwitterProcess.java
Camunda 8-й версии научилась "из коробки" не выпадать в осадок, если вызываемые синхронные сервисы замедлились или таймаутят?
Можно ли версионировать через git это всё?
Ценность Camunda для меня сомнительная, ещё в 2013ом мы послали в урну Activity, мама камунды, ибо все это выглядело не используемо. Тогда мы сделали свой движок, который обладал контектом, а Bmpn движки обладают недоконтекстом, а набором переменных, которые надо как то туда собрать, в итоге более менее серьёзный процесс выпадает в какой-то плохо сопровождаемый проект, где сложно понять почему процесс оказался тут... ( кто поставил значения переменным, на основе которых принималось решение).
Сейчас используем Camunda, для банков это плюс, они типа её знают и поэтому заносят в плюсы.
Что по факту:
Ни какой гибкости камунды нет, любое изменение, потребует знания не только сложной Camunda, но и java, python... Где реализуется ServiceTask. Да, визуально выглядит просто, но на деле, помимо аналитика, это всегда требует разработчика, например в приведеном примере надо до клуба сбегать за пивком..
Это поражает другую проблему - у вас знания, как эта штука работает, разделяется на 2 системы и 2 головы и возникает необходимость синхронизация этого.
Отладка, это боль и страдания, когда ты не можешь вначале понять где проблема, отдебажить все это, а пытаешься понять, как такой контекст переменных образовался.
Ещё +1 система отказа и головной боли, для админов
Какие мысли по этому, лучше все написать на одной системе или на java/... или на Camunda, звучит странно, но большую часть проблем тогда удастся решить.
Но в Camunda нельзя видеть историю и её nocode движок очень слабо развит, т. е технически задачу не решить без code.
На java/... , не будет визуальности диаграммы и типа лёгкости внесения изменений,что "типа" надо архитектору/аналитику банка.
Кто как решает эту проблему?
Кто и как управляет контекстом Camunda? (устанавливаете все переменные непосредственно перед принятием решения? Или где придётся) или может как то по другому?
Идеального решения у меня нет, есть видение, кнопок возможно придётся реальзовать
Camunda никогда не позиционировалась как low/no code платформа, даже наоборот, у них есть статья, где они принципиально дистанцируются от этого термина. Так что без навыков в ИТ в Camunda проекте делать нечего. Другое дело то, что для реализации бизнес-логики на java требуются разработчики уровня архитектора, а они обычно не понимают, зачем нужен BPMN, разбираться в нём не хотят, и пытаются избавиться от как им кажется лишнего движка. С другой стороны, аналитики, владеющие BPMN не могут понять, нафига им джависты в звании архитектора, когда бизнес-логику, в 80% случаев состоящую из трансформации одного формата данных в другой можно реализовать на питоне.
хмм, очень интересное дистанцирование, как архитектор я реально почти не вижу в ней пользы, так как без разработчика нельзя ничего изменить, а разработчику она только мешает. Для разработки бизнес логики, хорошо описанной аналитиком, требуются разработчики уровня верх jun или middle, ни каких сеньеров и тем более архов там не требуется (java, phyton,... тут все равно).
Аналитикам бы не понимающим нафига им разрабы, неплохо бы понять, что те 20% которые они не могут сделать, занимают 80% времени :), поэтому пусть лучше пишут доку... Кубики можно и в другом редакторе рисовать...
Как мне кажется, камунда подходит только для условного роутинга скана по какому-то БП, во всех остальных случая - это лишняя хрень, которая очень дорого обходится в саппорте...
Кубики можно и в паинте рисовать :) Но в том то и дело, что BPMN это не только про кубики. По нему есть официальный экзамен, в котором есть вопросы связанные с ИТ и бизнес сферой. По самой нотации там вопросов может 30% только. Вы верно заметили, что в BPM проекте редко нужны разработчики выше мидла, и когда появляется не тривиальная задача срабатывает правило Паретто. Вот только тут появляется вопрос специализации. Разработчики в BPM проектах должны ориентироваться на системную итнеграцию, а когда появляется что-то не тривиальное- нужно привлекать специалистов соответствующего профиля. Те, кто продвигают low code инструменты заведомо лгут, что можно обойтись без дорогостоющих разработчиков. Для какой-нибудь демки и презентации может сгодиться, а потом наступает момент жёсткой истины, и заказчик сталкивается с необходимостью подлючать людей, на которых он не рассчитывал. Подстройка под архитектуру BPMS или внесение изменений в неё может быть намного сложнее, чем написание нового функционала. Наступает разочарование. Как пример- почти в каждой BPMS есть встроенный дизайнер пользовательских форм. Раньше в Камунде его не было, но недавно добавили. На презентациях продавцы шустро создают на них работающие примеры, а когда начинается реальная работа, всплывает, что в дизайнере нет выподающего списка, или форму нельзя динамически менять. И тут в проекте появляется веб разработчик, на которого никто не рассчитывал, или (что чаще бывает) системных интеграторов пытаются перевести на веб разработку, что ни к чему хорошему не приводит.
Все верно, NoCode платформу можно сделать только для очень простых задач, шаг вправо или влево = расстрел. Вот с low code платформами можно гораздо больше, если обычному разработчику убрать с помощью нее рутину, тогда открываются интересные возможности...
Обычно все эти платформы сыпятся на элементарной задаче, а покажите мне в этой формочки данные из этого rest....
В общем для себя я отметил, что Camundа используем в исключительных случаях, если можно не использовать, не используем.
8я версия это плод жадности владельцев проекта. Способ уйти от OpenSource и перевода в клауд. Camunda, как форк от jBPM унаследовала его способ описания бизнес-логики через Java, однако в Камунде появился функциоал воркеров, который позволяет автоматизировать задачи хоть на питоне. Но в проектах с какой-то маниакальной упроностью продолжают использовать джаву. Опытные джависты реально не понимают, зачем нужен ещё один слой, не хотят в этом разбираться, или попросту саботируют работу. А новичкам в этом разобраться сложно. Это погубило уже ни один проект. А потом мы видим комментарии из серии "камунда маст дай". Прекратите использовать джаву в BPM проектах, и увидите как мир станет светлее.
Зачем backend-разработчику Camunda и как ей пользоваться? Разбираем на примере одного пятничного вечера