В названии цифра «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. В итоге решили воспользоваться уже готовым решением. Теперь наши процессы, а особенно сложная бизнес-логика формирования данных для конечного потребителя, стали прозрачными, поддерживаемыми и наглядными. Также мы можем отслеживать процессы «на лету» и получили эффективные механизмы перезапусков неуспешно отработавших бизнес-задач.