7 долларов? Это тариф с 512мб оперативы?

Честно говоря, не знаю, сколько там памяти. Но Камунда работает.

ну просто за эти деньги можно взять вдс в весьма дорогих Российских компаниях с 2 и более гигами оперативы)

Это не просто хостинг. Вся прелесть в том, что там из коробки есть CI/CD — обновления можно разворачивать, делая git push в хранилище Хероку.

эт понятно)

впрочем. Портейнер позволяет делать автодеплой с любого хранилища. Тот же бесплатный jetbrain space

Спасибо. Я про эти сервисы не знал.

ну там надо будет самому настраивать, разумеется)

В camunde есть у UserTask два параметра " Due Date" и "Follow Up Date". Для чего используется второй параметр?

Кроме как вариант указать временной интервал ничего в голову не приходит

https://docs.camunda.org/manual/7.15/reference/bpmn20/tasks/user-task/#follow-up-date

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

> Each task has a field indicating the follow up date of that task. The Query API can be used to query for tasks that need to be followed up on, before or after a certain date.

В документации я нашел одно отличие между ними: Якобы, due date  можно менять с помощью TaskService или TaskListeners, а follow up date — нет. Во всяком случае такого абзаца у follow up date нет.

Теоретический пример, когда нужно и то и другое:

Допустим, отчет по доходам надо сдать 15-го марта. Этим занимается бухгалтер. А первого марта надо проверить, сделал ли он его и при необходимости пнуть.

В этом случае dueDate -- 15-е марта, follow up date -- 1-е марта.

Может кто подскажет каким образом решается кейс когда есть SLA на конкретные задачи подпроцессов, сам подпроцесс и SLA на сам родительский процесс, состоящий из этого множества подпроцессов. Заказчик хочет в web-интерфейсе видит при взятии задачи в работу как срок по самой задаче (относительный от даты наступления), срок по подпроцессу с учётом выполнения срока по родительскому процессу (своеобразный KPI).

Нативно в бпмн никак, https://bpmn2.ru/vremya-%D0%B2-bpmn/ придумывать костыли

Собирайте метрики start/end  нужных активити. Вариантов много: history, listeners и подобное. Выберите подходящий вам способ

Единственным решением пока видится это хранение и перерасчёт всего этого в своих таблицах БД с выводом на фронт

> Что могло бы сделать Камунду еще лучше?

Писать и издавать книжку "Camunda для детей", собирать фидбэк от читателей и 5% ресурсов разработки направлять на улучшения, подсказанные читателями или навеянные их отзывами

Камундаводу на заметку

На время, за которое job executor подбирает процесс и начинает его обрабатывать влияют такие настройки как maxWait и maxBackoff.

Пример боевой конфигурации:

camunda:
  bpm:
    job-execution:
      deployment-aware: true
      core-pool-size: 3
      max-pool-size: 15
      max-jobs-per-acquisition: 3
      wait-time-in-millis: 5000
      lock-time-in-millis: 300000

Детали: https://docs.camunda.org/manual/7.15/reference/deployment-descriptors/tags/job-executor/#job-acquisition-configuration-properties

Если проставить эти параметры забыли, а потом Камунда перестала запускать процессы из-за exponential backoff timing, то помогает удаление деплойментов.

Job executor на то и job, что выполняет job'ы, а не процессы 😉

А опишите, пожалуйста, как воссоздать ваш кейс. Если я правильно понимаю, то backoff должен увеличиваться на ожидающем потоке, при этом должен (по идее) оставаться работающий поток, который в это время собственно и лочит