Визуальный конструктор бизнес-логики на основе Camunda BPM

Привет! Меня зовут Олег Гетманский, я – старший архитектор информационных систем. Сегодня расскажу, как мы упростили создание и управление бизнес-процесссами в IdM, оставив в прошлом жестко зашитые в систему правила и внедрив гибкий визуальный конструктор бизнес-логики Camunda BPM. Под катом краткое руководство по внедрению движка с моими комментариями – возможно, для кого-то оно сэкономит несколько рабочих часов или даже дней.

Автоматизация в IdM

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

С точки зрения разработчика самое сложное в системах класса IdM – это требование абсолютной кастомизируемости: заказчики считают, что в IdM все должно быть настраиваемо. Приведу несколько примеров из жизни:

• Есть стандартная логика бизнес-процесса: IdM автоматически создает учетную запись для сотрудника при приеме на работу и блокирует УЗ и связанные с ней права при увольнении. Написали код, протестировали, выпустили фичу – все работает. Но у заказчика есть такое понятие, как перевод через увольнение, и теперь наша фича ломает этот выстроенный процесс перевода – IdM воспринимает его как просто прием на работу и создает новую учетную запись, а она сотруднику не нужна. Здесь важно, чтобы осталась прежняя учетка, и, уж тем более, чтобы она не заблокировалась.

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

• IdM автоматически назначает базовые роли новым пользователям. Внезапно найдутся «не такие как все» VIP-пользователи, которым нужно назначать роли в обход регламента – по разным алгоритмам в разных организациях.

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

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

Как можно решить эту проблему? Мы пробовали разные варианты:

1. Inline feature flags. Создаём множество параметров конфигурации и прямо в коде бизнес-логики пишем, как нужно поступать в том или ином случае, в зависимости от этих параметров. В отдельном интерфейсе можно включить те или иные флажки. Идея не взлетела, потому что мы все равно не знаем, какие фича-флаги понадобятся в будущем. К тому же чем больше в коде фича-флагов, тем дороже выходит реализация очередного такого флажка.

2. Заскриптованная бизнес-логика. Оставить в стабильной ветке лишь общий workflow и архитектурный «каркас» в виде доступных сервисов и API, предоставив командам внедрения возможность самостоятельно закодировать специфичную для заказчика бизнес-логику. В таком случае объектом поставки является комбинация из стандартного продукта и множества скриптовых конструкций (в нашем случае это скрипты на языке Groovy). Кастомизировать и настраивать в такой модели можно практически всё, что угодно, однако при написании скрипта легко поломать то, что работало раньше. К тому же на практике оказалось довольно сложно поддерживать обратную совместимость для старых скриптов в новых версиях продукта.

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

BPM-движок в основе бизнес-логики

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

Если посмотреть на IdM как на систему, автоматизирующую бизнес-процессы, то получается, что:

• Можно выделить контекстно-независимые компоненты для проведения атомарных операций (создать аккаунт, назначить роль, отправить уведомление). Эти компоненты простые, они очень редко изменяются, и их можно переиспользовать. В своей системе мы иногда создаем новые компоненты, когда нужна новая функциональность.

• Задача располагает к выстраиванию событийно-ориентированной архитектуры. При различных действиях (автоматических или пользовательских) порождаются события. В ответ на различные события происходят автоматические действия, определяемые бизнес-процессами организации («Новый пользователь? Создать доменный аккаунт», «Сотрудник ушел в отпуск? Временно заблокировать аккаунт», и много другого, что может потребоваться в отдельно взятой организации). Любую автоматику можно представить как последовательность простых шагов.

• Максимальная гибкость настройки требуется именно на уровне принятия решений. Это не касается компонентов, выполняющих атомарные операции. Очень редко нужно изменять реализацию конкретных операций, и наоборот — очень часто мы будем изменять алгоритмы принятия решений – то есть добавлять условия на выполнение тех или иных операций, менять их последовательность, убирать из процессов ненужные шаги и добавлять нужные.

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

В качестве BPM-системы мы выбрали Camunda v.7 – это open-source движок, его можно встроить в Java-приложение, он хорошо интегрируется со Spring. Есть визуальный редактор Camunda Modeller, в котором можно рисовать бизнес-процессы (БП). Сами БП у нас будут в формате BPMN (Business Process Management Notation).

