В общем виде задача сильно больно решается

да довели

это реально перенести на камунду, но вопрос на сколько это надо. Потому что это довольно большая и долгая разработка

ну и не только разработка

Всем привет.
Подскажите, пожалуйста, есть сервисТаск,  вызывает рест апи.
Почему то сервисТаск выполняется несколько раз. А в истории act_hi_actinst по этому сервисТаску одна запись. В каких случаях может выполнятся несколько раз?

В момент закрытия задачи, посылается complete, но из-за ошибки, например optimistic lock, задача не закрыта, идёт откат транзакции, и снова вызывается. Вторая причина - задача закрывается с failed и retry count больше 1, и она будет спамить, пока не поставишь retry count 0. Третья причина далее до следующей точки сохранения идёт какой то код, например script task, если в нем ошибка, на complete система не просто сохранят транзакцию о задаче а сразу и весь код до след точки сохранения,там идёт вылет и откат транзакции, и задача снова посворяется. Это наиболее часто возникающие повторы.

Спасибо большое! Только что прочитал о первом случае.

https://docs.camunda.org/manual/7.8/user-guide/process-engine/transactions-in-processes/#optimistic-locking

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

Есть один трюк, который позволяет почти всегда решить проблему optimistic locking. В момент сохранения и посылки события complete, нужно ловить код возврата. Если там есть engine error 500, optimistic locking, или любая другая ошибка, можно сразу до несколько раз повторить complete, и я у себя сделал лимит 3 попытки. Тогда этот вариант даже в стресс тестах, когда rest api перегружено, норм работает

Я так тоже делал, но это решение в стиле: "чем больше джип тем дальше идти за трактором" - в любом случае будут ситуации когда попыток нехватило

согласен, что оно не устраняет проблему на 100%, но 99% уходит. Не всегда повтор задачи приводит к катастрофе. А если может привести изза ну там двойного списания средств, то это нужно понимать что повтор возможен, и обработать на уровне самого внешнего модуля, обрабатывающего эту задачу.

Я это делал по другой причине. Если задачу не удается закомитить. Изза держания Exclusive lock например на 50 секунд, следующий повтор идет через минуту. Что резко замедляет скорость проходжения бизнес процесса по цепочке вызовов. Если этот фактор критичен (общее время выполнения бизнес процесса), то оно того стоит.

В базе в таблице act_hi_actinst наплодилось 5кк записей ивента из процесса. В чем может быть проблема?

Всем привет! Подскажите по скриптингу, плиз, почему-то когда-то давно мы у себя решили не использовать Groovy но оно нужно иногда пользую JS. (почему так - я не помню уже) Я правильно  понимаю, что вообще нет разницы, я буду Groovy использовать или JS внутри bpmn (знаю, что скрипты - зло, но пока что удобно)? (используем обычно в 2 кейсах - пихнуть переменку в какой-то JSON в контексте или подрезать переменку строковую)

разница только в том, есть ли в вашей системе в проде интерпретатор скриптов, в alpine помоему JS вырезан

контейнерозависимость это еще один повод отказаться от скриптов

У вас что-то зациклилось может?

Нет, просто ивент с условием висит

это следующий шаг

спасибо!