Camunda modeler как работать

Camunda — что это такое?

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

Какое вам дело до Camunda

Camunda может очень сильно, в десятки раз (например если вы устали от «статусов»), снизить затраты на автоматизацию бизнес-процессов и\или оркестрацию микросервисов. Это достигается за счёт:

Пример бизнес-процесса в BPMN

Компоненты системы

Camunda — это набор приложений Modeler, Task List, BPMN Engine, DMN Engine, Cockpit, Admin,Optimize.

Архитектура приложений Camunda

Интерфейс camunda tasklist

Структура BPMN Engine

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

Как попробовать Camunda самому

Standalone вариант использования

2. Библиотека внутрь java-приложения — это значит, что вы указываете зависимости в своем приложении и работаете с camunda через Java API.

Embedded вариант использования

В этом видео можно посмотреть как сделать своё первое stand-alone приложение:

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

В итоге

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

Вы уже работаете с системой? Как вам? Расскажите в комментариях и поделитесь этой статьей в соц.сетях.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Camunda Modeler

Анатолий Опарин / август, 2018

Начало

Установка приложения. Зайти на страницу скачивания приложения (ссылка ниже). Выбрать нужную ОС и скачать. Распаковать ZIP-файл В новой папке на диске C. Запустить файл с расширением EXE. Следуя инструкциям установить Camunda Modeler. Создать ярлык на рабочем столе.
После установки приложение является по сути портабельным. Это значит, что папку с приложением можно перемещать в другое место на диске или устанавливать на другие компьютеры просто методом копирования этой папки без инсталляции.
Экспортировать работу можно в два растровых формата PNG и JPG, в векторный формат SVG, а также сохранять проект в родном xml-подобном формате BPMN.

Маленькие хитрости

Элемент действие по умолчанию не очень большой и текст даже среднего объема вместить в него красиво проблематично. Камунда не позволяет в визуальном интерфейсе менять размеры этого прямоугольника.

(Иметь в виду, что при последующей попытке перетащить эту текстовую аннотацию на другую позицию, Камунда поймет, что ее обманули, и снова прилепит аннотацию к валидному с ее точки зрения элементу)
(В свежей версии 2.2.4 этой проблемы уже нет)

У таких элементов как событие, поток операций и шлюзы есть параметр Name, который часто используется при создании диаграмм в качестве комментария к своему родительскому элементу. Но Камунда его крайне ограничивает по ширине и не позволяет в визуальном редакторе его изменять. Более того, если найти по ID и изменить width у этого элемента в XML-коде (как демонстрировалось выше), то Камунда на это никак не реагирует.

Ассоциацию можно провести между действием и базой данных только однонаправленной стрелкой, а хотелось бы изобразить обмен данными с БД двунаправленной стрелкой.

Невозможно закрасить элемент каким-нибудь цветом.

Ссылки

Конкуренты

ARIS Express. Бесплатный продукт. [Страница скачивания]. После инсталляции программы она будет работать только после того, как вы пройдете процедуру регистрации в сообществе ARIS и получите логин и пароль, которые надо будет ввести во время первого запуска программы. На общем диске «p:\Функциональные Папки\04 IT Департамент\50 Distrib\03 Util\for_BPMN\ARIS_Express\» лежит портабельная версия программы.

Bizagi Modeler. Бесплатный продукт. [Страница скачивания]. Без регистрации не дадут скачать и запустить после инсталляции. Здесь лежит скачанный после регистрации инсталлятор «p:\Функциональные Папки\04 IT Департамент\50 Distrib\03 Util\for_BPMN\».

Software Ideas Modeler. Платный продукт. [Страница скачивания] триальных версий. Понравился больше предыдущих двух. Работает быстрее, решает бо́льший спектр задач.

ELMA BPM. Платный отечественный продукт. [Описание продукта] на сайте производителя. Не скачивал для тестирования, но судя по скриншотам, отзывам, основательности сайта, это достойный и удобный продукт.

Grapholite. Платный редактор деловой графики. [Обзор и скачивание бесплатной портабельной версии]. Удобнейший редактор, который имеет богатый набор готовых элементов для моделирования BPMN схем. Работает без тормозов.

MyDraw. Платный редактор деловой графики. [Обзор и скачивание бесплатной портабельной версии]. Мощный редактор, который имеет очень богатый набор готовых элементов для моделирования BPMN схем. Работает без тормозов.

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

Источник

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

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

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

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

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

Делаем такой бизнес-процесс

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

