Пример события в бизнес процессах

Одним из самых важных и сложных моментов, предшествующим разработке архитектуры приложения, это сбор требований и моделирование бизнес-процессов.

Не важно, внтутренний или внешний заказчик, не важно будет in-house или outsource разработка, вначале требуется понять ЧТО требуется сделать, КАКИЕ объекты будут в будущей системе и КАКИЕ сценарии должны происходить. И если ваше будущее приложение немного сложнее, чем красная кнопка с функционалом оставить отзыв, то в сложном бизнес-процессе будет присутствовать большое количесство объектов и вариантов сценариев с ними.

Но зачастую такие знания о процессах, которые должны происходить в системе при различных условиях, о возможных состояниях объектов в системе и условиях переходов из одного состояния в другое, не описаны в едином источнике знаний. Знания и понимание как должно быть могут немного содержаться в устаревшей документации, разумеется у product manager, project manager, у программистов и у многих других сотрудников компании, в том числе у собственника бизнеса.

Все события BPMN на примерах

И для такого моделирования уже существуют способы разной степени сложности и затратности по времени, но на их фоне очень выгодно выделяется подход Event Storming, введеный итальянским программистом Альберто Брандолини, успешно используемый им в контексте DDD.

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

Процесс Event Storming — это способ собрать вместе всех доменных экспертов (программистов, менеджеров и других) и учиться друг у друга, чтобы через описание событий в системе получить полную картину требуемых бизнес процессов.

Главный результат — это быстрое исследование предметной области и шаринг и фиксация знаний среди заинтересованных лиц.

Дополнительно Event Storming позволяет:

• Выявление неявных зависимостей на уровне бизнеса.
• Поиск пропущенных событий.
• Поднимать сложные вопросы о поведении пользователя еще на этапе идеи, чтобы не разрабатывать системы, которые не удовлетворяют потребностям клиентов нашего бизнеса.
• Хорошая исходная точка для моделирования бизнес-процесс на DDD, за счет использования похожей терминологии.

Составные элементы event storming — один элемент — один стикер:

• Пользователь Actor (желтый маленький стикер) — человек, выполняющий команду через представление.
• Команда (синий стикер) — это команда, выполняемая пользователем через представление агрегата, которая приводит к созданию события домена.
• Агрегат (желтый большой стикер) — совокупность объектов домена, которые можно рассматривать как единое целое.
• Внешняя система (розовый стикер) — сторонний поставщик услуг, например платежный шлюз или транспортная компания.
• Бизнес-процесс (фиолетовый стикер) — обрабатывает команду в соответствии с бизнес-правилами и логикой. Создает одно или несколько доменных событий.
• Событие домена (оранжевый стикер) — это событие, происходящее в бизнес-процессе. Пишется в прошедшем времени, как свершившийся факт.
• Представление (зеленый стикер) — это представление, с которым пользователи взаимодействуют для выполнения задачи в системе. Команды

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

Бизнес-процессы Битрикс24 — примеры на лидах, сделах, процессы со статусами

Что нужно для проведения?

1. Неограниченная поверхность — физическая стена или доска на https://miro.com
2. Разбиение на группы не более 4-х человек с разными экспертами внутри команды (люди с вопросами и люди с ответами). Event Storming должен описывать реальную модель процессов в бизнесе, для этого нужны представители от бизнеса.
3. Много стикеров
4. Много маркеров, для каждого участника.
5. Обязательно, чтобы каждый написал (отразил) хотя бы одно событие.
6. Во время Эвент Шторминга будут возникать Вопросы и Предположения — мы их долго не обсуждаем — записываем для дальнейшего уточнения в нерамках текущей сессии эвент шторминга.

Вопросы — ключ к выяснению бизнес процесса.

• Что должно произойти, чтобы произошло это событие?
• Это происходит всегда или иногда?
• Что произойдет, если что-то пойдет не так, как задумано?

Итерация 1.

Результат итерации: найдены все-все доменные события бизнес-системы.

1. Приводим краткую теорию и пример: что есть кто-то, он может вызвать команду, какие события происходят? События — действия в системе, которые уже произошли в прошлом как факт и не могут быть отменены, например: товар оплачен, пользователь добавил товар в корзину и т.д.
2. Выписываем все события в рамках домена (также в рамках всего бизнеса).
3. Размещаем события по шкале времени слева — направо.
4. Проигрываем события в обратную сторону спарва — налево. Например Товар оплачен, что этому предшествовало (какое событие) ?

Итерация 2.

Результат итерации: найдены все-все команды, вызвавшие события из итерации 1 и экторы, выполняющие команды.

