В прошлой записи я пошел навстречу любителем сообщений и включил события-сообщения и задачи-сообщения в палитру BPMN с ручным приводом. Честно говоря, я бы рекомендовал обходиться без них, т.к. слишком часто люди используют сообщения сверх всякой меры и некорректно, как в следующем примере:
Опасно! Не пытайтесь повторить.
Я заметил, что те, кто обходятся задачами, развилкам и потоками управления, рисуют схемы более понятные и прямолинейные, чем те, кто в курсе существования сообщений. События-сообщения и задачи-сообщения похожи на автоматические задачи: они предназначены для процессных движков, а не для того, чтобы их обрабатывали люди.
Самое распространенное заблуждение - это считать, что конвертик на иконке имеет отношение к электронной почте. В действительности отправка электронной почты должна моделироваться пользовательской задачей, если процесс исполняется вручную, и задачей на выполнение сценария, если используется BPMS:
 |
 |
 |
| Неправильно: email через сообщение |
Правильно: email через пользовательскую задачу (ручной процесс) |
Правильно: email через задачу-сценарий (процесс, реализованный в BPMS) |
Если вам надо показать, что какая-то задача взаимодействует с внешним миром (например, с заказчиком или поставщиком), то можно использовать пул - черный ящик и сообщения, прикрепленные непосредственно к задаче:
Но лучше не засорять диаграмму потоками сообщений и черными ящиками. Ведь если задача называется “Get customer’s commitment”, то и так понятно, что она взаимодействует с клиентом:
Использование черных ящиков и сообщений имеет смысл только в одном случае: если вам надо отобразить ВСЕ сообщения, входящие в / исходящие от внешнего контрагента, чтобы специфицировать “коммуникационный контракт” с ним.
И завершая эту заметку,- о различиях между событиями-сообщениями и задачами-сообщениями: их основные функции тождественны; небольшое различие проистекает из общего различия между событиями и задачами. К последним можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), что иногда бывает удобно:
Кстати, события-сообщения обрабатываются event-based шлюзами. А задача-сообщение, по сути, не должна?
Теоретически за развилкой по событиям может стоять как событие, так и задача на получение сообщений. Но что будет, если задача с циклом, например? На практике наверное лучше использовать честные события, а не задачи.
Анатолий, спасибо за статью!
Рад, что моя диаграмма помогла вам раскрыть тему про сообщения.
Можете ответить на несколько вопросов по статье?
1. В целом речь идёт о “BPMN с ручным приводом”, но ведь на рисунке явно видно, что сквозной процесс выполняется BPM-движком, координирующим работу других систем. Насколько релевантно приводить эту диаграмму, обсуждая BPMN с ручным приводом?
2. Вы говорите, что на приведённой схеме сообщения использованы некорректно. Можете пояснить, в каком именно месте некорректность, и в чём она состоит (я задавал этот вопрос на bpmnforum, но вы не ответили)?
3. Чем приведённая диаграмма, которая приведена в качестве отрицательного примера, принципиально отличается от той, которая приведена на рис.5.2 в вашей статье “Дирижировать или реагировать” (http://mainthing.ru/ru/item/613/)?
А что не так в том, чтобы после событийного шлюза (event-based) поставить задачу-получение сообщения с циклом (receive task)?
Шлюз ждёт, пока появится событие в обработчиках, соединённых с ним потоками управления. Если первым появляется сообщение в задаче-получении сообщения, то остальные обработчики, стоящие после событийного шлюза, не будут никогда активированы, даже если появятся события, на которые они настроены. А когда задача-получение сообщения с циклом будет выполнена, процесс пойдет дальше по исходящему из этой задачи потоку управления.
Вот “что будет, если задача с циклом”. Разве не так?
Анатолий,
в своей статье “Баланс между оркестровкой и межпроцессным взаимодействием в BPMN” (http://mainthing.ru/ru/item/439/) в конце Вы говорите: “В следующей статье поделюсь опытом, как в ходе анализа выявлять независимые процессы.”. Не подскажете ссылку на эту “следующую статью”?
Извините, что спрашиваю здесь, но в оригинальной статье комментирование уже закрыто.
P.s. Если смотреть статьи по тэгам, то на странице, в конце набора фрагментов, на русском языке есть только ссылка “<< Назад”, которая очень сбивает с толку. Я несколько лет думал, что “Назад” - это действительно назад, и полагал, что статьи архивируются и доступ к ним закрывается. :))) Кстати, на английском это выглядит как “Older Entries”. Эти навигационные ссылки можно на русском исправить на “Раньше / Позже” или вшито в “движок”?
Владимир
Некорректными у вас получились пулы “Сервисы бухгалтерии”, “Сервисы отдела продаж”; на рис 5.2 внешние системы изображены черными ящиками. Второе отличие: рис. 5.2 подразумевает, что внешняя система отрабатывает нетривиальный и протяженный фрагмент процесса, включающий в том числе пользовательские задачи. Если надо просто вызвать автоматическую функцию (сервис) внешней системы, то это уместнее было бы сделать через задачу-вызов сервиса. Саму внешнюю систему при этом можно отобразить дорожкой.
По поводу задачи с циклом - трактовка выглядит логичной, но вы сможете поручиться, что производитель движка реализовал именно такую трактовку?
Старые сообщения пришлось закрыть из-за потока спама.
Сейчас я уже не вспомню, что мне помешало написать продолжение в 2011 году. Отчасти тему выявления процессов раскрывает статья “Дирижировать или реагировать”.
Hi Anatoly,
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
Bogdan
Sure, why not - if we model an engine-powered process. This post was about human-powered ones, though.