Это строго обратный процесс описанному мной.
Не, проект давно накостылен и наверное где-то до сих пор работает. Но ещё раз - основная мысль в том, что bpm (и, соответственно, bpmn движки) не подходит для практического описания любого процесса. Только весьма узкого класса.

Процессы линейны, структурированы и однонаправлены только в головах бизнеса )

для описания бизнес процесса, да. понятно что для термодинамического процесса уже не подходит

Да не, очень немногих бизнес-процессов, в том проблема.
Как бы, лексическая полнота есть, но задолбаешься )

У нас есть следущие плюсы:
1) Мы сейчас понимаем, как устроен бизнес-процесс, на уровне, который может понять бизнес-аналитик. Что, откуда и куда. Где пользователь включается в процесс, где система сама отрабатывает.
2) Снижается вероятность сломать бизнес-процесс и накодить не стыкующиеся с ним действия: все такие моменты инкапсулируются в тасках.
Минусы:
1) В самих тасках может твориться полный беспредел и вакханалия. В том числе непонятно когда происходящий вызов каких-то других бизнес-процессов той же камунды. То есть определенность появляется только на верхнем уровне.
2) Адекватного описания тасков не хватает. По сути камунда оперирует черными ящичками. А хотелось бы знать, о чем они и какова их логика.

https://cadenceworkflow.io/
На ее базе попробуйте. В Activity там может твориться все что угодно как раз

А там есть возможность в интерфейсе редактировать процессы? Бизнес-аналитиков туда запустить реально?

это engine, это не графический движок для рисования процессов
это как бы основа на которой можно реализовать и BPMN и всякое иное подобное

и DSL-и

графика - это вообще лучше отдельно прикручивать к текстовому DSL

Менять камунду будет крайне дорого, поэтому такой вариант даже не рассматривается. Есть жопки поприоритетнее. Да и ее минусы вполне решаются другими методами. Более примитивными (грубо говоря, держать в базе знаний описания тасков), зато дешевыми

Не, ну какой реализовать. Нужно коробочное решение. А его нет

Была задачка найти состояние заявки в этой Camunda через api. Обплевались и аналитики, и разработчики, т.к. есть уходы на подпроцессы, вызовы событий и пр. приколы, которые одним запросом не выгребешь никак.

Версий процессов может быть 200+, по несколько десятков заявок в каждой. И всё это нужно было опретивно обработать и отобразить пользователям в виде понятной последовательности, истории заявки, своего рода. Причем как по service, так и по user таскам..

Для MVP  инструмент пойдет, навертеть можно что угодно. А вот сопровождать это потом будет больно

Camunda... TRIGGERED

😂

Я

Вечером скину "Ромашку"

Активити диаграм. Которую зациклили на Documentum и получили разработку встроенных систем (2006?)

Йееее