Куда добавить bpmn файл в Camunda

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

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

Правила перехода на стрелке

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

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

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

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

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

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

Обращение к контекстной переменной в Camunda

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

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

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

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

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

Добавление полей на форму

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

Вот такая форма будет сгенерирована

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

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

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

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

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

Вывод

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Дорога к BPMN 2

В названии цифра «2» не из-за версии нотации (хотя она и так 2.0), а потому что это вторая статья. В первой я рассказывал про наш путь к Activiti и о том, почему от этого инструмента стоило отказаться и идти дальше. И сегодня я расскажу, куда же мы пошли.

Поскольку времени у нас было крайне мало, нам требовалось решение, на которое мы могли бы максимально просто мигрировать, не считая решения других недостатков Activiti, описанных в предыдущей статье.

New engine (Camunda vs. Flowable)

На данный момент существует два основных форка Activiti: Camunda и Flowable. Camunda — форк Activiti 5, а Flowable — форк Activiti 6.

Есть множество статей о достоинствах перехода на Camunda. Главными из них, как описывают сами авторы, являются полностью переписанные персистентный слой (улучшена система предотвращения дедлоков, подключаемый backend DRBMS, Cassandra, Hazelcast) и парсинг XML-схем. Вдобавок разработчики Camunda сосредоточились на поддержании стандарта BPMN. Также в этом фреймворке есть множество дополнительных энтерпрайз-инструментов, например, Cockpit.

Другой альтернативой для миграции с Activiti является Flowable. Поскольку это форк более поздней версии Activiti, он обладает и обновлённым движком. Подробнее можно почитать тут. Во Flowable (по сравнению с Activiti) переписано дерево вызовов, сделан подключаемый персистентный слой, а также расширена поддержка стандарта BPMN.

Авторы обоих форков в основном сравнивают свои проекты с Activiti, но официальных сравнений «в бою» форков между собой на момент выбора нами движка не было. Если у вас есть опыт подобного сравнения, прошу поделиться в комментариях. Наш выбор пал на Camunda из-за его большей распространённости (больше людей отлавливают в нём ошибки, а значит проект потенциально стабильнее), а также из-за «киллер-фичи» Cockpit, о которой подробнее расскажу ниже.

Activiti + Camunda

Просто остановить разработку бизнес-фич и заняться переводом всех существующих процессов на Camunda мы не могли, как и выбросить уже существующие и используемые клиентами процессы. Поэтому на переходной стадии миграции мы рассматривали одновременное использование обоих движков Activiti и Camunda. Мы не были уверены, что наши старые процессы во всех случаях будут работать так же, как на Activiti, а нам требовалось плавно преодолеть переходную стадию. Осложнялось всё тем, что внутреннее устройство движков сходно и они могли конфликтовать друг с другом. Например, в обоих движках использовались таблицы с одинаковыми наименованиями. Однако возможной причиной конфликта было то, что старые схемы выполнялись только в Activiti, а новые — только в Camunda, а значит не имели общих записей по запущенным процессам и сопровождающим их данным. Реализацией такой миграции занимался мой коллега @shabrak. Для корректного запуска требовалось сперва запускать Activiti и экземпляр liquibase, а затем Camunda и другой экземпляр liquibase. Но из-за избыточности такого решения мы отказались от него, хотя уже реализовали в коде.

Camunda

У Camunda есть две версии: Community и Enterprise. Первая в себя включает сам движок, инструмент для визуального редактирования BPMN-схем Camunda Modeler и Cockpit базовой версии. Enterprise-версия помимо полной версии Cockpit содержит в себе платформы Cawemo и Optimize. Cawemo — инструмент для спецификации BPMN с возможностью совместного редактирования.

Optimize — мощный инструмент мониторинга и анализа процессов, который позволяет строить heat-map исполнения процессов.

Также Enterprise-версия обеспечивается характерной для enterprise-продуктов круглосуточной поддержкой, консалтингом и т.д.

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

Нам потребовалось перевести BPMN-процессы Activiti на процессы Camunda. Код скриптов перенесли в делегаты Camunda и покрыли их тестами, как и весь процесс. Для отладки и отслеживания покрытия тестами использовали Camunda BPM Process Test Coverage, а для code review BPMN-схем мой коллега @rudykhнаписал плагин. Camunda мы используем в production уже два год и особенно рады инструменту Cockpit, значительно облегчившему нам анализ происходящего в сервисах.

Cockpit

