Comments 13
А как в Camunde покрывается проблема
? извините, если не по статье вопрос.
Сложности совместной разработки схем\кода, по существу монопольный режим разработки.
? извините, если не по статье вопрос.
Вполне по теме.
Мы используем Camunda как зависимость в проекте, поэтому весь код живёт как у людей — в Git.
С BPMN-файлами (они же XML) примерно так же, только их автоматом не смерджить. Поэтому изредка приходится это делать руками. Если там прям что-то большое, то иногда использую github.com/bpmn-io/bpmn-js-differ
Мы используем Camunda как зависимость в проекте, поэтому весь код живёт как у людей — в Git.
С BPMN-файлами (они же XML) примерно так же, только их автоматом не смерджить. Поэтому изредка приходится это делать руками. Если там прям что-то большое, то иногда использую github.com/bpmn-io/bpmn-js-differ
Добрый день, Денис. Большое спасибо за статью, как раз хотел увидеть пример успешного внедрения Camunda BPM.
Несколько не понял, как возник такой профит времени и ресурсе, если в тексте:
Рискну предположить, что тут сыграл рефакторинг бизнес логики и структуры разработки. Но это проблема разработки и её поддержки, а не платформы.
По поводу ограничений платформы для разработчика — это в яблочко. Перейти с intellij idea на Eclipse (которым по сути и является IBM Integration Designer) очень тяжело, писать красивый фронт тоже не получится в IBM BPM. Да и специалистов найти — проблема, особенно если учитывать, что система с версиями сильно меняется и порой кампании требуется поддержка старой версии. Это особенность не только IBM BPM, а вообще всех подобных продуктов (Siebel CRM в том числе). Про плюсы данных систем не говорим, это дело отдельной статьи.
Я понимаю, что есть ряд ограничений по тому, что можно показывать и рассказывать, но, конкретно данный пример кажется крайне абстрактным и выводы связаны не с Camunda, а качественно новым уровнем проектирования информационных систем.
Несколько не понял, как возник такой профит времени и ресурсе, если в тексте:
Когда в беклоге появилась задача, мы старались идентифицировать квадратик\компонент\сервис к которому он относится и переписывали эту штуку с нуля в Camunda. Иногда по стоимости это было 1.2х (х — если бы делали в IBM), иногда — 3х или 5х.
Рискну предположить, что тут сыграл рефакторинг бизнес логики и структуры разработки. Но это проблема разработки и её поддержки, а не платформы.
По поводу ограничений платформы для разработчика — это в яблочко. Перейти с intellij idea на Eclipse (которым по сути и является IBM Integration Designer) очень тяжело, писать красивый фронт тоже не получится в IBM BPM. Да и специалистов найти — проблема, особенно если учитывать, что система с версиями сильно меняется и порой кампании требуется поддержка старой версии. Это особенность не только IBM BPM, а вообще всех подобных продуктов (Siebel CRM в том числе). Про плюсы данных систем не говорим, это дело отдельной статьи.
Я понимаю, что есть ряд ограничений по тому, что можно показывать и рассказывать, но, конкретно данный пример кажется крайне абстрактным и выводы связаны не с Camunda, а качественно новым уровнем проектирования информационных систем.
Профит возник в том, что в итоге стало дешевле и проще разрабатывать, а так же проще найти и замотивировать ребят работать с нормальным стеком.
Здесь заслуга не только от Camunda, скорее она просто хорошо подошла под наш замысел проектирования, тут я с вами согласен.
Здесь заслуга не только от Camunda, скорее она просто хорошо подошла под наш замысел проектирования, тут я с вами согласен.
Подскажите, насколько активно идут Java программисты на проект разработки/поддержки проекта на Camunda? По сути, ведь, большая часть кода приложения связана с вызовом Camunda API в том или ином месте и виде.
Скорее наоборот, это Camunda вызывает код на Java, а не наоборот. За несколько лет только один раз человек отказался работать с Camunda, потому что хотел делать «нормальный код, а не стрелочки двигать». Но за счёт того что это привычный всем спринг и котлин, такого сопротивления, как с IBM, конечно нет.
Тоже накину. Для процессов на камунде довольно удобно и прикольно писать юнит тесты. Этот момент тоже крайне положительно влияет на разработку и как итог удешевляет ее
-Раньше текст был захардкожен на уровне компонента
-Лицензионные ограничения заставляли нас пихать множество продуктов в один кластер
-Мы старались переиспользовать общий код внутри разных бизнесовых процессов, что создавало сложности с его модификацией.
-проще было архитектора заменить, а не движок.
Трансляция митапа будет на youtube.com?
Для бизнес-правил традиционно используем IBM ODM, а сейчас начинаем использовать свой фреймворк на Kotlin.
Скажите, почему не использовали встроенный в Camunda (его кстати также можно отдельно вызывать) движок правил DMN или Drools?
И было бы интересно узнать подход к миграции правил на другую систему, там, как опыт подсказывает, не всегда просто переехать по частям.
Sign up to leave a comment.
Как мигрировать большой процесс с IBM BPM на Camunda и не останавливать разработку фич