Я об этом даже не думал, честно говоря, когда проектировал

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

Да, согласен, над таким штуками заморачиваться не хочется :(

я пока пришел к тому что в bpmn или движках на этот счет не хватает атомарных элементов либо в движках возможности коррелировать send и recieve так что бы на ресив виртуальный токен появлялся (по типу того гейтвея что на форуме камунды, только без ебалистики в схеме)

но это блин странно) вроде все юзают, а общих подходов как будто нету, как не отстрелить себе ногу

Да не так давно юзают, пожалуй, ещё не утряслось это всё

а в новых движках типа зиби это как-то решено не?

а еще вопрос, эта проблема имеет какое-то название которое можно гуглить хоть?) с гонкой токенов

Не стоит рисовать так процессы просто

ну вот тогда вопрос где вообще можно применять intermediate receive event :)

В межпроуессном взаимодействии

я не оч понимаю что ты межпроцессным взаимодействием называешь до конца, такое ощущение что ты имеешь ввиду только кейсы когда процессы в одной камунде крутятся. Но если у тебя микросервисы, сага и эмбед камунда например - это уже не межпроцессное?)

ну вот пример твой, пока ты контроллируешь нижний процесс вероятность того что будет токен-рейсинг(?) контроллируется тобой. Но как только ты вынес его в соседний отдел - там могут вставить условие "проверить новые заказы" -> "если лишние детали уже лежат в углу" -> "сообщить что заказ уже выполнен". И ты об этом не узнаешь, т.к. это соседний процесс.  Условно будет рейсинг или нет зависит от времени за которое второй процесс обработается

кстати, а вот эти штуки отличаются вообще чем-нибудь?

Нууу, на последний не повесишь boundary event :)

да, поправка: правый именно как intermediate event, а не баундари)

вот так, короче

баундари на левую не повесишь

task придумали в bpmn2 еще