Ниже под спойлером будет немного кода в технологическом стеке Java 17 + Maven + Spring Framework + Hibernate.

Компоненты атомарных операций

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

// Все атомарные компоненты называются по шаблону [Область применения]Ops  // Так проще отличить их от любых других компонентов  @Component  public class RoleOps {  // Компоненты полагаются на другие готовые сервисы из инфраструктуры системы      @Autowired      protected RoleService roleService;        @Autowired      protected UserRepository userRepository;        // Методы принимают и возвращают простые типы      /**       * Назначить роль на пользователя       * @param roleId id роли       * @param userId id пользователя       * @return id назначения       */      public String assignRoleToUser(String roleId, String userId) {          var role = roleService.getRole(roleId);          var user = userRepository.getUser(userId);          return roleService.createAssignment(role, user).getId();      }        /**       * Отозвать назначение       * @param assignmentId Id назначения       */      public void removeAssignment(String assignmentId) {          roleService.removeAssignment(assignmentId);      }  }

Теперь мы можем вызывать компонент RoleOps в скриптовом обработчике Camunda:

roleOps.assignRoleToUser("id-role-admin", userId)

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

Интегрируем Camunda в проект

Создаем новый Maven проект, добавляем зависимости на Camunda, Spring и сервисы инфраструктуры IdM:

<!-- Camunda, Spring --> <dependency>     <groupId>org.camunda.bpm</groupId>     <artifactId>camunda-engine</artifactId> </dependency> <dependency>     <groupId>org.camunda.bpm</groupId>     <artifactId>camunda-engine-spring</artifactId> </dependency> <dependency>     <groupId>org.springframework</groupId>     <artifactId>spring-context</artifactId> </dependency> <!-- Инфраструктура IdM --> <dependency>     <groupId>ru.solarsecurity.inRights.model</groupId>     <artifactId>model-common</artifactId>     <scope>provided</scope> </dependency>

В нашем случае мы создаем отдельный Maven-модуль, который живет в составе проекта, однако можно сделать отдельный BPM-микросервис. Сегодня это даже предпочтительно: принятие решений – отдельно, исполнители – отдельно.

Создаем конфигурацию Camunda:

