ок сп

Для старта проекта-бизнеса лучше использовать excel, а для зрелых компаний нанять аналитиков и разработчиков

ок сп

было бы хорошо, если в обзор также попадут activiti, jbpm, flowable.

Не, там разница сежду bpm engine и bpms

ясно. ну тогда если будет возможность, сравнение engine тоже было бы полезно.

В листе ожидания :)

+zebee

спасибо 👍

Вы от тинькоффбанка?. мне просто интересно тб платит на поддержку и за фичи в камунде?

Не платит

ок

а то потом будет как с nginx ))

?

ну я про рамблер, который наехал на своего сотрудника спустя годы

Это как раз таки понятно) не понятно причем тут эта ситуация в контексте разговора

ну, мне так показалось )

Привет всем!

Еще одна ситуация по исполнению процесса в Camunda.

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

В табличке act_hi_job_log до этого момента все ок - одна запись со статусом (job_state_) = 0 (created).
Ветка одна, нет параллельных веток до таски Wait.

Далее, срабатывает таймер через Х дней, и ветка процесса отрабатывает 2 раза.
В табличке act_hi_job_log - две записи, одна из которых со статусом = 2 (success),
другая - со статусом 1 (failure), и job_exception_msg_ = 'ENGINE-03005 Execution of 'DELETE TimerEntity[xxxxxx]' failed. Entity was updated by another transaction concurrently'.

Соот-но вторая ветка завершается неуспешно.

Но даже в этом случае выполняются таски Call service X, Call service Y и далее по ветке.

Конфиги Camunda - все по дефолту.
Причем данная ситуация достаточно редкая.

Подскажите, кто сталкивался с таким, в чем может быть причина срабатывания таймера более 1 раза,
что можно донастроить, чтобы ветка отрабатывала гарантированно 1 раз ?
(версия Camunda = 7.10, поднята в OpenShift, смасштабирована в 4 пода)

А почему используется boundary event, а не catch event? Может ли таска из-за этого завершаться дважды?