Как мы BPM Camunda в свои проекты внедряли

Технологии
479
0
Дмитрий Егоров, ведущий программист департамента цифровых решений
В условиях, когда над бизнес-процессом работает не один человек, а целая группа специалистов разных профилей, разработчики неизменно сталкиваются с необходимостью стандартизированного ПО, которое бы позволило реализовать концепцию BPM. Для нашей команды фронт-разработчиков таким решением стала BPM Camunda. Как они ее внедрили в свои проекты — узнаете из данной статьи.



Определяемся с целями

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

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

Реализация бизнес-процесса включает его анализ на этапе написания технического задания, разработку согласно ТЗ, тестирование, документирование, сопровождение и возможные дальнейшие изменения. Все перечисленные действия могут выполняться различными группами аналитиков (не только специалистами в сфере) и разработчиков,  необязательно теми, кто первоначально реализовывал процессы. В таких условиях  возникает потребность в стандартизированном ПО, которое позволит реализовать концепцию и которое могли бы использовать все причастные к разработке группы лиц. Такой подход упростит и унифицирует реализацию и описание бизнес-процессов. Именно это и было нашей главной целью. 

Кратко о BPM Camunda

В качестве BPMS (Business Process Management System) решено было использовать java-фреймворк BPM Camunda (узнать о нем подробнее можно здесь: https://camunda.com). Преимущества данного сервиса заключаются в том, что он является open-source-платформой, то есть предоставляет возможность свободной доработки под наши требования, и является бесплатным. 

BPMS поддерживает стандарт BPMN (Business Process Model and Notation) — систему условных обозначений для описания и моделирования бизнес-процессов. 

Для создания схем бизнес-процессов предусмотрено приложение Camunda Modeler, поддерживающее стандарты BPMN (ознакомится с приложением можно здесь: https://camunda.com/download/modeler/). Схема процесса сохраняется в формате xml, именно эти данные использует фреймворк для управления процессом. С помощью утилиты bpmn-to-image можно настроить автоматическую конвертацию схем в изображения, что упрощает документирование проекта. 

Подробный список инструментов, предоставляемых BPM Camunda, можно посмотреть в описании фреймворка, мы же перечислим наиболее распространённые: 
  • Пользовательская задача — задача, связанная с человеком; 
  • Сервисная задача — используется для вызова задач, не связанных с человеком; 
  • Таймер — используется для временной задержки; 
  • Ожидания события — задача для ожидания определенного сообщения. 

Для хранения необходимой для какого-либо процесса информации (например, условий перехода при его ветвлении) предусмотрен так называемый контекст процесса — набор пар <имя_переменной>,<значение_переменной>. Значение переменной можно получить и установить, также можно удалить переменную. 

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

 


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

Внедрение BPM Camunda в наши проекты 

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

Библиотека bpm-support является своего рода оберткой над BPM Camunda. При её подключении продуктовый микросервис получает встроенный BPM-движок и предопределённый API для управления им. 

Camunda позволяет сохранить информацию о процессе как и in-memory, так и в БД. Нам нужна была история по процессам для анализа, а также предполагалось, что будут реализовываться длительные по времени процессы (выдача кредита, например), поэтому для хранения информации была выбрана БД. 

Также в bpm был разработан агрегатор, собирающий информацию о процессах микросервисов для формирования списков процессов по различным фильтрам (дата и время создания, статус и т.д.). Для большей гибкости имена интересующих микросервисов задаются в настройках. Микросервис bpm-presentation содержит инструменты для работы с процессами на фронтенд-компонентах разрабатываемых систем и предоставляет следующие возможности: 

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

В ходе внедрения мы столкнулись с необходимостью доработки сервиса под наши задачи. Вот что было сделано:
 
  1. Возникла необходимость контроля прав пользователя для завершения задачи. Для завершения разных задач надо иметь разные права. Поэтому, прежде чем как вызвать обработчик завершения задачи, производится проверка наличия у пользователя соответствующих прав. Также было добавлено свойство для пользовательской задачи, включающее наименование необходимого права. 
  2. Была выделена общая для процессов информация (сотрудник, инициировавший процесс, клиент, с которым работаем в данный момент, текущий владелец процесса и др.), которую требуется защитить от несанкционированного изменения. Данная информация была инкапсулирована в системные переменные, которые автоматически изменялись библиотекой bpm, у разработчика не было инструмента для того, чтобы менять их напрямую. В случае необходимости изменения конкретной переменной добавлялся метод для её модификации. Также была предусмотрена автоматическая передача данных переменных в вызываемый подпроцесс и возвращение в вызывающий. 
  3. В некоторых операциях может потребоваться контроль со стороны другого сотрудника. Иными словами, могут быть задачи, которые сотрудник не может завершить, даже имея для этого формальное право, до того момента, пока ее не завершит контролер. Чтобы реализовать такую возможность, было добавлено свойство, запрещающее инициатору процесса завершать задачу. Данное свойство проверяет не только права, но и табельный номер сотрудника, пытающегося завершить задачу. После завершения задачи контроллером она может быть возвращена на инициатора. Изменение системной переменной о владельце процесса происходит автоматически. 
  4. Добавлена возможность переназначить задачу на другого сотрудника. Так как информация о владельце процесса была вынесена в системные переменные и инкапсулирована от несанкционированного изменения, то потребовалась предоставить API переназначение задачи на сотрудника, то есть фактического изменения владельца процесса. При переназначении задачи также происходит контроль прав пользователя (взять задачу можно только при наличии необходимых прав). 
  5. В определенный момент возникла необходимость логирования завершения задач с записью параметров операции в системный журнал. Для решения данной проблемы модель запроса на завершение задачи создается с помощью нашей библиотеки swagger, которая генерирует не только саму модель, но и форматтер для представления модели в виде строки со значениями полей. Bpm-support при завершении задачи использует форматтер для формирования записи в системный журнал. Таким образом, мы можем отследить действия сотрудника. 
  6. Добавлена возможность возвращения на определенную страницу по завершении процесса. В ряде случаев было необходимо, чтобы после завершения процесса осуществлялся возврат на страницу, с которой были инициирована операция. Для этого было добавлено соответствующее свойство в bpm-presentation. 
  7. Разработана библиотека для упрощения написания юнит-тестов (в первую очередь для проверки корректности условия перехода по различным веткам). Доработанный таким образом инструментарий в целом удовлетворяет нашим требованиям.
Доработанный таким образом инструментарий в целом удовлетворяет нашим требованиям.

Пример реализации процесса 

Продемонстрируем, как все это работает, на примере реализации обработчиков для процесса, описанного в пункте 2 предыдущего раздела. 
 
  1. Подключаем библиотеку в микросервис (МС) с помощью аннотации в конфигурации МС: 



  2. Определяем обработчик пользовательской задачи для заполнения признака перехода по таймеру и его реализацию:



  3. Определяем сервисную задачу для заполнения переменной со значением временной задержки и её реализацию



  4. Реализуем маппинг переменных для подпроцесса: 



  5. Устанавливаем условие перехода: 



  6. Задаем значение задержки для таймера из переменной, установленной в сервисной задаче: 



  7. Пишем юнит-тест для проверки корректности перехода: 



  8. Пишем интеграционный тест: 



Таким образом, мы реализовали довольно простой процесс и тесты для него. 

Что в итоге? 

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

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

Дополнительно были выработаны следующие рекомендации: 

  1. По возможности, в контексте сохранять только информацию, необходимую для переходов по веткам процессов. 
  2. В пользовательских задачах только валидировать и сохранять данные, избегать взаимодействия с внешними системами. 
  3. При взаимодействии с внешними системами сохранять в БД текущее состояние процесса (по умолчанию это делается перед пользовательскими задачами). 
  4. При реализации продолжительных по времени процессов учитывать, что могут оставаться процессы со старыми схемами.


Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2016 2017 2018 2019 2020 2022