@Configuration public class BpmBeanConfiguration {      @Qualifier("transactionManager")     @Autowired     protected PlatformTransactionManager transactionManager;      @Bean     public SpringProcessEngineConfiguration engineConfiguration(DataSource dataSource) {         SpringProcessEngineConfiguration cfg = new SpringProcessEngineConfiguration();         cfg.setProcessEngineName("engine");                  // Используем стандартные dataSource и transactionManager из проекта         // Camunda будет использовать ту же БД, что и остальная система         cfg.setDataSource(dataSource);         cfg.setDatabaseSchemaUpdate("true");         cfg.setTransactionManager(transactionManager);         cfg.setScriptEngineResolver(new DefaultScriptEngineResolver(new ScriptEngineManager()));         cfg.setInitializeTelemetry(false); // Отключаем телеметрию Camunda                return cfg;     }      @Bean     public ProcessEngineFactoryBean engineFactory(SpringProcessEngineConfiguration engineConfiguration) {         ProcessEngineFactoryBean factoryBean = new ProcessEngineFactoryBean();         factoryBean.setProcessEngineConfiguration(engineConfiguration);         return factoryBean;     } }

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

В нашей IdM бизнес-процессы будут стартовать по сигналу, где сигнал – это какое-либо пользовательское действие или внешнее событие.

Все сигналы наследуются от нашего интерфейса CamundaSignal:

public interface CamundaSignal extends Serializable {     String getSignalName(); }

Для Camunda важно, чтобы сигналы были сериализуемыми и имели название.

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

public record UserCreatedEvent( String id,     String login,     String name,     Map<String, Serializable> attributes ) implements CamundaSignal {     @Override     public String getSignalName() {         return "userCreated";     } }

Создаем сервис для запуска бизнес-процессов по сигналам. Поскольку запуск БП и выполнение всех его шагов – это дорогостоящая операция, то лучше не блокировать поток обработки пользовательских запросов и сделать запуск БП асинхронным. Мы отправляем сигналы для Camunda в отдельном ThreadPoolExecutor:

@Component public class CamundaSignalService {      @Autowired     protected RuntimeService runtimeService;      // 128 потоков выполнения БП по умолчанию.     // Так много, потому что внутри них IdM занята в основном ожиданием I/O:     //  обращения к СУБД, запросы к внешним системам, отправка уведомлений     @Value("${inRights.camunda.threadPoolSize:128}")     protected int threadPoolSize;      protected ThreadPoolExecutor singalSubmitterThreadExecutor;      @PostConstruct     protected void init() {         var threadFactory = new CustomizableThreadFactory();         threadFactory.setDaemon(true);         threadFactory.setThreadNamePrefix("camunda-signal-thread-");          singalSubmitterThreadExecutor = new ThreadPoolExecutor(             threadPoolSize, threadPoolSize, 60, TimeUnit.SECONDS,             new LinkedBlockingQueue<>(Integer.MAX_VALUE), threadFactory         );     }      /**      * Отправить сигнал в Camunda. Это запустит БП, которые должны отреагировать на данный сигнал.      * @param camundaSignal сигнал      */     public void sendSignal(CamundaSignal camundaSignal) {         singalSubmitterThreadExecutor.execute(() ->             runtimeService.createSignalEvent(camundaSignal.getSignalName())                 .setVariables(Map.of("signal", camundaSignal))                 .send()         );     } }

Теперь отправляем сигналы в Camunda там, где возникают соответствующие события в системе:

// В БД сохранен новый пользователь userRepository.save(user); // Сообщаем об этом Camunda camundaSignalService.sendSignal(new UserCreatedEvent(user.getId(), user.getLogin(), user.getName(), user.getAttributes()));

Далее — разворачиваем в Camunda наш стандартный БП, чтобы наполнить уже движок каким-нибудь полезным функционалом. В идеале мы хотим сделать отдельную административную web-страничку для управления бизнес-процессами – разворачивать новые БП, скачивать / включать / выключать существующие. Интерфейсы Camunda для этого не подходят, поэтому создадим свой простой репозиторий сущностей БП.

Сущность бизнес-процесса имеет название, случайный id как UUID, флаг развернут / не развернут, и контент в формате BPMN:

@Entity @Table(name = "bpm_process") public class BusinessProcessEntity {      @GeneratedValue(generator = "custom-generator", strategy = GenerationType.IDENTITY)     @GenericGenerator(name = "custom-generator", strategy = UuidGenerator.STRATEGY_NAME)     @Id     protected String uuid;      @Column     protected String name;      @Column     protected boolean deployed;      @Version     @Column     protected Integer version;      @Column     protected byte[] content;      // getters, setters }

Репозиторий для сущностей БП:

public interface BusinessProcessRepository extends CrudRepository<BusinessProcessEntity, String> {     Optional<BusinessProcessEntity> findByName(String name); }

BusinessProcessDeploymentService отвечает за фактическое соответствие сущностей BusinessProcessEntity реальному состоянию БП в Camunda BPM. С помощью него и только него мы будем управлять БП на инсталляциях нашей IdM:

@Component  public class BusinessProcessDeploymentService {        @Autowired      protected BusinessProcessRepository bpRepo;        @Autowired      protected RepositoryService camundaRepo;        /**       * Активировать БП в Camunda BPM       */      @Transactional      public void deploy(BusinessProcessEntity bp) {          bp.setDeployed(true);          bpRepo.save(bp);          deleteDeployments(bp.getName()); // Удаляем старую версию деплоймента          camundaRepo.createDeployment()   // Создаем новый деплоймент              .source(bp.getName())              .addInputStream(bp.getName(), new ByteArrayInputStream(bp.getContent()))              .deploy();      }        /**       * Деактивировать БП в Camunda BPM       */      @Transactional      public void undeploy(BusinessProcessEntity bp) {          bp.setDeployed(false);          bpRepo.save(bp);          deleteDeployments(bp.getName());      }        protected void deleteDeployments(String deploymentSource) {          camundaRepo.createDeploymentQuery().deploymentSource(deploymentSource).list().stream()              .map(Deployment::getId)              .forEach(camundaRepo::deleteDeployment);      }  }

Установка флага deployed = true и деплоймент в Camunda происходят в одной транзакции, поэтому если в процессе деплоя что-то пойдет не так, то сущность BusinessProcessEntity не будет считаться активным процессом.

Для краткости я пропущу написание REST-контроллера и детали реализации фронтенда.

Итоговый вид административной странички управления БП:

Бизнес-процессы разворачиваются в Camunda сразу после загрузки файла. Если снять флажок «Активен» с бизнес-процесса, то деплоймент будет удален из Camunda, но сама сущность BusinessProcessEntity останется в таблице. Так можно включать и отключать БП, не удаляя их из системы. Если загрузить БП с именем, которое уже есть в таблице, тогда старая версия БП будет обновлена в Camunda.

Пишем простой бизнес-процесс

Для составления БП будем использовать редактор Camunda Modeller. Создаем новый файл в формате BPMN diagram (Camunda Platform 7).

Добавляем сигнал начала процесса — userCreatedEvent (как написано в коде: UserCreatedEvent#getSignalName). Добавляем в процесс шаги типа Script Task. Внутри шагов — скриптовые выражения, вызывающие методы атомарных компонентов. В результате получится примерно так:

Сохраняем файл bpmn, загружаем в IdM и таким образом реализуем то, что нужно организации.

Итак, составляя BPMN, можно быстро набросать работающую фичу по желаниям заказчика, возможно, даже сидя вместе с ним за одним столом. Нужно сделать перевод через увольнение? Отлично, только расскажите, с чего оно начинается, и что IdM должна при этом сделать. Если известны стартовые события и правила формирования атрибутов учетных записей, то поддержать множественные доменные аккаунты также будет довольно просто.

В целом, чем больше атомарных бинов, которые можно использовать в БП, – тем более функциональные процессы можно строить в визуальном редакторе.

Теперь мы можем выстроить такой процесс реализации новых фич:

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

2. Превращаем схему в валидную BPMN-диаграмму.

3. Наполняем диаграмму обращениями к атомарным компонентам через скриптовые выражения.

4. Реализуем в IdM новые сигналы (события, запросы) и атомарные компоненты, если существующих недостаточно.

5. Получаем рабочий бизнес-процесс в виде файла с расширением bpmn, проверяем работоспособность.

6. Устанавливаем готовый bpmn у заказчика.

Готовый БП – это легковесный переносимый артефакт. Файлы bpmn можно копировать, изменять, можно положить их в систему контроля версий и использовать как основу для других кастомных БП.

В заключение

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

Плюсы этого решения:

• Это «микросервисно»! Модуль BPM взаимодействует с остальной системой посредством обмена сигналами и событиями, это позволяет выделить его в отдельный микросервис. Инфраструктура исполнения команд, поступающих от BPM, может быть масштабирована отдельно.

• Поощряет написание простого кода. BPMN-диаграммы будут простые и понятные, если таковыми будут атомарные компоненты, которые их поддерживают. Желательно, чтобы Ops-бины принимали и возвращали простые типы данных: строки, числа, enum, record.

• Наглядность. Бизнес-логика в BPMN отображена визуально. Не требуется умение программировать, чтобы понимать диаграммы бизнес-процессов.

• Изменения on-the-fly. Для изменения бизнес-логики на конкретной инсталляции достаточно только загрузить новый файл bpmn.

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

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

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

• Тяжеловесность. BPM-движок усложняет систему как минимум одним своим присутствием. Поэтому если ваша предметная область достаточно предсказуема, и вы можете сохранить гибкость вашего продукта просто посредством написания качественного кода, тогда вам не нужен BPM.

• Нужно знать нотацию. Для того, чтобы грамотно составлять бизнес-процессы, кто-то в команде должен изучить нотацию BPMN 2.0.

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

• Обязательное протоколирование. Довольно сложно проводить отладку кода бизнес-логики, когда он заключен в BPMN-диаграммы. Крайне желательно делать так, чтобы любое совершенное действие было зафиксировано в файлах логов или в журнале событий, или в системе аудита. По этим данным позже можно будет отследить, почему движок BPM принял то или иное решение на конкретном шаге. Без подробного протоколирования бизнес-процессы – это черный ящик.