Мне важно добиться именно поведения

Ну и поведение же у них концептуально разное

Пока что кажется что проще делать два разных воркера

Возможно это будет более правильное решение. Два воркера  - два разных поведения. Бизнесовую часть можно выделить в отдельный метод (обработчик/сервис/и т.д.) А интеграционную отдельно для каждого случая

Друзья, всем привет! Подскажите, пожалуйста, как отключить ретраи процесса в камунде? есть процесс, у всех делегатов настроена обработка исключений. Если поймали исключение - уходим в соответствующую ветку. Но бывает случае, когда какой-нибудь делегат зависает (например при http запросе) и камунда решает сделать ретрай процесса. Как можно их вообще отключить?

Очень похоже на то, что нужно. Большое спасибо!

Коллеги, подскажите, может кто сталкивался. СкрипТаск через bpmnдвижок обрабатывает данные в БД в 10 раз медленнее чем запущенный такой же скрипт вне bpmn движка. Может что с настройками пошаманить надо. Запускали с одной и той же машины как отдельно так в процессе над БД на другой машине.

Надо пошаманить с навыком анализа производительности 😁
А если серьёзно, включите логи камунды в debug, они довольно подробные, посмотрите что как отрабатывает. Дальше анализ запроса в бд. Статистика, план выполнения. По другому вам только экстрасенс поможет)

Дамы и господа камунданты,

кто-нибудь пробовал подружить Камунду с Кложуром?

Т. е. чтобы можно было динамически (в REPL) менять код сервис-тасков (см. приложенную диаграмму)?

Ох... а это действительно хорошая идея?

> а это действительно хорошая идея?

It depends.

В плохо организованных командах такой способ разработки является воплощением принципа "фигак-фигак и в продакшен."

А если с процессами и дисциплиной все в порядке, то иногда такой способ прототипирования может очень даже пригодиться.

Пример из жизни:

1. На машине разработчика ряд сервисов, необходимых для работы процесса недоступны.
2. Поэтому проверять код он может только на сервере в DEV окружении.
3. Чтобы обновить приложение, новую версию джарника нужно сначала собрать, потом загрузить на нужный сервер через SFTP, потом в командной строке положить в правильную директорию, потом приложение перезапустить.

Если так работать, то затраты на обновление джарника будут тормозить разработку (особенно, если в процессе обновления разработчика кто-то дергает и тот забывает, на чем остановился).

Мне кажется, кейс который вы описали вполне покрывается юнит тестированием. А после прохождения оного подтверждается командой QA, интеграционным и e2e.

Если это нужно только на этапе разработки, то выглядит вообще как овернижиниринг. Но я конечно не знаю Ваших реалий.

Одна из реалий — мое желание, можно ли применить кложурный подход к разработке к Камунде. Я пробовал Кложур в одном личном проекте и иногда кажется, что на Кложуре разработка идет быстрее, чем на Джаве. Хочу проверить это на чем-то таком, что можно применить в работе.

Вот это уже аргумент ) 👍

А стоимость сопровождения и развития продукта в случае применения в продакшене прикидывали? Искать на рынке спецов на кложуре или переучивать имеющихся?

Пока нет.

Но по слухам, если человек умеет работать на Джаве, то переучиться на Кложур довольно легко. Я тоже раньше боялся скобок, но оказалось, что все не так страшно. Я к этому привык быстрее, чем ожидал.

Поддержка Кложура в Идее (Курсив) тоже помогает.

А в чем профит перед Джавой?

Способ разработки.

1. Есть код.
2. Есть REPL.
3. Написал кусочек кода, нажал кнопку и изменения поступили в REPL.
4. Запустил код, проверил, все ли работает.
5. Потом шаги 3-4 повторяются до тех пор, пока все не заработает.

Это чем-то похоже на PHP в 1990-х. Написал изменение, загрузил файл на сервер (либо UltraEdit сам это сделал) и сразу видно результат.

Возникает ощущение, что код пишется быстрее. Возможно, из-за того, что есть много маленьких успехов.