Но PlantUML это просто рисовалка. Окей, для документирования сгодится. Однако мы же говорим об автоматизации процессов. Тогда нужен исполняемый BPMN, который загружается в движок. Вот у нас в Jmix так и есть -- BPMN моделер прямо в IDE, вместе с кодом. По мне, так удобно -- плюхнул сервис-таску -- сразу написал бин или делегат, из графической модели по одному клику переход в код.
И не согласен, что текст это прям панацея. Вот, например, модель данных где хотя бы сотня сущностей. Наверное, ER-диаграмма будет удобнее для понимания, чем текст.
Та же история с процессами: они делают наглядной логику выполнения для сложных систем. Просто надо разок напрячься и вникнуть в нотацию, потом становится просто. И я бы не сказал, что в BPMN все интуитивно понятно. Для примитивных случаев - да. Как посложнее, то надо учить матчасть.
Дело в том, что вопрос вообще не нужен движку. Об этом была речь. Вопросы только наводят тень на плетень. Что с ними делать разработчику? -- Самому домысливать, что имел в виду аналитик.
Я пытался вам рассказать, как это на самом деле работает, а не как предписывает хороший стиль нотации. Да, такое может получиться хотя бы по ошибке. Чтобы разработчик понимал, где эту ошибку ловить. И что буквы на схеме вообще ничего не значат.
Непонятно, почему такое противопоставление BPM и лоукода. Давайте посмотрим на магические квадраты Гартнер по BPM и найдем там хоть одну не лоукод систему. Едва ли это получится. Потому что сейчас лоукод и BPM это практически синонимы. Все известные вендоры BPM давно называют себя лоукод-платформами. Pega, Appian, OutSystems, далее везде. А сегодня, следуя моде, все стали AI-платформами. Стоит ли обращать такое внимание на маркетинговые ярлыки?
Да, это известный факт, что есть два уровня BPMN-моделей, аналитические и исполняемые. Естественно, аналитическую модель нельзя запихнуть в движок. Но бизнес-логику все равно надо как-то делать. Это справедливо для всех платформ.
Смысл использования графической нотации, BPMN или другой в том, чтобы сделать процесс видимым. Observability это очень полезно.
Моделирование в BPMN это избыточный этап. Да и ТЗ писать только время тратить. То есть, вы предлагаете отказаться от моделей процессов вообще и реализовывать их сразу в коде, да? Для простых процессов в 3-5 шагов пожалуй да. Ну пропуск заказать. отпуск согласовать.
Но когда этих шагов несколько сотен (а такое бывает), то пожалуй трудновато будет держать в голове всю логику, если это просто в коде.
Я в математике не силен, за граф не скажу. Вот чатик утверждает, что DMN можно рассматривать как ориентированный ациклический граф (DAG), поскольку решения строятся на основе входных данных и других решений, не образуя циклов. Может врет, кто его знает. Но зачем бы мне визуализация? В том-то и смысл, чтоб иметь компактное представление И как на графе смоделировать множественные выходы, когда hit policy = Collect?
За книжку спасибо, гляну. Но у меня такое ощущение, что мы говорим немного о разных вещах. В контексте управления бизнес-процессами таблицы решений это то, что определено в стандарте DMN. Это совершенно конкретный механизм, реализованный в Camunda и Flowable.
Просто это статья немного верхнеуровневая, в ней опущены технические детали. Например, такая штука как Hit policy, которая определяет, как именно движок обрабатывает бизнес-правила из таблицы и что будет на выходе.
Да, вы правы, оба эти подхода применимы и нельзя сказать, что надо одно выбросить, а другое оставить. Но! Логика if-else известна каждому школьнику, а про таблицы решений надо рассказывать.
И это еще пол-дела. Если от теоретических построений перейти к конкретной реализации в системах BPM, то разница будет гораздо более заметной. Логику if-else в нотации BPMN реализуют посредством эксклюзивных шлюзов и при большом числе параметров диаграмма становится просто нечитаемой. Вот, например:
Тут всего-то пара вопросов про возраст аккаунта и траты, а уже какая-то каша.
Но есть способ лучше! Упаковываем это все в набор бизнес-правил и наша модель начинает выглядеть вот так:
И да, манипулировать правилами гораздо удобнее, чем деревом. То есть в плане поддерживаемости этот вариант лучше.
Ок, про минус видно куда-то не туда глянул и огорчился. Извиняюсь. Дотошно сравнивать системы это хлеб аналитиков, я точно не возьмусь делать калькулятор на Камунде.
Насколько я понимаю, вот эта сложность работы с транзакциями, когда кругом микросервисы, была одной из побудительных причин, почему появилась Camunda 8 с новым движком Zeebe, где вообще нет реляционной СУБД. То есть, проблема распределенных транзакций реально существует и нельзя проектировать процесс, не принимая это во внимание.
Можно ли резюмировать нашу мини-дискуссию следующим образом? ---
Не стоит полагаться на штатные механизмы обработки распределенных транзакций в вашем процессном приложении, потому что это несет риски несогласованности данных. Но, если есть на то ресурсы и квалификация, эту проблему можно решить кастомной разработкой собственного менеджера транзакций.
Про распределенные транзакции не мои слова, это говорит Бернд Рюккер, сооснователь и главный технолог Camunda. Можно с ним поспорить, конечно. Но для начала лучше глянуть его статью Достижение согласованности без менеджеров транзакций.
Возможно, для вашей задачи это эффективное решение - использовать свой менеджер транзакций. Но это выглядит сложно. Почему бы просто не использовать компенсации в BPMN? Можно получить тот же результат, но штатными средствами.
Один знакомый говорил, что он может на экселе написать операционную систему, но зачем? Конечно, можно запилить калькулятор на любом BPM-движке, но едва ли в этом есть смысл.
А что конкретно вам не понравилось в статье, за что минус-то?
Да, вы правы. Если запущено два процесса и они вызывают один подпроцесс, то возникнет неоднозначность, придется делать более сложный запрос, одним бизнес-ключом не обойтись. Но это скорее гипотетическая ситуация. Едва ли в процессе ознакомления вносят изменения. Но не суть важно.
Идея в том, что лучше иметь бизнес-ключ, чем не иметь.
Увы, "восьмерка" только платная. Это мы никак обойти не можем. А чтобы не было совсем грустно, мы решили сделать форк "семерки" и поддерживать ее дальше. Скоро выйдет наш OpenBPM Engine, но он тоже будет стоить каких-то денег. Что касается "восьмерки", то все наши комопненты будут с ней интегрированы.
Да, это известно про восьмерку. Мы тоже работаем над альтернативными вариантами. Но это же не отменяет того, что надо поглядывать на лидера, понимать куда движется.
Но PlantUML это просто рисовалка. Окей, для документирования сгодится. Однако мы же говорим об автоматизации процессов. Тогда нужен исполняемый BPMN, который загружается в движок. Вот у нас в Jmix так и есть -- BPMN моделер прямо в IDE, вместе с кодом. По мне, так удобно -- плюхнул сервис-таску -- сразу написал бин или делегат, из графической модели по одному клику переход в код.
И не согласен, что текст это прям панацея. Вот, например, модель данных где хотя бы сотня сущностей. Наверное, ER-диаграмма будет удобнее для понимания, чем текст.
Та же история с процессами: они делают наглядной логику выполнения для сложных систем. Просто надо разок напрячься и вникнуть в нотацию, потом становится просто.
И я бы не сказал, что в BPMN все интуитивно понятно. Для примитивных случаев - да. Как посложнее, то надо учить матчасть.
Спасибо, конечно! Но это же просто перевод
пока у него это получается фигово.
это какие-то космические корабли бороздят
не понял вопрос.
в смысле чтоб ИИ сгенерил процесс?
по мне это пока бла-бла, так не работает
но с статье же о другом
Дело в том, что вопрос вообще не нужен движку. Об этом была речь. Вопросы только наводят тень на плетень. Что с ними делать разработчику? -- Самому домысливать, что имел в виду аналитик.
Я пытался вам рассказать, как это на самом деле работает, а не как предписывает хороший стиль нотации. Да, такое может получиться хотя бы по ошибке. Чтобы разработчик понимал, где эту ошибку ловить. И что буквы на схеме вообще ничего не значат.
Непонятно, почему такое противопоставление BPM и лоукода.
Давайте посмотрим на магические квадраты Гартнер по BPM и найдем там хоть одну не лоукод систему. Едва ли это получится. Потому что сейчас лоукод и BPM это практически синонимы. Все известные вендоры BPM давно называют себя лоукод-платформами. Pega, Appian, OutSystems, далее везде. А сегодня, следуя моде, все стали AI-платформами.
Стоит ли обращать такое внимание на маркетинговые ярлыки?
Да, это известный факт, что есть два уровня BPMN-моделей, аналитические и исполняемые. Естественно, аналитическую модель нельзя запихнуть в движок.
Но бизнес-логику все равно надо как-то делать. Это справедливо для всех платформ.
Смысл использования графической нотации, BPMN или другой в том, чтобы сделать процесс видимым. Observability это очень полезно.
Моделирование в BPMN это избыточный этап. Да и ТЗ писать только время тратить.
То есть, вы предлагаете отказаться от моделей процессов вообще и реализовывать их сразу в коде, да? Для простых процессов в 3-5 шагов пожалуй да. Ну пропуск заказать. отпуск согласовать.
Но когда этих шагов несколько сотен (а такое бывает), то пожалуй трудновато будет держать в голове всю логику, если это просто в коде.
О, регби! Респект! (нет-нет, я не играл, только пиво пил с регбистами)
Я в математике не силен, за граф не скажу. Вот чатик утверждает, что DMN можно рассматривать как ориентированный ациклический граф (DAG), поскольку решения строятся на основе входных данных и других решений, не образуя циклов. Может врет, кто его знает.
Но зачем бы мне визуализация? В том-то и смысл, чтоб иметь компактное представление И как на графе смоделировать множественные выходы, когда hit policy = Collect?
За книжку спасибо, гляну.
Но у меня такое ощущение, что мы говорим немного о разных вещах. В контексте управления бизнес-процессами таблицы решений это то, что определено в стандарте DMN. Это совершенно конкретный механизм, реализованный в Camunda и Flowable.
Просто это статья немного верхнеуровневая, в ней опущены технические детали. Например, такая штука как Hit policy, которая определяет, как именно движок обрабатывает бизнес-правила из таблицы и что будет на выходе.
Насчет кластера -- да, говорят была такая странность. Как сейчас с ходу не скажу. Но это же друга тема, это уже не про транзакции, не так ли?
Да, вы правы, оба эти подхода применимы и нельзя сказать, что надо одно выбросить, а другое оставить. Но! Логика if-else известна каждому школьнику, а про таблицы решений надо рассказывать.
И это еще пол-дела. Если от теоретических построений перейти к конкретной реализации в системах BPM, то разница будет гораздо более заметной. Логику if-else в нотации BPMN реализуют посредством эксклюзивных шлюзов и при большом числе параметров диаграмма становится просто нечитаемой. Вот, например:
Тут всего-то пара вопросов про возраст аккаунта и траты, а уже какая-то каша.
Но есть способ лучше! Упаковываем это все в набор бизнес-правил и наша модель начинает выглядеть вот так:
И да, манипулировать правилами гораздо удобнее, чем деревом. То есть в плане поддерживаемости этот вариант лучше.
Ок, про минус видно куда-то не туда глянул и огорчился. Извиняюсь.
Дотошно сравнивать системы это хлеб аналитиков, я точно не возьмусь делать калькулятор на Камунде.
Насколько я понимаю, вот эта сложность работы с транзакциями, когда кругом микросервисы, была одной из побудительных причин, почему появилась Camunda 8 с новым движком Zeebe, где вообще нет реляционной СУБД. То есть, проблема распределенных транзакций реально существует и нельзя проектировать процесс, не принимая это во внимание.
Можно ли резюмировать нашу мини-дискуссию следующим образом? ---
Не стоит полагаться на штатные механизмы обработки распределенных транзакций в вашем процессном приложении, потому что это несет риски несогласованности данных. Но, если есть на то ресурсы и квалификация, эту проблему можно решить кастомной разработкой собственного менеджера транзакций.
Согласны?
Про распределенные транзакции не мои слова, это говорит Бернд Рюккер, сооснователь и главный технолог Camunda. Можно с ним поспорить, конечно. Но для начала лучше глянуть его статью Достижение согласованности без менеджеров транзакций.
Возможно, для вашей задачи это эффективное решение - использовать свой менеджер транзакций. Но это выглядит сложно. Почему бы просто не использовать компенсации в BPMN? Можно получить тот же результат, но штатными средствами.
Один знакомый говорил, что он может на экселе написать операционную систему, но зачем? Конечно, можно запилить калькулятор на любом BPM-движке, но едва ли в этом есть смысл.
А что конкретно вам не понравилось в статье, за что минус-то?
Да, вы правы. Если запущено два процесса и они вызывают один подпроцесс, то возникнет неоднозначность, придется делать более сложный запрос, одним бизнес-ключом не обойтись. Но это скорее гипотетическая ситуация. Едва ли в процессе ознакомления вносят изменения. Но не суть важно.
Идея в том, что лучше иметь бизнес-ключ, чем не иметь.
Увы, "восьмерка" только платная. Это мы никак обойти не можем.
А чтобы не было совсем грустно, мы решили сделать форк "семерки" и поддерживать ее дальше. Скоро выйдет наш OpenBPM Engine, но он тоже будет стоить каких-то денег.
Что касается "восьмерки", то все наши комопненты будут с ней интегрированы.
а) это не корпоративный пост, у меня нет техписа
б) окей, не доглядел, сейчас поправлю
Да, это известно про восьмерку.
Мы тоже работаем над альтернативными вариантами.
Но это же не отменяет того, что надо поглядывать на лидера, понимать куда движется.
Согласен, не доглядел. Поправлю!