Cockpit представляет из себя панель управления движком с веб-интерфейсом. В нём информативно представлена статистика по сервису. Инструмент позволяет «на лету» управлять процессами, меняя BPMN-схему прямо в интерфейсе, просматривать активные, завершённые или упавшие процессы, менять порядок исполнения разных схем или экземпляров процессов. Можно визуально наблюдать, на каком этапе находится конкретный процесс и что лежит в его контексте. Также Cockpit позволяет использовать самописные плагины, полностью настраивая его под свои потребности. Cockpit также существует в двух версиях: Community и Enterprise. Enterprise-версия имеет бо̒льшую функциональность, например, поддерживает перезапуск процессов группами, а не по одиночке, или аудит уже закончивших работу процессов. Сравнительную таблицу версий можно посмотреть здесь.

Подробнее о Cockpit и плагинах для него уже рассказал мой коллега.

Ложка дёгтя в Camunda

Об очистке истории нужно задумываться сразу при переходе на Camunda, потому что данные накапливаются слишком быстро, и в дальнейшем это может создать много проблем. Если изначально автоочистка не настроена, то, возможно, придётся столкнуться с ручной очисткой таблиц. Исторические и runtime-данные в таблицах в большинстве своём разделены. За исключением таблицы act_ge_bytearray, в которой все бинарные данные лежат вместе, и очистка её гораздо труднее.

Также есть проблема обработки асинхронных ответов: вызываемый нами сервис в одном таске отвечает раньше, чем движок дошёл до таска в стадии ожидания ответа. Исправить это можно повторной попыткой обработки асинхронного ответа.

Чтобы не натолкнуться на различные проблемы при переходе на Camunda, рекомендуется ознакомиться с Best Practices.

Вместо заключения

Существует мнение, что BPMN это инструмент уровня Drag&Drop, который просто «навязан сверху» с подачи «эффективных менеджеров». Мы и сами до поры до времени так думали, и движки бизнес-процессов с нотацией BPMN были для нас чем-то вроде «программирования мышкой». Однако в ходе работы нам потребовалась определённая функциональность для выстраивания бизнес-процесса и достижения стабильности его выполнения, а также мониторинга успешности работы сервиса и сбора аналитических данных. Мы начали изобретать свои решения, сделав несколько итераций, прежде чем получили что-то похожее на BPMN. В итоге решили воспользоваться уже готовым решением. Теперь наши процессы, а особенно сложная бизнес-логика формирования данных для конечного потребителя, стали прозрачными, поддерживаемыми и наглядными. Также мы можем отслеживать процессы «на лету» и получили эффективные механизмы перезапусков неуспешно отработавших бизнес-задач.

Источник

Внутренняя автоматизация – почему мы отказались от Bonita в пользу Camunda

Привет! Меня зовут Мирослав, я инженер-разработчик проекта по реализации BPM-решений для внутренней автоматизации КРОК.

Наш проект не гоняет миллионы строк каждую ночь через фильтры и правила, это не сложная система, которая отвечает за кадровую информацию, бюджетирование или сведение план-факта. Наш проект автоматизирует КРОК на самом понятном пользователю языке – их у нас сейчас более 2 000 сотрудников. Если есть рутинная задача, которую можно представить в BPMN, мы ее реализуем.

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

Теперь пользователь просто прописывает путь к папке, выбирает тип доступа (чтение/редактирование), оставляет при желании какой-нибудь увлекательный комментарий – и все, дальше все делает BPMN.

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

Каким мы хотели видеть BPMS

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

Тогда как раз набирала обороты глобальная трансформация КРОК (что это значит, в одном абзаце не объяснить, поэтому просто оставлю это здесь как факт). Бизнес повсеместно стремился к изменениям, и это, конечно же, влияло на нас. То, как было по-старому, работать перестало – нужны были гибкая разработка, регулярные демо, работа бок о бок с заказчиком на понятном ему языке.

Нашей идеальной системе предстояло усилить взаимодействие команды с заказчиками и ускорить процесс разработки. Для этого отлично подходили iBPMS, в которых, при нашем сценарии использования, ведущая роль разработки отводилась аналитику и автогенерируемому интерфейсу. Именно аналитик должен был проектировать BPM-схему, собирать модель данных и создавать страницы в UI-дизайнере. Разработчики, в свою очередь, должны были насытить BPM-схему логикой при помощи скриптов, а также развернуть окружение и наладить workflow внедрения новых бизнес-процессов.