1. Группы перемешиваются новыми участниками по 3 человека.
2. Краткая теория и пример про действующих лиц actors, что они вызывают команды, команды могут быть отправлены в Агрегат или во внешнею систему, в результате выполнения команды меняется состояние в системе и генерируются события. Команды — некоторое действие в будущем времени которое меняет состояние, например: отправить уведомление, сформировать платежку. Это действие, которое может и не произойти, если не будет удовлетворять условиям в системе. Зачастую команда генерирует событие — оплатить заказ — заказ оплачен. Также бывает, что Одна Команда — может сгенерировать несколько разных событий, а также разные команды — могут привести к одному событию.
3. Группы проигрывают процесс вперед и назад и через стикеры описывают процесс для себя, а потом проигрывают для других групп, формируя единое понимание и единый язык, а также дополняя темные пятна.

Итерация 3.

1. Краткая теория и пример для политик и подпроцессов. Например, запрос на возврат средств — предусмотренно ли политикой — если да то возникает команда — команда например во внешнюю систему возврата — генерируются события средства возвращены. Политики вдальнейшем программисты реализуют как бизнес-правила в рамках агрегатора.
2. Группы проигрывают процесс вперед и назад и дополняют схему политиками и процедурами
3. Также группы указывают уже возможные модели чтения — формируется постепенно UI.

Итерация 4

Результат итерации — определенные ограниченные контексты и агрегаты в которых выполняются команды и происходят события.

1. Краткая теория про абстракцию Агрегат, что это совокупность сущностей, рассматриваемых как единое целое и имеющие транзакционную границу и целостность данных. Например, ордер и к нему имеются транзакции — и мы к транзакциям обращаемся не напрямую, а через агрегат Ордер. Зачастую агрегат будет фигурировать в команде.
2. Группы проигрывают процесс вперед и назад, выявляя агрегаты и отражая их на схеме.

Описание ограниченного контекста далее удобвно фиксировать как текст ввиде конкретной формы в конфлюенс.

Самый важный момент, что анализ предметной области происходит за часы вместо недель. Процесс происходит естественно и открыто. Эксперты предметных областей сами расказывают все нюансы и делятся информацией, программистам не приходится додумывать.

А по завершении Event Storming мы как программисты имеем четкие ограниченные контексты для разделения на домены и реализации DDD в нашем приложении.

Дополнительная информация:

• моделирование бизнес-процессов подход bpmn.
• статья 2013 года на блоге Альберто Брандолини.
• дополнительные источники на оф сайте об event storming.
• выступление 2017 года Альберто Брандолини об event storming.
• книга об event storming от Альберто Брандолини.
• доклад Сергея Баранова на митапе в Райффайзен-банке.
• статьи об event storming на сайт Сергея Баранова.
• мастер-класс Евгения Пешкова на канале DDDevotion на youtube.
• мастер-класс Сергая Баранова.
• статья в блоге ontico на habr.

Источник: world-hello.ru

Маршрутизация событий в процессах

Для того, чтобы запустить новый экземпляр процесса или направить сообщение на уже функционирующий инстанс, необходимо выбрать наиболее подходящий инструмент: Java, REST API, SOAP Web Services или JMS. Начнем с короткого обзора стартовых событий.

Оригинал статьи на английском языке размещен тут: Routing Events to Processes

Выбор корректного BPMN события

Стартовые события. Для запуска нового процесса может быть использовано несколько стартовых BPMN. Рассмотрим случаи использования различных стартовых событий:

1. None Event – в процессе одно стартовое событие или условие для запуска экземпляра процесса не указано.
2. Message Event – используется в случае, когда необходимо различать несколько стартовых событий.
3. Timer Event – автоматический запуск процесса контролируется таймером.
4. Signal Event – необходимо запустить сразу несколько инстансов (редко используется).
5. Conditional Event – запускает событие при выполнении определенного условия.

Рассмотрим следующий процесс в качестве примера:

1. None start event показывает типичную отправную точку процесса. Еще раз отмечу, что только одно подобное стартовое событие может существовать в процессе.
2. Это message start event начнет процесс при получении определенного сообщения извне.
3. В процессе может быть несколько message start event. В данном примере оба message start event оказались исключительными случаями, в подобных ситуациях лучше использовать вместо none start события message start event.

Промежуточные события. Несколько промежуточных BPMN событий (и задач-получения сообщения) могут быть использованы для того, чтобы заставить инстанс процесса ждать и реагировать на определенные триггеры.

1. Message Event — используется, когда направляем сообщение конкретному и уникальному экземпляру процесса.
2. Receive Task – очень похож на message event, но используется для того, чтобы дополнительно использовать boundary events.
3. Timer Event – используется, когда хотим заставить инстанс процесса ожидать некоторое время.
4. Signal Event – используется, когда направляем сигнал всем инстансам процесса, ожидающим его.
5. Conditional Event – как только определенное условие выполнено, процесс продолжается.

