Первый проект на Camunda: создание и запуск бизнес-процесса

В этой статье рассмотрим, как нарисовать и запустить первый бизнес-процесс в камунде. Рассматривать будем наивный, неэффективный способ это сделать. Так же затрону важный момент процессных приложений — контекст. Видео-версия внутри.

Видео-версия

1. Бизнес-процесс

Будем делать бизнес-процесс командировок. Вот он:

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

Обратите внимание на папку META-INF и файл processes.xml — они нужны, чтобы камунда подхватывала ваши файлы. Создайте их.

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

Это выражение открывает нам важную тему для автоматизации процессов — контекст.

Что такое контекст в Camunda

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

BPMN не предоставляет средств моделирования контекста, и каждая BPMS-система предлагает какие-то свои варианты её описания.

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

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

Обращение к контекстной переменной осуществяется по её имени.

Таким образом необходимость принимать решения на развилках бизнес-процессов приводит к необходимости сохранить данные для этого решения.

Модель данных процесса

Чтобы успешно улететь в командировку, человек должен указать:

• Откуда лететь
• Куда лететь
• Когда лететь туда
• Когда лететь обратно
• Почему надо лететь
• Кто полетит
• Какая стоимость командировки будет

Добавим такие поля на форму первой задачи:

Добавление полей на форму одновременно добавляет их и в контекст, так что они становятся доступны другим квадратикам и развилкам.

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

В задачу согласования заявки надо добавить результат согласования и комментарий, в задачу покупки билетов — результат покупки билетов, описание заброннированого отеля и самолёта, комментарий к задаче. В задачах исправления заявки — комментарии от пред. сотрудников.

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

Результат и что с ним не так

Такой наивный способ сделать (кстати вот исходники) процесс приводит к убогим результатам:

• Страшные формы — без валидации, без ограничения на чтение\запись, без подсказок и справочников.
• Сотрудники не определяются автоматически, людям могут делать чужие задачи.
• Нет уведомлений о новых задачах (это встроенное поведение camunda).
• Нет отмены заявок.
• Нет аналитики.
• Если мы захотим обработку заявок на командировку превратить в несколько процессов, то нам прийдется перекидывать кучу полей между процессами.
• Одни и теже атрибуты приходится прокидывать на каждую форму. При добавлении нового нужно пройти по всем задачам и проделать это упражнение.

Вывод 

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