Спустя пару месяцев наш выбор пал на Bonita, а в феврале 2019 года мне поручили ее внедрение на нашем проекте.

Опыт использования Bonita

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

Архитектура Bonita BPM

Как вы уже поняли из заголовка – Bonita нас все-таки не устроила. Далее я подробно опишу архитектуру решения, чтобы наглядно показать, почему в итоге наша команда от него отказалась.

Bonita Studio

С чем столкнулись

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

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

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

На деле UI-дизайнер оказался слишком негибким для того, чтобы отрисовывать на нем сложные формы. Аналитик мог «набросать» примерную схему страницы, но дальше на ее оживление разработчик тратил слишком много времени. И чем сложнее была страница, тем больше времени требовалось. А все дело было в том, что под капотом конструктора были примитивные и не расширяемые инструменты, а формируемые им страницы реализовывались на AngularJS.

Дальше мы старались писать фронтенд по старинке, при помощи Angular 2+, и налаживать взаимодействие с Bonita через REST API.

Bonita Portal

С чем столкнулись

Такое пространство – удобное решение, если нет необходимости его дорабатывать. У Bonita есть возможность кастомизировать портал при помощи архивов стилей, накатываемых прямо в Web. Мы легко перекрасили оформление и даже поменяли язык всего портала на русский. Но когда дело дошло до каких-то детальных изменений, не предусмотренных BonitaSoft, мы столкнулись с проблемой – для подобных доработок Bonita Portal не был приспособлен.

В Bonita Portal можно редактировать скрипты и параметры бизнес-процессов в runtime. Это достаточно мощное решение, с которым можно здесь и сейчас устранить проблемы пользователей, но в перспективе эта опция создает огромные проблемы и хаос в Production среде. И естественно с этими перспективами мы столкнулись лицом к лицу. Но это уже совсем другая история :D.

Bonita Runtime

К этой части вопросов почти не было. Движок требует настройки, документация не идеальна, но сам по себе он работает хорошо и REST API у него описан достаточно подробно.

Version Control

Это опция Bonita Studio, которая обеспечивает взаимодействие с Git-репозиториями. Не очень красивая, и на самом деле, совершенно необязательная, так как можно воспользоваться каким угодно иным инструментом для работы с Git. Но работает исправно 🙂

Bonita Storage

С чем столкнулись

После создания модель данных содержалась в xml-файле, который необходимо было заархивировать и развернуть в Bonita Portal.

XML-схема, которую генерит Bonita на основе business data model. Далее в соответствии с этой схемой будут созданы таблицы в БД

После деплоя архива с xml-схемой в BonitaPortal на ее основе создавались таблицы в заранее указанной базе данных. Выглядели они не совсем так, как нам хотелось. При этом в самой Bonita были ограничения по именованию объектов BDM. Все таблицы лежали в одной БД, хранить их иначе было невозможно. Для того, чтобы исключить пересечения именований, мы добавили префиксы, но в названиях таблиц (сущностей в модели данных) нельзя было использовать точки или нижние подчеркивания. В результате это были просто буквы, с которых начинались все названия сущностей.

Еще были сложности с изменением модели данных. Добавление нового столбца или изменение Nullable могло обернуться вынужденным сносом всех данных из таблицы – этого в проде мы допустить не могли.

Information systems

С чем столкнулись

Выводы

Bonita отлично подошла нам для создания простых бизнес-процессов: в некоторых случаях нам пригодился UI-дизайнер и даже генерация несложной модели данных. Но при создании нетривиальных, многомерных BPM-приложений такой подход начинал пробуксовывать, порождать костыли, а само приложение становилось неподъемным в плане поддержки и развития.

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

Более того, через несколько месяцев (в декабре) у нас заканчивалась лицензия BonitaSoft, что ставило нас в ситуацию с выбором – либо мы уходим на новый круг работы с системой, которая не оправдала наших ожиданий, либо отказываемся от нее здесь и сейчас и бросаем все силы на перевод существующих процессов. Конечно, мы решили рискнуть.

Поиск новой BPMS

В этот раз в выборе BPM системы участвовала большая часть проектной команды – все те, кто был причастен к разработке процессов на Bonita. Пропустив через этот опыт решения из прошлого исследования, выбрали трех финалистов – Bizagi, ELMA и Camunda.

