Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Потоки сообщений, события-сообщения и задачи-сообщения

В прошлой записи я пошел навстречу любителем сообщений и включил события-сообщения и задачи-сообщения в палитру BPMN с ручным приводом. Честно говоря, я бы рекомендовал обходиться без них, т.к. слишком часто люди используют сообщения сверх всякой меры и некорректно, как в следующем примере:

Опасно! Не пытайтесь повторить.

Я заметил, что те, кто обходятся задачами, развилкам и потоками управления, рисуют схемы более понятные и прямолинейные, чем те, кто в курсе существования сообщений. События-сообщения и задачи-сообщения похожи на автоматические задачи: они предназначены для процессных движков, а не для того, чтобы их обрабатывали люди.

Самое распространенное заблуждение - это считать, что конвертик на иконке имеет отношение к электронной почте. В действительности отправка электронной почты должна моделироваться пользовательской задачей, если процесс исполняется вручную, и задачей на выполнение сценария, если используется BPMS:

Неправильно:
email через сообщение
Правильно: email через пользовательскую задачу
(ручной процесс)
Правильно: email через задачу-сценарий
(процесс, реализованный в BPMS)

Если вам надо показать, что какая-то задача взаимодействует с внешним миром (например, с заказчиком или поставщиком), то можно использовать пул - черный ящик и сообщения, прикрепленные непосредственно к задаче:

Но лучше не засорять диаграмму потоками сообщений и черными ящиками. Ведь если задача называется “Get customer’s commitment”, то и так понятно, что она взаимодействует с клиентом:

Использование черных ящиков и сообщений имеет смысл только в одном случае: если вам надо отобразить ВСЕ сообщения, входящие в / исходящие от внешнего контрагента, чтобы специфицировать “коммуникационный контракт” с ним.

И завершая эту заметку,- о различиях между событиями-сообщениями и задачами-сообщениями: их основные функции тождественны; небольшое различие проистекает из общего различия между событиями и задачами. К последним можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), что иногда бывает удобно:

19.01.17 | Статьи |    

Комментарии (8)

  1. Юлия 20.01.17 12:49

    Кстати, события-сообщения обрабатываются event-based шлюзами. А задача-сообщение, по сути, не должна?

  2. Anatoly Belychook 20.01.17 12:58

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

  3. Владимир 21.01.17 18:00

    Анатолий, спасибо за статью!

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

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

  4. Владимир 21.01.17 18:34

    А что не так в том, чтобы после событийного шлюза (event-based) поставить задачу-получение сообщения с циклом (receive task)?

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

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

  5. Владимир 22.01.17 00:51

    Анатолий,

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

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

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

  6. Anatoly Belychook 22.01.17 10:08

    Владимир

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

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

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

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

  7. Bogdan N 06.02.17 17:40

    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

  8. Anatoly Belychook 06.02.17 17:54

    Bogdan

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

А что вы думаете?

Captcha

Copyright © 2008-2017 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии