Можете написать Deadlock на Camunda BPM? А я могу

[ganqqwerty]

А вот во Flowable так не выйдет!

[nshipyakov]

можно по подробней?

[sibkedr]

Таким значком изображается параллельный шлюз. Parallel Gateway — самый простой из шлюзов для построения параллельно выполняющейся части процесса.

Существует два типа параллельных шлюзов:

fork — создает отдельный execution для каждой ветки;
join — ожидает выполнения всех входящих executions.

Тогда, что-то я запутался. В исправленной схеме на диаграмме 8, разве join Parallel не должен дождаться токенов со всех входящих в него стрелочек? В него же входят 5 стрелок (вместе с дефолтным). А прийти может, например, 2 — после проверки и после валерьянки.

[nshipyakov]

Спасибо за вопрос. Параллел по идее посмотрит на число активных экзекушенов. Он посмотрит сколько что все активные зашли — ок.

[sshikov]

Я когда-то давно был одним из тех, кто писал первый кредитный конвейер для Тинькофф. Честно скажу — с тех самых пор (до настоящего времени) ко мне все еще прибегают рекрутеры с предложениями поработать на IBM BPM. Эх, скольких пришлось разочаровать…

Раз за вас, что наконец нашелся более удобный движок.

[nshipyakov]

Писали бэк на javascript, когда это еще не было мейнстримом:)?

[sshikov]

Ну, если выбирать между BPMN и javascript — то второе лучше. Даже в том ограниченном виде, в каком имеется в IBM BPM.

[Dauer]

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

1. Два токена вышли из форк.
2. Один из двух токенов превращается в 2, 3, 4
3. Джойн паралель не может правильно посчитать токены.

Не пробовали вместо джойн инкюзив сделать джойн паралель?

Тогда бы все токены по нижней ветке соберутся в один -> и джойн паралельного получит два токена, как он и планировал изначально.

[nshipyakov]

На диаграмме 8 примерно это и происходит. Все собирается в параллеле джойн. А насчет того чтобы сделать 2 паралл джойн — это кажется контринтуитивно. Ради интереса впрочем попробовать можно

[mayorovp]

Для того, чтобы исходить из принципа "сколько токенов вышло и форка, столько же должно зайти в джойн", нужно некоторое соответствие взаимное форков и джойнов, а оно-то BPMN и не требуется.

Всё-таки, BPMN задумывалось как средство бизнес-анализа, а не как средство реализации.

[Diaskhan]

зашёл думал будет про дедлоки, а написали про то что не знают bpmn, похвально!

[nshipyakov]

ну так проблема в том, что Inclusive Join работает некорректно. Он ждет тот экзекушен, который не должен ждать

[a_aleksin]

Если убрать execution 2-4 в subprocess, то проблема уйдет?

[nshipyakov]

ну если весь инклюзив в подпроцесс убрать то да. в выводах в п3 про это упомянул

[UvaysovRI]

Диаграмма 8 не будет работать.
Вот цитата: «A parallel gateway will simply wait for all incoming sequence flows ......»

[nshipyakov]

все работало хорошо в варианте как на диаграмме 8

[aleexp]

У меня вопрос про исходную логику этого синтетического примера:

Проверка благонадежности и возможных услуг никак между собой не связаны — эти действия можно выполнять параллельно.

А точно ли не связаны? Предложение услуг разве предусматривается для неблагонадежных клиентов? В описанной схеме поиск услуг будет обрабатываться даже для неблагонадежных клиентов, что, вероятно, будет зря расходовать ресурсы. Может, следовало бы поиск услуг запускать после выполнения проверки надежности только с положительным результатом?

[nshipyakov]

ну так то оно так, но на то это и синтетический пример. но вообще замечание разумное — спасибо!