Bizagi не устроила нас по цене, ELMA показалась слишком похожей на Bonita. У Camunda не было богатого набора инструментов iBPMS как у Bonita (но именно к ним у нас и было больше всего вопросов). Но зато у нее была Community-версия – что стало дополнительным аргументом «за». Нам хотелось быстро и безболезненно протестировать решение, и быстро отмести его, если вдруг что-то опять пойдет не так. В общем-то, по этой причине мы выбрали ее качестве объекта для исследования и внедрения в тестовой среде.

Новая BPM

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

Добавлю лишь немного лайфхаков.

Ссылка на git-репозиторий с огромным количеством тестовых проектов Camunda на любой вкус, которые помогут быстрому старту и поиску решений проблем, возникших при самостоятельном знакомстве.

Ссылка на telegram-канал русскоязычного сообщества Camunda, куда можно обратиться за помощью, когда документация и Google не смогли подсказать решение. Эти ребята не раз меня выручали в период знакомства с движком, за что им огромное спасибо 🙂

Наша основная проблема

Вероятных решений было два:

Интегрировать Camunda в нашу экосистему таким образом, чтобы рассинхрон стека как можно слабее повлиял на получаемый результат

Мы решили попробовать пойти по второму сценарию – и вот что из этого получилось.

Новая концепция взаимодействия с BPM

Spring Boot

Java-часть нашей BPMS выглядит так:

Здесь мы используем Spring Boot, в который как зависимость импортируем Camunda.

Бизнес-данные хранятся в БД, с помощью EF Core мы потребляем их в слой сервисов, где рассчитываем бизнес-логику и откуда обращаемся к Camunda REST API. Также у приложения есть формы на Angular для взаимодействия с пользователями и REST API для доступа к бизнес данным из Camunda и внешних систем.

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

Как теперь все устроено

За 8 месяцев мы исследовали и внедрили движок Camunda, а также мигрировали на него все бизнес-процессы, тем самым полностью отказавшись от Bonita BPM. Теперь у нас есть 3 отдельных Spring Boot приложения Camunda, под каждый бизнес-контур (Sales, HR и Production), самописный CROC BPM Portal, агрегирующий информацию о состоянии экземпляров процессов, и 4 бизнес-процесса, работающих в production-среде – вот таких:

– Выдача прав доступа

С него начался этот пост. Это инструмент, позволяющий автоматизировано получать права и доступ на файлы и папки КРОК.

– Обходной лист

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

– Согласование тендера

Мы упростили коммуникацию по согласованию участия в тендере и исключили из этого процесса электронную почту или мессенджеры. Теперь наши менеджеры используют автоматизированное приложение с продуманным WorkFlow.

– Пульс проекта

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

Считаю, что будет справедливо показать, как изменился процесс автоматизации с переходом от Bonita к Camunda – ниже опишу несколько ключевых моментов.

Bonita Studio => Camunda Modeler и Angular

За UI теперь отвечают SPA, написанные на Angular. Это решение можно назвать спорным, так как нет выигрыша в скорости разработки, но мы находимся в процессе поиска оптимального способа автоматизировать создание форм.

Bonita Portal => CROC BPM Portal

Интерфейс, который отвечает за отображение скоупа задач и экземпляров процессов – CROC BPM Portal – теперь тоже самописный. Благодаря этому мы можем оперативно отвечать на требования пользователей и гибко его развивать.

Task-модуль CROC BPM Portal на тесте

Bonita Runtime => Spring Boot и Camunda

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

Bonita Storage => EF Core

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

Information systems => Самописные сервисы

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

Почему BPM – это круто?

После прочтения этой статьи у вас может сложиться впечатление, будто мы отказались от всех преимуществ BPMS и переложили ответственность на самописный код. Но это не так.

Центр любой BPMS – это BPM-движок, и мы используем его по полной. Это удивительный инструмент, который действительно помогает ускорить разработку и повысить качество поставляемых решений. Фокус вовсе не в том, чтобы переложить ответственность на аналитика и автогенерацию. Основное преимущество в том, что BPMN – это исполняемая документация.

Аналитик согласовывает с заказчиком схему бизнес-процесса, передает её разработчику, и тот дальше вносит в нее технические изменения. Схема при этом всегда остаётся «живой» и может меняться в одном ритме с кодом. Такое поведение системы делает работу проектной команды целостнее и слаженнее, а связи с заказчиками – прочнее. Это именно то, чего мы добивались, начиная описанную мной историю.

Что дальше?

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

Буду рад узнать про ваш опыт использования BPMS, особенно, если вы используете подход, отличный от нашего. Приходите в комментарии, будет интересно пообщаться

Источник