1. Процесс не сдвинется с этой точки до тех пор пока не будет получено сообщение.
2. До тех пор пока токен находится на активности “Order fulfillment”, процесс может принять сообщение “Order canceled”.

Использование методов API Camunda для маршрутизации событий в процессах

Запуск процесса по ключу. Если в процессе одно стартовое событие, то достаточно сослаться на определение этого процесса по идентификатору в BPMN XML файле. Это наиболее часто встречающийся случай.

processEngine.getRuntimeService().startProcessInstanceByKey(«invoice»);

Идентификатор процесса определен в BPMN. API называет этот идентификатор ключом (Key) процесса. Чтобы извлечь processEngine необходимо либо инджектировать его (самый простой путь, это работает out-of-the-box используя Spring или CDI), либо осуществить поиск следующим образом:

Запуск процесса с помощью сообщения. Как только в процессе появляется несколько отправных точек необходимо использовать именованные сообщения для старта процесса. Названия стартовых событий должны быть уникальными в рамках всего Process Engine, иначе движок не сможет определить какой именно процесс запускать.

processEngine.getRuntimeService() .createMessageCorrelation(«message_invoiceReceived») .setVariable(«invoiceId», «123456») .correlate();

1. message_invoiceReceived – имя сообщения, определенное в BPMN-модели процесса
2. («invoiceId», «123456») – то, что передается инстансу вместе с сообщением

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

Запуск определенной версии процесса по идентификатору. По умолчанию Process Engine всегда стартует самую новую версию процесса. Запуск определенной версии процесса возможен по ссылке на ID (primary key) этой версии процесса из process engine database.

ProcessDefinition processDefinition = processEngine().getRepositoryService() .createProcessDefinitionQuery() .processDefinitionKey(«invoice») .processDefinitionVersion(17) .singleResult(); processEngine().getRuntimeService() .startProcessInstanceById(processDefinition.getId());

В данном случае имеется в виду не ID из BPMN XML файла (который еще называется ключом (key) в Process Engine), а ID который можно назвать первичным ключом (primary key) базы данных Camunda. На этот ID невозможно повлиять, он создается во время deployment time.

Корреляция сообщений к уже запущенным инстансам процессов.

Чтобы отправить сообщение процессу, ожидающему это сообщение, достаточно сопоставить некоторые свойства входящего сообщения с некоторыми свойствами ожидающего процесса. Эта процедура называется корреляцией (corellate message).

runtimeService .createMessageCorrelation(«myMessage») .processInstanceBusinessKey(myMessage.getOrderId().toString()) .processInstanceVariableEquals(«customerId», myMessage.getCustomerId()) .correlate();

1. myMessage – имя сообщения, которое ждет процесс
2. processInstanceBusinessKey(myMessage.getOrderId().toString) — если процесс содержит orderId сообщения в качестве своего бизнес ключа
3. и если переменная процесса “customerId” также соответствует ожиданиям.

Лучше всего коррелировать входящие сообщения на основе одного уникального атрибута (например «correlationIdMyMessage»), созданного специально для этого сообщения. В качестве альтернативы также есть возможность выбрать экземпляр процесса, на который нацелено сообщение, на основе запроса, включающего сложные критерии, а затем в качестве второго шага явно коррелировать сообщение с выбранным экземпляром процесса.

Маршрутизация сигналов. Корреляция с конкретным экземпляром процесса при использовании сигнала — невозможна. Механизм сигналов предназначен для информирования сразу нескольких экземпляром процесса, которые подписаны на конкретное событие сигнала:

runtimeService .createSignalEvent(«mySignal») .setVariables(variables) // pass variables (optional) .send();

Источник: reunico.com

События

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

Стартовое событие

Стартовое событие инициирует запуск процесса и указывает, в какой точке он берет начало. Процесс может содержать только одно стартовое событие.

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

Вкладка «Основное»

• Инструкция — в этом поле можно дать краткое описание процесса. Оно будет отображаться в стартовом окне, что позволит сотрудникам легко ориентироваться в процессе.
• Уведомление о запуске процесса — здесь можно ввести текст уведомления, которое вы увидите вверху страницы после того, как запустите процесс.

Вкладка «Форма»

На этой вкладке вы можете настроить внешний вид стартового окна процесса. Оно откроется сразу после того, как вы запустите процесс.

Чтобы настроить форму, перетащите переменные из столбца Контекст в столбец Название на форме . Чтобы создать новую перемененную, нажмите на кнопку + Добавить .

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

Укажите, какие переменные обязательны для заполнения , а какие доступны только для чтения . Поля, доступные только для чтения, можно скрывать с формы, если они не заполнены. Для этого нажмите на название поля в списке — откроется окно с его настройками. Включите опцию Скрывать, если не заполнено .

