Comments 32
Изучение готовых платформ требует времени, плюс есть проблемы с кастомизацией. А еще мы подумали, что дальнейшая разработка пойдет гораздо эффективнее, если решение будет создано с нуля – так мы сможем понимать, какие у него «внутренности».
Классика. Написать свой движок, стабилизировать его в проде, пофиксить проблемы не учтенные при проектировании проще чем изучить готовый продукт.
В этот момент так же часто говорят - нам нужен только движок, безо всяких доп утилит и прочего. Проходит время и они потребуется так же.
Если нужно в рамках сценария добавить некоторую задачу – мы просто делаем insert в таблицу Scenario_Task.
То есть ни Camunda Modeler, ни Activiti Modeler, ни какие-то еще редакторы BPMN, плагины к IDEA, ни сам формат BPMN вы не поддерживаете?
Стоило ли оно того, что бы потом для заведения задачи надо было SQL запрос выполнять?
Начнём с аксиоматики. BPM - это управление бизнес-процессами, а BPMN - конкретная нотация отображения бизнес-процесса. Мы не ставили целью поддерживать нотацию BPMN. Мы хотели создать возможность менять бизнес процесс в рантайме, без привлечения разработчиков и без перезагрузки стенда. В рамках нашей постановки задачи запросы в SQL выглядят рабочим решением. Плюс поджимали сроки на реализацию. Мы понимаем, что в дальнейшем скорее всего потребуются и другие способы конфигурирования бизнес-процессов. Плюс есть вероятность, что потребуется и наглядная визуализация. На данный момент детально эти вопросы не рассматривались.
Подскажите, пожалуйста, предполагается ли в будущем какая-то визуальная часть - фронт? Основным достоинством Camunda, Zeebe является возможность нарисовать процесс, согласовать его с бизнесом, а потом в сockpit увидеть визуально, где находится процесс, где ошибки, просматривать контекст и многое другое. Если основная задача была в декомпозиции, не смотрели ли на существующие аналоги - Spring Integration, Apache Camel ?
Первая постановка задачи заключалась в создании механизма изменения бизнес-процессов без привлечения разработчиков и без перезагрузки стенда. В рамках данной постановки задачи визуальная часть не рассматривалась. Более того были весьма сжатые сроки на реализацию. Со временем есть вероятность, что фронт потребуется, как раз в части согласования бизнес процессов с бизнесом. Мы будем отталкиваться от требований бизнеса, но не обязательно, что будем стремиться к поддержанию именно BPMN нотации отображения бизнес-процессов.
Мы не ставили задачу реализовать BPMN движок. Это разные понятия. BPM - это управление бизнес-процессами, BPMN - конкретная нотация отображения бизнес-процессов, как и многие другие, типо IDEF, Aris, UML и т.д. Наша первоначальная цель была предоставить возможность менять бизнес-процессы в рантайме без привлечения разработчиков и без перезагрузки стенда. Соответственно, в рамках этой задачи использовать такой тяжелый фреймворк как Camunda Platform является весьма избыточным решением. И о какой-либо совместимости с Camunda или Activity речи не шло. В данный момент движок конфигурируется через реляционную базу данных. Мы даём себе отчёт в том, что возможно в будущем потребуются и другие способы хранения конфигурации, начиная от NoSQL баз данных или каких-либо иных вариантах. Кроме того, мы задумывались и о визуализации процессов, но пока в приоритетном порядке рассматривали скорее семейство UML диаграмм. Решение было создано за весьма ограниченный промежуток времени. Поэтому мы выбирали наиболее простой путь.
Подскажите, плиз, неопытному, как в подобных системах происходит связь с реальностью? Вот нарисовали какие-то стрелочки, а дальше что? Какой-то сервер начинает слушать и отправлять https-запросы или какая-то интеграция с каким-то оборудованием или как это вообще происходит?
Фактически да. "Какой-то сервер" должен контролировать созданный бизнес-процесс, согласно нарисованной вами схеме. В сторону фронтендов он выставит новый метод, означающий запуск нового бизнес-процесса. Через него он получит запрос на запуск процесса с определенным контекстом, далее может обогатить контекст дополнительной информацией из внешних систем по необходимости и выполнить этот процесс, в том числе и во внешних системах. Для обращений во внешние системы используется слой адаптеров, поддерживающий протоколы этих систем (зачастую тот, который предоставляет шина ESB) и оркестратор этого слоя, обеспечивающий абстракцию технических сценариев взаимодействия с внешними системами (роллбеки, повторы и тп) от бизнес-сценариев. (к примеру, bpmn для описания бизнес-уровня и bpel для оркестрации адаптеров+расширения типа bpel4people для "оркестрации" людей).
Внешние системы очень часто могут в свою очередь иметь в своем составе подобные workflow оркестраторы для внутренних своих нужд, поэтому концептуально важно наличие самого "главного какого-то сервера", который будет начинать и заканчивать процесс, тем самым обеспечивая его полную измеримость от начала до конца.
Camunda, как и другие bpmn движки для оркестрации очень медленная, из-за постоянного сохранения контекста в бд (как результат, еще и table bloat в подарок), в кишках у нее настоящий адъ, а бэклог с ошибками вообще не закрывается. Ее надо уметь готовить чтобы выжать хоть какой-то перформанс (в документации вообще ничего про это нет), не говоря о том, что она вообще никак не масштабируется из коробки (zeebe тоже шляпа). Camel и правда выглядит как то что надо в контексте оркестратора с динамическим добавлением процессов, но расширять и подтачивать его под свои задачи дело тоже не из простых. Так что дело полезное, удачи, ребята
А что за ад в кишках у camunda?
Вы пробовали сами закрывать ее проблемы или допиливать какой-нибудь свой функционал поверх? Попробуйте, например, смигрировать миллион процессов между двумя версиями. Или добавить например brave-контекст для трассировки сквозь процессы.
Самописный движок для внутренних нужд будет лучше, по вашему?
Пробовал, ада не встречал.
Именно так и должен говорить идеальный миссионер.) Вы наверное пробовали это руками сделать для отдельных процессов, а не допиливать коробку чтобы это работало всегда. Вы бы лучше ответили на предметную критику платформы и рассказали о том как с этим жить, если у вас большие нагрузки и надо работать с 10М инстансами долгоживущих процессов (которые не упрощаются, у которых верно настроены границы континуаций, максимально оптимально сохраняется контекст переменных и корреляции только по проиндексированным полям) с 5К созданных процессов в секунду)
А где прочитать предметную критику? Я ж ее и пытась из вас вытащить. Голдманс сакс гоняет 10 миллирадов инстансов в день, и у них все хорошо.
У нас в организации такое есть, универсальный совет такой:
Не делать одну здоровенную камунду, а делать н-камунд. То, что хочется переиспользовать - выносить в либы.
Отказаться от визуального программирования, если оно есть. Перейти на моделирование бизнес-процессов, а не флоу.
Не использовать контекст, использовать только бизнес-ки, который является сссылкой на обрабатываемую сущность в соседней системе. В прочем пару айдишников можно добавить, как раз для корреляций.
Не использовать встроенные корреляции по переменным, максимум по бизнес-ки. В иделае написать свою обвязку для корреляций, мы так сделали в итоге.
Затюнить Job Executor
Перейти на External Task в жирных или долгих подключениях.
Миграции в общем виде автоматизировать нельзя, потому что в общем виде невозможно предугадать изменения бизнес-процессов.
Вот то что точно можно сказать, что эти советы очень сложно найти в доке и они контринтуитивны, особенно с контекстом.
Поэтому если у вас всегда FSM и не пахнет сетями Петри, то Camunda не нужна - у нее спект применения сильно уже, чем кажется на первый взгляд
Вы ловко уклонились от ответа. 10B инстансов в день - это вообще не тот параметр о котором я говорю. Речь идет именно об инстансах одного конкретного процесса. Естественно экзекьютор затюнен и корреляции идут по ключам. Экстернал таск - это так себе совет в контексте рпс, уж лучше асинхронный rest call в другой сервис. Камунда как оркестратор не справляется с корреляцией на тех числах, что я привел даже на самых жирных бд.
Э, так вы написали с 10м инстансами процессов, я подумал что про разные дифинишины. Но тут я уже хз, смотреть надо, я видел что такое нормально работает. Камунда это вообще не про рпс (если не брать с инмемори), а про инстансы в день. Мало организаций, где 10 миллионов заказов в час.
А перепутать легко, если начать логи в двх из кафки лить через камунду, то на второй день станет грустно .
На Jpoint в этом году, рассказывал как раз как не перепутать
Вот про спектр применения согласен, и кажется именно с этого надо начинать. Она работает далеко не всегда так как задумывалось по дизайну и позволяет на ранних этапах разработки слишком много того, из-за чего потом люди жалеют. Многие фичи настолько неоптимальны, что их лучше не трогать.
Расскажите, что не так с контекстом?
И что не так с визуальным программированием?
Даже если там ад в кишках, то кто гарантирует что разработка с нуля не создаст такого же ада только другого.
Импортозамещение Camunda самописным BPM-механизмом
Зачем импортозамещать опенсорс?
Не понятно зачем писали то? Если критерий "BPM-движок, который позволяет кастомизировать бизнес-процессы без перезагрузки стенда и перезапуска приложения ",то это позволяют и самые древние BPM движки, а уж Camunda и подавно.
Camunda является избыточным решением в рамках нашей постановки задачи. Со старыми движками есть проблема в поддерживаемости, в завязке на старые технологии, в сложности допилить коробочное решение в части каких-то узкоспециализированных вопросов. Своё решение гораздо проще поддерживать и кастомизировать, используя самый современный стек.
У вас java 8
Если вам не нравится решение, которому несколько лет, то есть легковесный Zeebe (он же "Camunda platform 8"). Стильный, модный, молодежный, cloud native и т.д.
Вопросик: может я не внимательно прочитал, но все же спрошу.
Существуют ли в вашем движке стандартные конекторы типа http,tcp, file и т. д. ? Откуда берутся данные ?
Поддерживаются ли какие-либо типы авторизаций ?
Импортозамещение Camunda самописным BPM-механизмом