Как стать автором
Обновить

Комментарии 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, например, для того чтобы отправить нотификацию или получить список кандидатов для утверждения таска из бизнес-данных.
А почему не использовать здесь тоже .net? Вроде у них есть пожжержка стека .net
Честно говоря, не совсем понимаю, о какой именно поддержке вы говорите. Можете кинуть ссылку? Было бы интересно почитать
Все же наблюдается, что большие системы не вывозят low code и приходится почти полноценно кодить, чтобы система была рабочей и подходила под компанию.
А насколько удобно в Camunda и Bonita делаются более сложные топологии, например, параллельные подпроцессы и условия по их результатам? В идеале, скажем, когда заявку должны независимо параллельно проверить и одобрить: технолог AND отдел IT AND (финансовый отдел OR директор филиала)
С этой задачей BPMN очень легко справляется. Например, «Обходной лист» представляет из себя параллельное утверждение десятью группами людей, результаты действий которых агрегируются на странице увольняемого сотрудника. Единственное ограничение, которое мы заметили – это работа с общими данными.

Пример:
У нас есть таблица отображаемая у технолога и финансиста с возможностью редактирования.
Данные – одни и те же строки в БД.
Технолог открывает форму и уходит за кофе.
В это время финансист открывает форму, вносит изменения в таблицу и отправляет задачу дальше.
Технолог возвращается, вносит изменения в таблицу, отправляет форму и тем самым перезатирает данные финансиста, которые не подтянул ранее.

Для подобных кейсов приходится придумывать разные способы решения, которые зависят от ситуации.
Чтобы внедрить BPM нужно отказаться от BPM. :-)

А вы рассматривали альтернативные лоу-код платформы? Да, они как правило строятся не по чистой БПМН методологии, но позволяют быстро собрать решение под процессы, похожие на ваши.

Принцип ведь схожий: генерируемые формы UI + скрипты автоматизации для оживления и коннектов с внешним миром.

Рассматривали какие-то продукты?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.