Эта настройка доступна для полей всех типов, кроме типа Приложение.

Для настройки формы вы также можете использовать готовый шаблон формы или создать новый. Подробно о создании шаблонов форм можно прочитать в статье «Вкладка «Формы».

Настроенное стартовое окно выглядит, например, так:

Имейте в виду, если вы настраиваете бизнес-процесс на уровне приложения, то на вкладке Форма вы увидите переключатель, который позволяет работать как с переменными процесса, так и со свойствами приложения.

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

Выбирайте контекст приложения, если хотите добавить или удалить свойства, которые имеют отношение только к приложению. Добавленное в дизайнере свойство будет отображаться на карточках создания, просмотра или редактирования приложения.

Вкладка «Настройки запуска»

Меню Создать — если вы выберете эту опцию, то сотрудник сможет запустить процесс с главной страницы системы, нажав на кнопку Создать .

Расписание — эта опция позволяет запускать процесс по расписанию.

В поле Запустить процесс автоматически подставляется текущая дата и время. Если процесс будет стартовать с определенной периодичностью, эти данные используются для вычисления каждого следующего запуска.

В поле Завершить указывается дата и время, после которых система больше не будет инициировать процесс.

В поле Повторять вы можете определить периодичность запуска:

• Однократно — процесс будет запущен один раз. Обратите внимание, если вы выберете дополнительный параметр Повторять в течение дня , система будет повторно инициировать процесс в течение суток с указанной периодичностью.

• Ежедневно — процесс может запускаться каждый день или раз в несколько дней. Периодичность определяется в поле Повторять каждый . день . Кроме того, вы можете настроить поведение системы, если событие выпадает на нерабочий день, а также указать, нужно ли повторять запуск в течение дня.
• Еженедельно — процесс может запускаться каждую неделю или раз в несколько недель. Периодичность определяется в поле Повторять каждую . неделю . При необходимости выберите, в какой именно день недели должен стартовать процесс. Кроме того, вы можете указать, каким образом должна вести себя система, если старт выпадает на нерабочий день.
  Например, процесс подачи еженедельных отчётов будет запускаться каждую неделю по понедельникам в 11 часов. Если старт выпадает на нерабочий день, то процесс на этой неделе запущен не будет.

• Ежемесячно — процесс будет запускаться каждый месяц или раз в несколько месяцев. Укажите дни, когда система должна инициировать процесс.
  Например, процесс выдачи заработной платы будет запускаться ежемесячно 10 и 20 числа. Если эти даты выпадают на нерабочий день, то старт процесса будет перенесен на ближайший рабочий день.

Поле Только по рабочим дням позволяет определить поведение системы, если старт выпадает на нерабочий день:

• пропустить — процесс не будет запущен;
• предыдущий — процесс будет запущен в предыдущий рабочий день;
• следующий — процесс будет запущен в следующий рабочий день;
• ближайший — процесс будет запущен в ближайший рабочий день.

Настройка При пропуске определяет поведение системы, если сервер был недоступен в запланированное время запуска.

Обратите внимание, что у процесса, который запускается по расписанию, не должно быть формы стартового события.

Вкладка «Название»

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

В поле Шаблон введите название для экземпляра процесса, если нужно, добавьте контекстную переменную, например, ФИО инициатора. Список доступных переменных открывается при нажатии на значок + в правом углу поля.

Промежуточное событие-таймер

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

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

Точное время

Если вы выберете эту опцию, то сможете указать точное время, по истечении которого выполнение процесса возобновится. Например, процесс будет ожидать ответа от заказчика два дня. После того как установленное время истечет, исполнение процесса продолжится.

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

Переменная

Вы можете определить дату и время, после которых выполнение процесса будет возобновлено, при помощи контекстной переменной.

В поле Срок выполнения выберите переменную из списка или добавьте новую. Для этого нажмите Создать новую переменную и в открывшемся окне заполните обязательные поля.

Обратите внимание, что вы не можете изменить тип, т. к. в промежуточных событиях-таймерах всегда используются переменные типа Дата/время . Однако можно указать дополнительные параметры:

• Устанавливать текущие дату и время — в качестве значения переменной будут автоматически подставляться текущие дата и время в часовом поясе данного пользователя;
• Время опционально — при заполнении переменной Дата/Время пользователь может не уточнять время.

Заполните все обязательные поля и нажмите на кнопку Создать .

Конечное событие

Конечное событие указывает на то, в какой точке завершается процесс или одна из его веток. У конечного события не может быть исходящих переходов. Количество таких событий в процессе не ограничено. В настройках конечного события вы можете указать его название для повышения наглядности схемы процесса.

Источник: elma365.com