Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Message Flows, Events And Tasks

In my previous post I did a favor to BPMN messages fans by including these elements into human-powered palette. Frankly, I’d recommend to leave them off because in too many cases people use message events excessively and incorrectly, like in the example below:

Dangerous! Do not try this at home.

People that use just tasks, gateways and control flows, tend to create more straightforward and more comprehensible diagrams than those who are aware of BPMN messages and message elements. BPMN message events/tasks are similar to automatic tasks: they are for process engines and aren’t supposed to be executed by a human.

The most common misunderstanding is associating the envelope icon with email. A human task should be utilized to model sending an email in human-powered environment; if the process is BPMS-powered then script task is the best option:

Wrong: email via messages Right: email via human task

(human-powered process)

Right: email via script task

(BPMS-powered process)

If one just wants to depict that a certain task communicates with some external entity (e.g. customer or supplier) then black box pools and message flows attached directly to the task may be an option:

Better yet, keep the diagram clear from message flows and black box pools. If the task is labelled “Get customer’s commitment” then it’s pretty clear that it communicates with the customer, no need to clutter the diagram:

There is only one case when black boxes and messages are essential: if one needs to depict ALL the messages going to/from the external entity in order to visualize the complete “communication contract” with the said entity.

The final note about message events vs. message tasks: their primary functions are identical. The subtle differences are those between events and tasks in general: unlike events, tasks may carry attached events (e.g. timers) and/or modifiers (e.g. mutli-instance) which is handy sometimes:

01/19/17 | Articles |    

Comments (8)

  1. Юлия 01/20/17 12:49 PM

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

  2. Anatoly Belychook 01/20/17 12:58 PM

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

  3. Владимир 01/21/17 06:00 PM

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

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

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

  4. Владимир 01/21/17 06:34 PM

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

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

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

  5. Владимир 01/22/17 12:51 AM

    Анатолий,

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

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

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

  6. Anatoly Belychook 01/22/17 10:08 AM

    Владимир

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

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

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

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

  7. Bogdan N 02/06/17 05:40 PM

    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 02/06/17 05:54 PM

    Bogdan

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

Comments are closed

Copyright © 2008-2024 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments