BPM-разработка — дело непростое. Это обусловлено тем, что процесс должен быть читаемым и понятным заказчику, а не только корректным с технической точки зрения.
Не все средства разработки бизнес-процессов позволяют найти компромисс между понятным описанием и технической функциональностью. Многие продвинутые средства разработки и описания процессов часто имеют еще один недостаток: они настолько крутые, мощные и сложные, что, пока их делали, технологии сильно шагнули вперед и разработка таким инструментом стала неактуальной.
2018 год принципиально изменил наш подход к разработке бизнес-процессов. Ниже — о том, как эволюционировал этот подход и как менялись мы.
Вместо пролога
Наш отдел занимается разработкой бизнес-процессов — начиная от самых маленьких и незначительных, заканчивая крупными и крайне прибыльными. До последнего времени для разработки мы использовали продукт от IBM, который позволяет достаточно быстро выпустить в продакшен работающий бизнес-процесс.
IBM BPM — мощная платформа, которая включает богатый набор возможностей, таких как описание самих процессов, UI-форм, интеграционных модулей. К тому же эта платформа имеет довольно низкий порог входа, что позволяет начинающим разработчикам практически сразу погружаться в проект. Но есть у этого продукта и недостатки, которые если и не тормозят разработку, то уж точно не способствуют скорости и качеству:
- Нет вменяемого контроля версий. IBM BPM просто не дает возможности нормально хранить процессы (код) в репозитории и использует свое собственное хранилище, которое не знает о таком понятии, как merge, например.
- Разработка на Java 6. Возможно, на момент написания этой статьи уже можно разрабатывать на Java 7, но в 2019 году это слабое утешение.
- IBM BPM крутится на WebSphere, в итоге разработчикам надо запасаться терпением при каждом обновлении своего модуля. К тому же это дополнительная головная боль для админов, которым периодически приходится возвращать к жизни этого монстра в случае его зависания.
- Разработка интеграционных модулей в среде Integration Designer, которая в действительности является затюненным не в лучшую сторону Eclipse.
- Нет нормальной возможности Unit-тестирования.
- Высокая стоимость платформы.
Эти недостатки кроме чисто технического неудобства разработки породили еще одну проблему, которая, возможно, гораздо серьезнее всех вышеперечисленных. Во времена Java 12, Kotlin, микросервисов и прочих модных трендов и штук все эти нюансы очень демотивируют команду. Трудно испытывать радость при разработке в постоянно виснущем Integration Designer на Java 6 в 2019 году.
Со всеми этими ограничениями трудно находиться на плаву. Чуть менее года назад поступило предложение попробовать движок Camunda для описания бизнес-процессов. Для начала был выбран не очень большой, но достаточно важный процесс по регистрации терминалов для юрлиц.
Так как его мы переписывали полностью, старого кода почти не было, мы могли практически ни в чем себя не ограничивать и поэтому в качестве языка разработки выбрали Kotlin. Было интересно попробовать этот новый язык, о котором слышали по большей части положительные отзывы. На некоторых других проектах в нашем отделе был успешный опыт внедрения. Финальный стек получился таким: Camunda, Spring Boot 2, Kotlin, Postgre.
Что это такое Camunda?
Camunda — это open-source-платформа для моделирования бизнес-процессов, которая написана на Java и в качестве языка разработки использует Java. Она представляет собой набор библиотек, которые и позволяют выполнять описанные процессы. Для интеграции Camunda в проект достаточно добавить несколько зависимостей. Для хранения процессов можно выбрать in-memory или персистентную СУБД — в зависимости от задач. Мы выбрали Postgre, так как нам важна история для «разбора полетов». По умолчанию платформа разворачивается на H2.
Разработка состоит из двух частей: создание flow-процесса в специальной утилите Camunda Modeler и написание java-кода, который обрабатывает шаги процесса, описанные на диаграмме. Чтобы из процесса вызвать java-код, достаточно реализовать интерфейс JavaDelegate, поднять этот Bean (можно указать делагат по полному имени, но через Bean удобнее и гибче) в контексте и указать его id на нужном шаге процесса. На Kotlin делегат выглядит еще более лаконично. Логика работы делегатов довольно проста: что-то вычитали из контекста, выполнили какие-то действия и положили обратно в контекст.
Рабочее окно Camunda Modeler
Пример делегата на Java:
import org.camunda.bpm.engine.delegate.DelegateExecution;
import org.camunda.bpm.engine.delegate.JavaDelegate;
public class JavaExampleDelegate implements JavaDelegate {
@Override
public void execute(DelegateExecution execution) {
String someVar = (String) execution.getVariable("someVariable");
// some actions
execution.setVariable("otherVariable", "otherValue");
}
}
Пример делегата на Kotlin:
import org.camunda.bpm.engine.delegate.DelegateExecution
import org.camunda.bpm.engine.delegate.JavaDelegate
class KotlinExampleDelegate: JavaDelegate {
override fun execute(execution: DelegateExecution) {
val someVar = execution.getVariable("someVariable")
//some code
execution.setVariable("otherVariable", "someValue")
}
}
В делегате можно описывать бизнес-логику, интеграции и всё, что душе угодно.
Мы стараемся создавать прослойку в виде бизнесового компонента с логикой, а сам делегат использовать только как связующее звено с flow процесса, чтобы как можно меньше смешивать код и процесс.
В большинстве случаев этот подход удобен и работает успешно. Взаимодействие с процессом происходит через DelegateExecution, который позволяет, например, работать с контекстом, инцидентами и так далее.
Это то, чего мы хотели?
В самом начале, при выборе инструмента, мы искали решение со следующими возможностями:
- Восстановление процесса ровно с того места, где произошел сбой, и желательно, чтобы это было из коробки.
- Некоторый GUI, где можно посмотреть, что вообще с процессом происходит.
- Возможность написания юнит-тестов не только на логику и интеграцию, но и на сам процесс.
- Java 8 и выше.
- Развитое сообщество.
С возможностью восстановления и анализа ошибок у Camunda все отлично.
Хорошо читаемый трейс, возможность задания числа попыток выполнить шаг перед падением, кастомный обработчик при падении — например, если при падении мы хотим поменять статус некоторой сущности на Error. Последнее сделать достаточно легко, просто реализовав DefaultIncidentHandler. Правда, есть забавный момент при работе этого обработчика: код восстановления из ошибки срабатывает при каждом заходе на шаг процесса. Не могу сказать, что это — супербаг или проблема. Скорее, об этом нужно просто помнить и учитывать при разработке.
Мы решили это примерно так:
override fun resolveIncident(context: IncidentContext) {
val incidentList = Context.getCommandContext().incidentManager.findIncidentByConfiguration(context.configuration)
if (incidentList.isNotEmpty()) {
// некоторый код при восстановлении инцидента
}
}
GUI у Camunda есть, и он неплохой.
Но если хочется чуть больше, например миграцию инстансов между версиями процессов, то уже придется потрудиться. В дефолтном UI только минимальный функционал, зато есть очень мощный Rest API, который позволяет создать свою админку — крутую и навороченную.
Именно по пути своей админки мы пошли. Наш архитектор бизнес-процессов в довольно короткий срок ее запилил, включив туда функции просмотра истории по уже завершенным процессам, миграции между версиями и так далее.
Rest у Camunda действительно мощный и позволяет творить с процессами практически что угодно. Например, стартовать процесс можно по /process-definition/key/aProcessDefinitionKey/start таким нехитрым запросом:
{
"variables": {
"aVariable" : {
"value" : "aStringValue",
"type": "String"
},
"anotherVariable" : {
"value" : true,
"type": "Boolean"
}
},
"businessKey" : "myBusinessKey"
}
Пример взят из официальной документации, которая содержит обширное описание различных кейсов использования этого API.
Для юнит-тестирования мы используем обычный Junit. Плюс есть довольно интересная библиотека для тестирования самого процесса — 'org.camunda.bpm.extension', name: 'camunda-bpm-assert'. С ее помощью можно описывать тесты для проверки flow-процесса.
Это довольно удобно, так как искать проблемы в случае багов во flow зачастую сложнее, чем в коде. Такое тестирование защищает, например, от неаккуратного рефакторинга и несколько раз действительно нас выручало.
Необходимость в Java 8 частично отпала, так как использование Kotlin на многих процессах устранило потребность в «восьмерке». Kotlin очень хорошо вписался в проект и позволил сосредоточиться только на написании бизнес-логики. Трудно поверить, но в основном всё то, что говорят о крутости Kotlin, — правда. Сущности с большим числом полей, которыми славятся практически все приложения с интеграциями, теперь выглядят не так страшно, и маппинги между сущностями стали гораздо более читабельными. Часто критикуемое null safety действительно работает и выручает в большинстве случаев.
Community у Camunda достаточно развитое. Об этом говорит тот факт, что постоянно появляются новые библиотеки на GitHub для тестирования и метрик.
Приятно, что Camunda отлично интегрируется со Spring. Добавить необходимых зависимостей, пару аннотаций и пару конфигурационных бинов — собственно, вот и вся интеграция! В результате мы пишем обычное spring-приложение, к которому все привыкли, добавляя flow бизнес-процесса. Взаимодействие происходит через Java API, которое позволяет выполнять манипуляции с процессами из java-кода.
Например, запустить процесс можно всего одной командой:
runtimeService.startProcessInstanceByKey(
"MyTestProcess",
"MyBusinessKey",
mapOf(
"key1" to "value1",
"key2" to "value2",
)
)
Здесь MyTestProcess — Id-шник процесса, а не инстанса. MyBusinessKey — уникальный ключ для запускаемого инстанса процесса. Мы обычно используем для этого поля некое бизнесовое значение — для более быстрой навигации между инстансами и поиском.
Примерно таким же образом можно разбудить «заснувший» процесс.
Заметных минусов или каких-то проблем, с которыми мы столкнулись, особо вспомнить не получается. В итоге за довольно короткий промежуток времени получилось сделать вполне рабочий процесс и благополучно вывести его в продакшен. На платформе внедряются другие процессы и вполне успешно. Сейчас на Camunda у нас запущено около 15 приложений, на которых единовременно крутится около 100 тысяч процессов.
Вместо эпилога
Вот несколько ресурсов, которые были полезны при внедрении описанного выше стека. Рекомендую ознакомиться с ними, если интересна дополнительная информация по теме.
- Camunda хорошо документирована — большинство нужных кейсов мы нашли в официальной документации.
- Более детально про платформу, интересные кейсы и вообще про bpm можно посмотреть на этом канале. Его ведет наш коллега, который и предложил использовать Camunda.
- Хороший доклад от Павла Финкельштейна про внедрение Kotlin.
Комментарии (25)
formatko
24.06.2019 13:211. Были случаи когда необходимо сделать точно такое же, что уже реализовано (схема с шагами), но некий порядок другой?
2. Сложно ли вообще рефакторить схемы, по сравнению с рефаторингом обычного кода?
3. Можно ли одновременно разрабатывать схему? Применяется ли практика деления на подпроцессы?
4. Есть ли проблемы при моделировании, например, есть в инструменте отладчик того что бы что то где то не правильно подключил в схеме?
5. Пользуются ли аналитики/менеджеры разработанными схемами? Могут что то подправить?
nshipyakov Автор
24.06.2019 16:401. Речь про переиспользование
кодапроцесса?
2. Ну это риторический вопрос на самом деле ибо сложно оценить сложность рефакторинга. Наверно сложнее, ибо при редактировании кода есть такой момент как скомпиллилось-не скомпиллилось. Тут только на этапе запуска будет ясно, что процесс поломался. Но для того, чтобы ничего не поломать мы пишем юнит тесты на процесс. Несколько раз действительно нас это выручало
3. Ну это не очень удобно на мой взгляд. Я не очень много видел деления процесса на подпроцессы
4. Не очень вопрос понял. Отвечу как понял — запустить процесс прям на лету из среды Camunda Modeler, не стартуя приложение, как в IBM нельзя(ну или я не знаю как). Ну честно говоря лично мне это особо нужно не было, ибо запустить бутовое приложение не особо долго, а проверить, что ничего не поломал при рефакторинге можно в принципе юнит тестами
5. Аналитики точно пользуются. Зачастую они сами их строят. Подправить можно и можно даже на лету подменить схему, но ИМХО делать этого не стоит. Все — таки это не стоит делать если на это нет прям супер-пупер критичной необходимости, ну или если это не прод
DSolodukhin
24.06.2019 13:40Нет вменяемого контроля версий. IBM BPM просто не дает возможности нормально хранить процессы (код) в репозитории и использует свое собственное хранилище, которое не знает о таком понятии, как merge, например.
А можно подробнее? А то может мы что-то не так делали, когда хранили _код_ в гите? Может, я вас неправильно понимаю, но в IBM BPM код бизнес-процесса — это .bpel файлы, которые внутри обычные xml, в чем сложность их хранить в репозитории?nshipyakov Автор
24.06.2019 14:01bpel в Integration Designer, а сами процессы пишутся в Process Designer. Процессы хранятся в Process Center и разработка — редактирование схоже с редактированием гугл дока. Т.е. можно конечно делать снепшотики, веточки, но когда речь заходит про merge — тут все грустно… Xmlки конечно тоже мерджить не особо удовольствие, но тут хотя бы можно реальные файлики просматривать и сравнивать, а в случае с Process Designer нельзя(ну или мы не научились)
nshipyakov Автор
24.06.2019 15:18Хотя немного приврал. Проект можно архивом выгрузить и уже по файлам лазить и из этого какую-то пользу извлекать. Но будем честны — в этом мало приятного(
Losted
25.06.2019 10:37А когда выбирали движок, flowable не рассматривали?
Throwable
25.06.2019 11:36IBM BPM — мощная платформа, которая включает богатый набор возможностей
О даа, это для меня как красная тряпка для быка! Не могу удержаться от переполняющих меня негативных эмоций, когда вижу IBM BPM. Волею богов я был наказан разрабатывать энтерпрайзщину более 10 лет на этом откровенном дерьмище. И по большей части в Integration Developer. Богатых возможностей нам чуть более чем ноль — одни ограничения. То, что можно сделать элементарно, там делаеться сложно, а для реализации простого нужно было создавать свой велосипед. BPMN прикрутили сбоку только в восьмерке, до этого был только BPEL.
К тому же эта платформа имеет довольно низкий порог входа, что позволяет начинающим разработчикам практически сразу погружаться в проект.
Да ладно? А не пугает руководство по инсталляции на 250 страниц? А 7-часовой платный курс, где Раджеш Кутраппали объясняет основы? А когда запускаешь простую вещь, а тебе в ответ несколько экранов stack trace с com.ibm.*, на которые Google выдает 0 результатов? Мотивирует, особенно новичка.
Нет вменяемого контроля версий.
Более того, Integration Developer отказывается работать со стандартными плагинами VCS. Но я все-равно все кладу на SVN.
Разработка на Java 6. Возможно, на момент написания этой статьи уже можно разрабатывать на Java 7, но в 2019 году это слабое утешение.
8.5 уже на Java 7. Мы начинали с Java 4, и до сих пор большинство кодовой базы на ней. Проблема не в Java, а в наборе библиотек Websphere, версии которых заморожены еще с 00-х, и с тех пор имеют неисправленные баги (EMF например и SDO по части сериализации).
Некоторый GUI, где можно посмотреть, что вообще с процессом происходит.
Это не GUI, а поделка, склепанная студентом на коленках в начале нулевых. Когда у вас играет 6k+ процессов в день, увидеть там что-то вообще нет никакой возможности. Благо есть API, который позволяет делать свои вебы.
IBM BPM крутится на WebSphere, в итоге разработчикам надо запасаться терпением при каждом обновлении своего модуля
WS это вообще отдельная история. Похож на старый ламповый телевизор без корпуса и ручек управления. Все настройки сзади, прямо на печатных платах. Отдельным бонусом идет Business Process Choreographer, который не дает удалить приложение, если на нем запущены процессы. Или там мусорные артефакты и байндинги, остающиеся в конфигурации после редеплоя. Иногда после манипуляций Process Server вообще отказывался запускаться, на этот случай держали "чистую" копию директории и базы.
Разработка интеграционных модулей в среде Integration Designer, которая в действительности является затюненным не в лучшую сторону Eclipse.
А редактор BPEL сделан просто отвратительно, лейаут вообще не заточен под стандартные мониторы. Редактировать процесс в крохотном окошечке, снуя туда-сюда между пропертями и ящиками — удовольствие то еще. Судя по остальным продуктам IBM создается впечатление, что они вообще не думают разработчиках — им важны лишь те, кто читает проспектики и покупает. Разрабы для них — это корпоративные плагины к их системам, компиляторы с человечьего на вебсфировский.
Нет нормальной возможности Unit-тестирования.
Вы хотите сказать, нет автоматической возможности тестирования? В понимании IBM это не и нужно. Для юнит-тестирования нужна специально обученная обезьяна, которая будет вручную деплоить артефакты и прокликивать все тесты с данными по методичке. В любом случае это выйдет дешевле.
очень демотивируют команду
Вам повезло, у вас есть команда. Наша разбежалась, не успев еще проект встать на продакшн. Найти спеца по IBM BPM практически невозможно, а обучить других с "низким порогом вхождения" не имеет смысла — они сваливают при первой возможности, не успев еще ничего сделать.
Я еще могу бросать камни в эту софтину хоть до завтрашнего утра. Что до версии 8.5 оно каждые полгода "засиралось" так, что приходилось создавать новый инстанс, работающий параллельно со старым. После крэшев иногда по непонятной причине отваливался SCA-binding, процессы не видели друг друга, и это при том, что каждый имел до десятков тысяч живых инстансов. Внятного версионирования модулей вообще нет — приходилось создавать копии модулей и деплоить их, либо вообще делать полную копию всего воркбенча. Из "богатых возможностей" я бы отметил чуть больше, чем ничего: для всего приходилось делать велосипеды и подпорки, в итоге спасла только Java, куда было вынесено большинство логики. Работы с данными вообще никакая: объекты на основе xsd и SDO, отсутствует нормальный type-safe меппинг (xslt прикрутили только в семерке). Полностью пропиетарный и закрытый state: в базе ничего ручками не подправить. Под ковром для интеграции используется малопонятная Service Integration Bus, документации к которой чуть менее, чем никакой. И что официальные бандлы продуктов, скачанные со страниц IBM тупо не устанавливаются. Также доставляет установка патчей и внутренняя борьба Installation Manager с FixPack. Про саппорт даже ничего не хочу говорить.
Чуть менее года назад поступило предложение попробовать движок Camunda для описания бизнес-процессов.
У нас было проще. За 2 недели мы переписали полностью весь функционал на голой Java. Вместо BPM движка использовали persistent storage и сериализацию. Все это было предложено клиенту за минимальную плату. Но клиент оказался дебилом.
nshipyakov Автор
25.06.2019 12:04По каждому пункту будет очень долго дискутировать, но насчет богатых возможностей — действительно они есть. Например UCA довольно интересная штука, да и то что есть конструктор интерфейсов — тоже скорее плюс чем минус. Понятно, что конструктор убогий, но если цель сделать быстро MVP — почему нет.
А так да. Не самый приятный инструмент.
SolodkovV
25.06.2019 12:15Нет вменяемого контроля версий. IBM BPM просто не дает возможности нормально хранить процессы (код) в репозитории и использует свое собственное хранилище, которое не знает о таком понятии, как merge, например.
Код из Integration Designer замечательно можно хранить в системе контроля версий. SVN, GIT
В IBM BPM контроль версий через снапшоты (откатить любой элемент можно до версии сделанной в этом снапшоте). Иногда восстанавливает некорректно, если есть большое количество связей на Coach, тогда эти связи могут отвалится.
Разработка на Java 6. Возможно, на момент написания этой статьи уже можно разрабатывать на Java 7, но в 2019 году это слабое утешение.
IBM BPM 8.6.0 (версия вышедшая в 2017 году) поддерживает java 8
IBM BPM крутится на WebSphere, в итоге разработчикам надо запасаться терпением при каждом обновлении своего модуля. К тому же это дополнительная головная боль для админов, которым периодически приходится возвращать к жизни этого монстра в случае его зависания.
Вот тут возникает 2 вопроса:
- насколько качественно разрабатываются процессы и админится WS
- сколько приобретено unit у IBM (сколько мощности под капотом)
Разработка интеграционных модулей в среде Integration Designer, которая в действительности является затюненным не в лучшую сторону Eclipse.
Нет нормальной возможности Unit-тестирования.
Высокая стоимость платформы.
Чистая правда. IID и BPM изменённый eclipse.
Слышал об IBM BPM Testing Asset, а так же есть масса способов прикрутить тесты к IBM BPM. Но все они связаны с шаманством.
Стоимость высокая, но в зависимости от обстоятельств, IBM делают хорошие скидки.
Плюс получить готовый коробочный продукт, на развитие которого не нужно тратить много сил разработчиков, наверное, стоит того. Как недавно в своей презентации о Camunda говорил Ваш коллега, Денис Котов, для того чтобы стартовать промышленную разработку на Camunda нужно сначала сделать очень много периферии. Если есть много скучающих Java-разработчиков, наверное, это не проблема вовсе.
IBM развивает свой продукт. Если в старых версиях инструментарий для интерфейсов пользователя был крайне скудным, то с 8.6.0 это сильно изменилось. У платформы есть минусы: невозможность перенести многие самостоятельные решения с предыдущей версии на новую (поэтому часть компаний по прежнему держать систему на 8.5.5 и 8.5.7). Курсы и обучение актуальным версия в России отсутствует.
Но года два-три назад появился новый тренд Camunda, а IT сообщество падко на такие вещи, плюс разработчики крупных BPM подняли цены, а тут «бесплатное» решение. Но никто не берёт в расчет, что необходимо вначале выстроить крупную инфраструктуру для этого решения, а для этого нужны люди с высокими компетенциями.
Это продукты совершенно разных уровней. Сравнивать их не правильно и вредно, оно (сравнение) создаёт у несвязанных с этим людей неправильное впечатление.
nshipyakov Автор
25.06.2019 15:241. Контроль версий через снепшоты — вообще не серьезно. А код-ревью как проводить? Давайте будем честны, что такую версионность можно взять и положить на далекую полку ибо это крайне неудобно
2. В 2017 году java8. Ну наконец — то
3. Если не вдаваться в демагогию про то как лучше админить, а просто взять как было и как стало: раньше админы постоянно чинили IBM и испытывали массу стресса из за этого. Сейчас когда каждое приложение в облаке все стало для них гораздо проще. Да и для нас.
4. Сравнивать эти продукты как раз надо. Одни и те же задачи решаем и на одном процессы — костыли, на другом — современные и тестируемые приложения в облаках
5. По поводу переферии — да она нужна. Метрики например написать. Но это не так долго делается. Гораздо больше времени теряется при использовании IBM BPM на вообще непонятно что:
a. умер сервер — давайте все посидим подождем пока админы починят
b. давайте разбираться с шаманством для Юнит тестирования. Зачем нам стандартные практики когда есть IBM BPM Testing Asset. Кстати интересно за него отдельная плата или он в комплекте
c. целый день устанавливать вебсферу на локальную машину. или как вариант пользоваться общей дев средой, которую тоже кстати кто-то админить должен
и список этот можно продолжать довольно долго
К слову камунду от нулевой компетенции до проекта на проде мы выкатили за 3 месяца. Я сомневаюсь, что дай сейчас продукт от IBM без компетенции получится сделать то же самое соответствующего качестваSolodkovV
25.06.2019 16:08Видимо у нас разный опыт пользования IBM BPM. Поэтому я и указал на современную версию IBM BPM. Если вы сравниваете систему 3-ех летней давности со свеженькой Camunda, это несколько не честно.
Если опытного программиста посадить за IBM BPM — она ему не понравится из-за своих жестких рамок и крайне специфического инструмента. Да и как IDE она плоха.
По своему опыту могу сказать, что разработка на IBM BPM может быть быстрой и стабильной. Но если бизнес процесс слабо проработан, запутан до невозможности или бизнес заказчик просто не знает что хочет, то тут ни одна BPM система не спасёт.
PS. Насколько я помню, именно Тинькофф первым из банков публиковали свой опыт по созданию кредитного конвейра на IBM BPM. И отзыв был исключительно положительным.nshipyakov Автор
25.06.2019 16:42Ну процессы все-таки разработчики разрабатывают, поддерживают и баги в них фиксят. И если это не удобный для них инструмент, то на мой взгляд это немаловажно
Throwable
25.06.2019 12:31Camunda действительно неплохое решение в сфре BPM, но далеко не единственное. Вопрос в том действительно ли вам необходим именно BPM, и покрывает ли его функционал ваши юзкейсы.
В самом начале, при выборе инструмента, мы искали решение со следующими возможностями:
Тут вообще подходит любой движок с персистенцией, от склепаного на коленках до Activiti.
Вот что действительно бывает релевантно при подборе технологии:
- BPMN: а так ли он нужен? Например если у вас преобладают автоматические процессы, всю бизнес-логика завязана на работу с данными, а процессы достаточно ограниченны поэтому BPMN тут будет только мешать.
- Лекговесность движка. Стоит ли устанавливать тяжелую полнофункциональную платформу, либо ограничится легким библиотекой-движком, интегрированным на вашу платформу? В некоторых случаях движками могут являться котлиновские корутины или джавовские файберы. В большинстве случаев хватает вообще обычной state machine.
- Открытость и документированность формата персистенции. Иногда возникает острая необходимость поправить данные ручками прямо "по живому".
- Пользовательский веб. Позволяет пользователю выполнять ручные задачи. Не сильно ведитесь. Возможности как правило сильно ограничены и неудобны. В большинстве придется интегрировать пользовательские задачи в корпоративный портал или более общую систему. Поэтому гораздо важнее наличие API, чем веб как таковой.
- Админка. Практически бесполезная вещь. Есть база данных, есть API. Мониторинг будет обычно ведется сторонними средствами.
- Версионирование. Вот здесь большинство съедает собаку. Заявленное версионирование процесса — это только версионирование схемки, но не артефактов и зависимостей. То есть все ваши Java-рутины, интерфейсы, меппинги и т.д. проверсионированы не будут и при деплое войдут в конфликт со старыми процессами. Надо смотреть, может ли система упаковывать все артефакты в отдельный бандл и обеспечить их co-living, а также оставить возможность сделать деплой поверх старой версии.
- Под BPM-движком все-равно должна быть какая-то платформа для интеграции сервисов. Иногда совсем не подходит под задачу.
- Development & delivery. Иногда предлагаемый цикл абсолютно не подходит под методологию работы, как в случае общего репозитория процессов, когда вы привыкли деплоить отдельные бинарники.
Kotskin
25.06.2019 18:36+1Ровно с такими требованиями Camunda как раз и создана:
*BPMN сначала практически никогда не нужен, но потом практически всегда нужен (если мы говорим про бизнес-процессы, см. bpmn2.ru/blog/kak-i-zachem-perexodit-k-processam ). А еще он работает отличной автодокументацией для бизнеса \ поддержки.
*Camunda используется как либа в Spring boot, это самый желанный вариант.
*Документация отличная, структура данных открытая. Контекст инстансов полностью независим от инстансов, можно менять в рантайме.
*Гуй встроенный можно выкинуть, нужно делать свой. Апи готово.
*Админка нужна не только для мониторинга, но и для эксплуатации — запаузить повалившийся квадратик, сделать миграцию, передёрнуть токен и т.д. На это всё готово АПИ.
*Код не версионируется, это нормально. Хмл-ки версионируются через базу, как и инстансы
*Платформа для интеграции сервисов — Kotlin :) Ну и всякие асинхронные приколы нужны конечно, очереди там.
*Поскольку используем как либку, то цикл такой, как хочется. Всё в итоге доставляется в кубер одним джарником, включая процессы.
Throwable
26.06.2019 13:05+1*BPMN сначала практически никогда не нужен, но потом практически всегда нужен (если мы говорим про бизнес-процессы
Вот с этим готов не согласиться. Под видом BPM часто подсовывают BPMN, а это не одно и то же. Семантику бизнес процесса можно выразить кучей способов без BPMN. Самый простой — это конечный автомат, где все действия пронумерованы, а выполнение каждого из них возвращает номер следующего действия или nil. Как программа на бейсике. Более сложной является декларативная семантика rule engines, где процесс выводится автоматически на основе правил и зависимостей. Как я уже сказал, зачастую BPM используют там, где нужно асинхронное выполнение, но это неправильно, ибо для этого есть файберы, корутины, колбеки и куча других вещей.
А BPMN во многих ситуациях является пятым колесом: вроде как и стандарт, но сам по себе ничего делать не умеет, поэтому всегда требует интеграции с низлежащими технологиями, для которых он всегда будет инородным телом в проекте. Хорошо, когда нужна визуализация и полный контроль над процессами.
Код не версионируется, это нормально.
Не сказал бы что нормально. Ибо как ни крути, львиная доля логики всега лежит в java-based activities. Если меняется процесс, меняется и логика классов. А версионировать классы ручками — занятие неблагодарное.
Kotskin
26.06.2019 14:12+1Так в bpm(n) основная фишка в том, что удобно менять процессы, не трогая ничего остального — не трогая классы, данные и интеграции. Т.е. совершенно отдельная управляемая структура.
Совсем не обязательно что меняется процесс, то меняется и код под квадратиками. И наоборот.
Со Стейтмашинами и рул ендженами логика потока протекает в данные, что делает сложным их отдельное управления.
Справедливости ради, правила и стейтмашины круто заходят там, где данные меняются асинхронно и не под нашим (процессным) контролем, и вычислять следующее состояние нужно каждый раз из "ничего".
krocodl
25.06.2019 15:06+11) имеет смысл обратить внимание на Zebee, это высокопроизводительный BPMN движок, ориентированный на использование с микросервисами. В качестве хранилища в отличии от Camunda используется не реляционная БД, а партиционированные реплики данных по типу Kafka. От того же производителя, что и Camunda
2) Мы перешли с Oracle BPM на Camunda, очень довольны. Система содержит порядка полусотни различных процессов, каждый на 10-30 операций
3) Если есть вопросы, то могу ответить. Для себя сделал компиляцию книжек, статей и собственного опыта. Можно взять свободно тут — www.twirpx.com/file/2771420nshipyakov Автор
25.06.2019 15:07Спасибо большое!
krocodl
25.06.2019 15:13У нас была дополнительная сложность: интеграция с EJB / CDI / WebLogic / веб-сервисами / распределенными транзакциями (так делать не надо!). Сделали сами на коленке не связываясь с платной версией. Не уверен, что это полезный опыт, но он есть.
pilot911
а какие накладные процессорные расходы накладывает движок BPM в сравнении с захардкоденными flow?
проводились ли сравнения производительности?
nshipyakov Автор
Речь про вариант захардкодить флоу на IFах?
Не сравнивали производительность, но пока проблем не наблюдали с производительностью. Пока все в штатном режиме