Comments 39
проводились ли сравнения производительности?
2. Сложно ли вообще рефакторить схемы, по сравнению с рефаторингом обычного кода?
3. Можно ли одновременно разрабатывать схему? Применяется ли практика деления на подпроцессы?
4. Есть ли проблемы при моделировании, например, есть в инструменте отладчик того что бы что то где то не правильно подключил в схеме?
5. Пользуются ли аналитики/менеджеры разработанными схемами? Могут что то подправить?
2. Ну это риторический вопрос на самом деле ибо сложно оценить сложность рефакторинга. Наверно сложнее, ибо при редактировании кода есть такой момент как скомпиллилось-не скомпиллилось. Тут только на этапе запуска будет ясно, что процесс поломался. Но для того, чтобы ничего не поломать мы пишем юнит тесты на процесс. Несколько раз действительно нас это выручало
3. Ну это не очень удобно на мой взгляд. Я не очень много видел деления процесса на подпроцессы
4. Не очень вопрос понял. Отвечу как понял — запустить процесс прям на лету из среды Camunda Modeler, не стартуя приложение, как в IBM нельзя(ну или я не знаю как). Ну честно говоря лично мне это особо нужно не было, ибо запустить бутовое приложение не особо долго, а проверить, что ничего не поломал при рефакторинге можно в принципе юнит тестами
5. Аналитики точно пользуются. Зачастую они сами их строят. Подправить можно и можно даже на лету подменить схему, но ИМХО делать этого не стоит. Все — таки это не стоит делать если на это нет прям супер-пупер критичной необходимости, ну или если это не прод
Нет вменяемого контроля версий. IBM BPM просто не дает возможности нормально хранить процессы (код) в репозитории и использует свое собственное хранилище, которое не знает о таком понятии, как merge, например.
А можно подробнее? А то может мы что-то не так делали, когда хранили _код_ в гите? Может, я вас неправильно понимаю, но в IBM BPM код бизнес-процесса — это .bpel файлы, которые внутри обычные xml, в чем сложность их хранить в репозитории?
IBM 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 и сериализацию. Все это было предложено клиенту за минимальную плату. Но клиент оказался дебилом.
А так да. Не самый приятный инструмент.
Ты походу очень шаришь с этой штуке. У меня есть процесс в camunda, у него есть Zeebe API, я так понял через него бекенд общается с camunda. Мне нужно, что бы по userId и Instance Id, я отдавал бы название на какой таске сейчас находится этот пользователь.В документации я не нашел каких то явных способов это достать типо getProcess(InstanceId) может кто то знает как можно достать название "Завершение инициализации" - на этом этапе находится пользователю сейчас. Я посмотрел как формируется Ui - там гигантский xml его очень неудобно парсить, и это не через Zeebe API получено, я думаю есть более нормальный способ. Есть мысли?
Нет вменяемого контроля версий. 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 подняли цены, а тут «бесплатное» решение. Но никто не берёт в расчет, что необходимо вначале выстроить крупную инфраструктуру для этого решения, а для этого нужны люди с высокими компетенциями.
Это продукты совершенно разных уровней. Сравнивать их не правильно и вредно, оно (сравнение) создаёт у несвязанных с этим людей неправильное впечатление.
2. В 2017 году java8. Ну наконец — то
3. Если не вдаваться в демагогию про то как лучше админить, а просто взять как было и как стало: раньше админы постоянно чинили IBM и испытывали массу стресса из за этого. Сейчас когда каждое приложение в облаке все стало для них гораздо проще. Да и для нас.
4. Сравнивать эти продукты как раз надо. Одни и те же задачи решаем и на одном процессы — костыли, на другом — современные и тестируемые приложения в облаках
5. По поводу переферии — да она нужна. Метрики например написать. Но это не так долго делается. Гораздо больше времени теряется при использовании IBM BPM на вообще непонятно что:
a. умер сервер — давайте все посидим подождем пока админы починят
b. давайте разбираться с шаманством для Юнит тестирования. Зачем нам стандартные практики когда есть IBM BPM Testing Asset. Кстати интересно за него отдельная плата или он в комплекте
c. целый день устанавливать вебсферу на локальную машину. или как вариант пользоваться общей дев средой, которую тоже кстати кто-то админить должен
и список этот можно продолжать довольно долго
К слову камунду от нулевой компетенции до проекта на проде мы выкатили за 3 месяца. Я сомневаюсь, что дай сейчас продукт от IBM без компетенции получится сделать то же самое соответствующего качества
Если опытного программиста посадить за IBM BPM — она ему не понравится из-за своих жестких рамок и крайне специфического инструмента. Да и как IDE она плоха.
По своему опыту могу сказать, что разработка на IBM BPM может быть быстрой и стабильной. Но если бизнес процесс слабо проработан, запутан до невозможности или бизнес заказчик просто не знает что хочет, то тут ни одна BPM система не спасёт.
PS. Насколько я помню, именно Тинькофф первым из банков публиковали свой опыт по созданию кредитного конвейра на IBM BPM. И отзыв был исключительно положительным.
Camunda действительно неплохое решение в сфре BPM, но далеко не единственное. Вопрос в том действительно ли вам необходим именно BPM, и покрывает ли его функционал ваши юзкейсы.
В самом начале, при выборе инструмента, мы искали решение со следующими возможностями:
Тут вообще подходит любой движок с персистенцией, от склепаного на коленках до Activiti.
Вот что действительно бывает релевантно при подборе технологии:
- BPMN: а так ли он нужен? Например если у вас преобладают автоматические процессы, всю бизнес-логика завязана на работу с данными, а процессы достаточно ограниченны поэтому BPMN тут будет только мешать.
- Лекговесность движка. Стоит ли устанавливать тяжелую полнофункциональную платформу, либо ограничится легким библиотекой-движком, интегрированным на вашу платформу? В некоторых случаях движками могут являться котлиновские корутины или джавовские файберы. В большинстве случаев хватает вообще обычной state machine.
- Открытость и документированность формата персистенции. Иногда возникает острая необходимость поправить данные ручками прямо "по живому".
- Пользовательский веб. Позволяет пользователю выполнять ручные задачи. Не сильно ведитесь. Возможности как правило сильно ограничены и неудобны. В большинстве придется интегрировать пользовательские задачи в корпоративный портал или более общую систему. Поэтому гораздо важнее наличие API, чем веб как таковой.
- Админка. Практически бесполезная вещь. Есть база данных, есть API. Мониторинг будет обычно ведется сторонними средствами.
- Версионирование. Вот здесь большинство съедает собаку. Заявленное версионирование процесса — это только версионирование схемки, но не артефактов и зависимостей. То есть все ваши Java-рутины, интерфейсы, меппинги и т.д. проверсионированы не будут и при деплое войдут в конфликт со старыми процессами. Надо смотреть, может ли система упаковывать все артефакты в отдельный бандл и обеспечить их co-living, а также оставить возможность сделать деплой поверх старой версии.
- Под BPM-движком все-равно должна быть какая-то платформа для интеграции сервисов. Иногда совсем не подходит под задачу.
- Development & delivery. Иногда предлагаемый цикл абсолютно не подходит под методологию работы, как в случае общего репозитория процессов, когда вы привыкли деплоить отдельные бинарники.
*BPMN сначала практически никогда не нужен, но потом практически всегда нужен (если мы говорим про бизнес-процессы, см. bpmn2.ru/blog/kak-i-zachem-perexodit-k-processam ). А еще он работает отличной автодокументацией для бизнеса \ поддержки.
*Camunda используется как либа в Spring boot, это самый желанный вариант.
*Документация отличная, структура данных открытая. Контекст инстансов полностью независим от инстансов, можно менять в рантайме.
*Гуй встроенный можно выкинуть, нужно делать свой. Апи готово.
*Админка нужна не только для мониторинга, но и для эксплуатации — запаузить повалившийся квадратик, сделать миграцию, передёрнуть токен и т.д. На это всё готово АПИ.
*Код не версионируется, это нормально. Хмл-ки версионируются через базу, как и инстансы
*Платформа для интеграции сервисов — Kotlin :) Ну и всякие асинхронные приколы нужны конечно, очереди там.
*Поскольку используем как либку, то цикл такой, как хочется. Всё в итоге доставляется в кубер одним джарником, включая процессы.
*BPMN сначала практически никогда не нужен, но потом практически всегда нужен (если мы говорим про бизнес-процессы
Вот с этим готов не согласиться. Под видом BPM часто подсовывают BPMN, а это не одно и то же. Семантику бизнес процесса можно выразить кучей способов без BPMN. Самый простой — это конечный автомат, где все действия пронумерованы, а выполнение каждого из них возвращает номер следующего действия или nil. Как программа на бейсике. Более сложной является декларативная семантика rule engines, где процесс выводится автоматически на основе правил и зависимостей. Как я уже сказал, зачастую BPM используют там, где нужно асинхронное выполнение, но это неправильно, ибо для этого есть файберы, корутины, колбеки и куча других вещей.
А BPMN во многих ситуациях является пятым колесом: вроде как и стандарт, но сам по себе ничего делать не умеет, поэтому всегда требует интеграции с низлежащими технологиями, для которых он всегда будет инородным телом в проекте. Хорошо, когда нужна визуализация и полный контроль над процессами.
Код не версионируется, это нормально.
Не сказал бы что нормально. Ибо как ни крути, львиная доля логики всега лежит в java-based activities. Если меняется процесс, меняется и логика классов. А версионировать классы ручками — занятие неблагодарное.
Так в bpm(n) основная фишка в том, что удобно менять процессы, не трогая ничего остального — не трогая классы, данные и интеграции. Т.е. совершенно отдельная управляемая структура.
Совсем не обязательно что меняется процесс, то меняется и код под квадратиками. И наоборот.
Со Стейтмашинами и рул ендженами логика потока протекает в данные, что делает сложным их отдельное управления.
Справедливости ради, правила и стейтмашины круто заходят там, где данные меняются асинхронно и не под нашим (процессным) контролем, и вычислять следующее состояние нужно каждый раз из "ничего".
2) Мы перешли с Oracle BPM на Camunda, очень довольны. Система содержит порядка полусотни различных процессов, каждый на 10-30 операций
3) Если есть вопросы, то могу ответить. Для себя сделал компиляцию книжек, статей и собственного опыта. Можно взять свободно тут — www.twirpx.com/file/2771420
Мы как раз присматриваемся к Camunda.
Хотелось бы понять следующее:
1) Где вы храните код делегатов? В самом Spring-boot сервисе?
2) Есть ли API, которая позволяет задеплоить процесс в runtime, в идеале с новым кодом, как если это делать на wildfly? Если такой апишки нет, получается для деплоя нужно каждый раз перекатывать приложение?
1. Да храним прям в спринговом приложении
2. Процесс можно обновить на лету через Camunda Modeler. Лично мне этот вариант не нравится, ибо на мой взгляд это не особо целостно. Перенакатить модуль не особо сложно.
Позволю себе задать ещё несколько вопросов.
Вы используете Community или Enterprise?
Насколько, на Ваш взгляд оправдана покупка лицензии? Или проще самим всю информацию собирать через апишки?
Не сталкивались с проблемами тестирования Parallel MultiInstance Subprocess?
Вы взаимодействуете с MQ сервисами, если да, то как понимаете CorrelationKeys для маппинга с ReceiveMessage и Singal?
Вы выделяете общие части в процессах и выносите их в отдельные схемы? Если да, то насколько сложно тестировать и поддерживать такие вещи?
Спасибо огромное за статью!!!
Подскажите, плиз по отчетам в Camunda.
Собираюсь интегрировать процесс от подачи заявки до предоставления услуги, в процессе участвуют несколько отделов, нужно интегрировать Camunda с Siebel CRM и личным кабинетом.
Требуют проверять SLA по каждому шагу процесса, при этом 1 таску в Siebel в Camunda будут соответствовать несколько «кубиков».
По вашему опыту, может ли Camunda показать отчет после предоставления услуги по выбранному сотруднику и по выбранному шагу в Siebel?
У меня лично опыта работы с подобными отчетами нет. Но пользуясь API camunda я думаю можно такие отчеты самим сделать. Апишка довольно крутая и позволяет вытаскивать что-то типо — число процессов которые прошли такой то шаг успешно или число процессов, которые сейчас на таком то шаге и тд
Всем привет, у меня есть процесс в camunda, у него есть Zeebe API, я так понял через него бекенд общается с camunda. Мне нужно, что бы по userId и Instance Id, я отдавал бы название на какой таске сейчас находится этот пользователь.В документации я не нашел каких то явных способов это достать типо getProcess(InstanceId) может кто то знает как можно достать название "Завершение инициализации" - на этом этапе находится пользователю сейчас. Я посмотрел как формируется Ui - там гигантский xml его очень неудобно парсить, и это не через Zeebe API получено, я думаю есть более нормальный способ.
Стильная, модная, молодежная разработка BPM на Camunda