7 вещей, которые надо добавить к BPMN-схеме, чтобы получить процессное приложение
Умение рисовать схемы в BPMN недостаточно для формирования ТЗ и разработки IT-приложения, которое эту схему автоматизирует. Расскажу о том, что нужно добавить, чтобы автоматизировать процесс BPMN в BPMS-системе на примере Camunda BPM.
1. Процесс
Будем считать, что к нам поступила нормальная схема от аналитиков, которые действительно умеют их составлять. Мы, как автоматизаторы, не ставим под сомнение логику и правильность схем.
Мы должны проверить, что в схеме использованы символы, которые поддерживает наша BPMS. В случае с Camunda BPM смотрим ссылку и ищем, есть ли в нашей модели неопределённые таски, множественные события или параллельные множественные.
Неопределённые таски определяем, множественные события стараемся привести к виду других событий.
В Camunda предпочитаю покрасить схему так, чтобы было понятно что именно нам предстоит сделать — зеленый делаем средствами BPM, красный — пишем код на Java, фиолетовый — пишем на HTML,JS. Серое — не делаем ничего или используем что-то, что делали раньше.
На этом этапе настраиваем все названия сообщений, таймеры, скрипты в событиях.
2. Модель данных и контекст
В реальности процесс не работает без данных — невозможно заказать пиццу, если не знаешь адрес доставки. BPMN не предлагает каких-либо встроенных подходов для моделирования данных и их маппинга на активности процесса. Так же схеме BPMN всё равно где и в каком виде вы храните данные.
Поэтому на этом шаге мы должны составить диаграмму классов нашего процесса и расположить её по задачам. Это шаг самый важный при создании процессного приложения, потому что ошибки в построении модели данных очень дорого переделывать.
Может потребоваться решить вопрос ГДЕ именно, в какой БД и таблицах хранить эти данные.
В Camunda этот вопрос решён из коробки, классы хранятся в Key-value хранилище в SQL-базе, используется ORM MyBatis и работа напрямую с табличками и прочими делами не предполагается.
Так же на этом шаге может захотется натыкать действий вида «Записать в базу», «Считать из базы». Пожалуйста, не делайте этого, потому что схема вырастит минимум в три раза и потеряет свои визуальные приемущества (и перестанет быть схемой от аналитика). Решайте технологические вопросы не трогая схему.
Например в Camunda на каждом из элементов есть листнеры. При попадании процесса на элемент можно вызвать любой джава код.
3. Формы
На этом этапе нам нужно взять и определить как будут выглядеть пользовательские формы (фиолетовые штуки) с диаграммы. Для макетирования я использую Axure.
Как бы не хотелось наводить красоту, но процессные приложения с точки зрения форм и своей сути довольно простые — нужно доставить какие-то данные до пользователя, собрать с него какие-то другие данные. Так же на этом этапе определяю права на данные в разных задачах (визуализацией формы). В Camunda BPM формы создаются на HTML, Javascript и Angujar. Специальные API предоставляю доступ до контекста процесса, так что остается всё это дело красиво разложить.
4. Шлюзы и бизнес-правила
На этом этапе мы пишем правила для шлюзов и прочие бизнес-правила, если они есть. При написании условий используем данные, которые определили на втором этапе. В Camunda BPM бизнес-правила задаются в DMN нотации.
А правила на шлюзах пишутся на скриптах, например с помощью Groovy или JavaScript
5. Исполнители
Чтобы пользователи могли выполнять задачи они их должны найти. Поэтому во все пользовательские задачи нужно прописать исполнителей. В Camunda BPM это делается в моделлере.
Бывают более сложные случаи определения исполнителей, например по количеству задач в работе, по нормативам и т.д. Для этого нужно писать код.
6. Код, интеграции
В бизнес-процессах код и интеграции работают ради данных — например, надо сходить в API платежной системы и узнать, пришёл ли платёж. Или получит массив гос.контрактов и найти самый дорогой. Как правило этот код очень высокоуровневный, и если нет у вас не локальных заморочек с точки зрения того как работать с внешними\внутренними системами, то такой код, хотя бы в виде макета, должен уметь писать аналитик.
7. Тестирование
Для проверки работоспособности вашего приложения нужно собрать несколько бизнес-тест кейсов, которые покроют happy path как минимум, а лучше все ветки процесса. Под бизнес-тест кейсом я понимаю нормальные, боевые случаи прохождения процессов. Если у вас процесс «Заказ еды в офис», то кейс это «Заказ в 18:00 пятница, 3 больших пиццы «4сыра», оплата картой, адрес доставки — Зеленоград, к1220″.
Схемы не достаточно
BPMN-схема это только 30% от хорошего приложения, и работы по её превращению в приложение надо сделать достаточно. Зато BPMN это отличная «карта» для начала разработки, которая позволяет не забыть и не потерять важные элементы приложения.
Комментарии