Sure, why not - if we model an engine-powered process. This post was about human-powered ones, though.

some modern process engines implement sending emails via service tasks / external classes (enabling you to use whatever external communication channel you wish: email, SMS, Slack, Twitter etc).
In this case, it is appropriate to use the envelope task.

Regards,
Bogdan

Некорректными у вас получились пулы “Сервисы бухгалтерии”, “Сервисы отдела продаж”; на рис 5.2 внешние системы изображены черными ящиками. Второе отличие: рис. 5.2 подразумевает, что внешняя система отрабатывает нетривиальный и протяженный фрагмент процесса, включающий в том числе пользовательские задачи. Если надо просто вызвать автоматическую функцию (сервис) внешней системы, то это уместнее было бы сделать через задачу-вызов сервиса. Саму внешнюю систему при этом можно отобразить дорожкой.

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

Старые сообщения пришлось закрыть из-за потока спама.

Сейчас я уже не вспомню, что мне помешало написать продолжение в 2011 году. Отчасти тему выявления процессов раскрывает статья “Дирижировать или реагировать”.

в своей статье “Баланс между оркестровкой и межпроцессным взаимодействием в BPMN” (http://mainthing.ru/ru/item/439/) в конце Вы говорите: “В следующей статье поделюсь опытом, как в ходе анализа выявлять независимые процессы.”. Не подскажете ссылку на эту “следующую статью”?

Извините, что спрашиваю здесь, но в оригинальной статье комментирование уже закрыто.

P.s. Если смотреть статьи по тэгам, то на странице, в конце набора фрагментов, на русском языке есть только ссылка “<< Назад”, которая очень сбивает с толку. Я несколько лет думал, что “Назад” - это действительно назад, и полагал, что статьи архивируются и доступ к ним закрывается. :))) Кстати, на английском это выглядит как “Older Entries”. Эти навигационные ссылки можно на русском исправить на “Раньше / Позже” или вшито в “движок”?

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

Вот “что будет, если задача с циклом”. Разве не так?

Рад, что моя диаграмма помогла вам раскрыть тему про сообщения. Можете ответить на несколько вопросов по статье?

1. В целом речь идёт о “BPMN с ручным приводом”, но ведь на рисунке явно видно, что сквозной процесс выполняется BPM-движком, координирующим работу других систем. Насколько релевантно приводить эту диаграмму, обсуждая BPMN с ручным приводом?
2. Вы говорите, что на приведённой схеме сообщения использованы некорректно. Можете пояснить, в каком именно месте некорректность, и в чём она состоит (я задавал этот вопрос на bpmnforum, но вы не ответили)?
3. Чем приведённая диаграмма, которая приведена в качестве отрицательного примера, принципиально отличается от той, которая приведена на рис.5.2 в вашей статье “Дирижировать или реагировать” (http://mainthing.ru/ru/item/613/)?