Comments 12
После прочтения этой статьи у вас может сложиться впечатление, будто мы отказались от всех преимуществ BPMS и переложили ответственность на самописный код. Но это не так.
Именно так. Более 10 лет разрабатывал под BPM, а ситуация все та же. Сначала вам задвигают Дорогое Красивое Решение, которое предендует на роль швейцарского ножа на все случаи жизни. Уже в процессе внезапно оказывается, что лезвия нихрена не режут, тупые, маленькие, пользоваться им не удобно или по большей части существуют как декорация. В итоге весь цикл разработки — это горожение велосипедов в борьбе с ограничениями платформы, и постепенная миграция критического функционала из BPM на самописку вплоть до полного отказа от этой самой BPM.
Центр любой BPMS – это BPM-движок, и мы используем его по полной. Это удивительный инструмент, который действительно помогает ускорить разработку и повысить качество поставляемых решений.
Ваш движок — это джарник на 100кб, коих на гитхабе полно, и сам по себе не несет абсолютно никакой ценности. Для того, чтобы его можно было использовать, нужна платформа для интеграции типа Spring и какой-нибудь persistence layer. Коммерческие решения поверх этого обвешиваются различного рода порталами и бизнес тулзами на все случаи жизни, однако как всегда жутко неудобоваримыми и ограниченными. У меня есть твердое убеждение, что весь этот обвесок служит по большей части для маркетинга, нежели для реального использования.
Ну и еще, такое наблюдение: 95% пользователей тащат в проект BPM потому что не знают как осуществить персистенцию долгоиграющего процесса или сделать асинхронный вызов. А большинство т.н. "процессов" — это линейные вызовы в лучшем случае с парой ветвлений.
Именно так. Более 10 лет разрабатывал под BPM, а ситуация все та же. Сначала вам задвигают Дорогое Красивое Решение, которое предендует на роль швейцарского ножа на все случаи жизни. Уже в процессе внезапно оказывается, что лезвия нихрена не режут, тупые, маленькие, пользоваться им не удобно или по большей части существуют как декорация. В итоге весь цикл разработки — это горожение велосипедов в борьбе с ограничениями платформы, и постепенная миграция критического функционала из BPM на самописку вплоть до полного отказа от этой самой BPM.
вот именно почему сказано:
Вместо того, чтобы помещать BPM движок в центр нашего бизнес-процесса, мы используем его как вспомогательный фреймворк. Руководящая роль в этом случае отводится .NET-приложению
Вместо того, чтобы помещать BPM движок в центр нашего бизнес-процесса, мы используем его как вспомогательный фреймворк
Любой менеджер, продающий коммерческую BPM, с пеной у рта будет вам доказывать, что BPM обязательно должна ядром вашего бизнеса и IT-архитектуры, и все сервисы и процессы должны строиться вокруг нее. Иначе это пустая трата денег (что собственно верно). Ну а во-вторых, согласно моей практике, в большинство решений, где требуется "только мотор", в итоге очень неплохо обходятся без него. Как я уже сказал, много людей тащат в проект BPM, только потому что им внезапно понадобились асихнронные вызовы с персистенцией.
Основное преимущество в том, что BPMN – это исполняемая документация.
Вот в это я ни за что не поверю. Есть два мира: в одном аналитик рисует красивый оптимистичный BPMN согласно тому, как он видит бизнес задачу, а в другом девелоперы строчат по картинке страшный реальный процесс, учитывая стопицот нюансов и поведений, которые не учел аналитик, и который в итоге и будет работать. Как ни пытались производители BPMS помирить эти два мира и сделать единый репозиторий — не получилось. В итоге уже после первой итерации аналитик говорит: "вот я вам донес идею, а вы там себе скопируйте мою схему и добавьте как вам надо".
Начав исследовать Camunda я столкнулся с очевидной проблемой. Camunda написана на Java, разворачивается в среде Java и расширяется при помощи Java-подобных языков
А почему REST API не использовали?
Мы используем REST API Camunda для того, чтобы взаимодействовать с движком и манипулировать экземплярами бизнес-процессов.
Kotlin нужен для того, чтобы вызывать внешний REST API написанный на .NET, например, для того чтобы отправить нотификацию или получить список кандидатов для утверждения таска из бизнес-данных.
Пример:
У нас есть таблица отображаемая у технолога и финансиста с возможностью редактирования.
Данные – одни и те же строки в БД.
Технолог открывает форму и уходит за кофе.
В это время финансист открывает форму, вносит изменения в таблицу и отправляет задачу дальше.
Технолог возвращается, вносит изменения в таблицу, отправляет форму и тем самым перезатирает данные финансиста, которые не подтянул ранее.
Для подобных кейсов приходится придумывать разные способы решения, которые зависят от ситуации.
А вы рассматривали альтернативные лоу-код платформы? Да, они как правило строятся не по чистой БПМН методологии, но позволяют быстро собрать решение под процессы, похожие на ваши.
Принцип ведь схожий: генерируемые формы UI + скрипты автоматизации для оживления и коннектов с внешним миром.
Рассматривали какие-то продукты?
Внутренняя автоматизация – почему мы отказались от Bonita в пользу Camunda