В принципе, можно в методе sendEmailToRecipients ( https://github.com/jit-open/email-incident-notification-plugin/blob/master/src/main/java/at/jit/incidentlistener/BufferingIncidentHandler.java ) вместо

final String messageText = composeMessage(incidents);

      final boolean emailSent = sendEmail(recipientInfo, messageText);

вставить REST-запрос Прометею.

Всем привет!

В чем может быть дело, есть процесс, на задачах везде указана группа в Candidate Group. Все работает норм. Но когда сделал одну из задач подпроцессом, то на задачах, которые идут после этого подпроцесса identity-links возвращается пустой, хотя на диаграме все проставлено.

На задачах до подпроцесса, внутри подпроцесса тоже проставлено в Candidate Groups и там identity-links возвращается как и ожидается.

мне тут подумалось, что Send/Receive для запроса в асинхронную систему и получения ответа от неё не такой уж и костыль:

если мы хотим тру асинхронность, чтобы "отправили запрос - пока ждём ответа, делаем какие-то другие дела в том же процессе - получили ответ", то всё равно придётся разветвлять и тогда схемы с External vs. Send/Receive уже выглядят примерно на равных

только с Send/Receive не придётся писать отдельно стоящий @ Scheduled поллер для External тасков, связь которого со схемой процесса не сразу очевидна в коде

1) По этому процессу у тебя ответ в любое время может прилететь, даже до отправки запроса. Если это бизнесово так - то ок 2) если завтра вызываемая система переедет с очередей на rpc call то это или схему заденет или нужно будет писать адаптер на очередях, а схема будет изображать псевдоасинхрон непонятный

1) ответ коррелируется по uuid, который уникален для запроса из этого экземпляра процесса, так что асинхронный ответ, по такой логике, не может прийти раньше (вероятность коллизий uuid ничтожно мала)

2) у нас как-то так сложилось, что всем удобно видеть на схеме не что-то абстрагированное верхнеуровневое, а вполне конкретное; так что то, что синхронное и асинхронное взаимодействие на схеме рисуются по-разному, для нас нормально и даже желанно :)

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

2) И тем не менее это засорение схемы бизнес-процесса подробностями технической реализации. Различать синхронное и асинхронное можно помечая разными значками (Service Task, Send task).  А отдельно стоящий @ Scheduled поллер для External тасков совсем не обязательно. Делали реализацию со спринговыми эвентами и @ TransactionalEventListener с взаимодействием через MQ, т.к. идея поллера не понравилась сразу.

Помечать что угодно можно комментами. Вызываемые системы, виды взаимодействия. А бизнес процесс оставлять на максимально бизнесовом уровне абстракции. Иначе там смесь начинается абстракций, в этом шаге мы создаем заявку, а в этом дергаем систему system23. Это тож самое как посреди бизнес когда вызывать сокеты

Доброе утро, в каком формате в процессе указывается history time to live? Допустим, если нужно указать один день, то просто устанавливаем значение в 1? И удалятся ли старые процессы?

Доброе. В документации написано, что формат ISO 8601.
Проставлением просто history time to live ничего не удалится. Просто этот дюрейшен будет добавляться к дате и писаться в колонку(END_TIME_ или REMOVAL_TIME, зависит от выбранной стратегии) в исторических таблицах

А дальнейшие инструкции какие?

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

https://docs.camunda.org/manual/latest/user-guide/process-engine/history/#history-cleanup
Лучше всего изучить документацию по этому вопросу

Я пытался следовать документации, вызывал разные апишки, по итогу ничего особо и не заработало

Там следует понимать, что процессы привязываются в версии модели или копии, ну например вы создавали рабочую модель много раз ее запускали удаляя старую и пересоздавая. Если при этом вы не укажете признак cascade то связанные исполненные процессы так и останутся висеть в бд. вообще в бд есть один фоновый процесс batch job который этим занимается. Фактически вам по логам нужно увидеть что он работает

Допустим, у меня есть несколько версий одного и того же процесса и я хочу удалить всё, что было позднее одного месяца, даже если этот процесс относится к старой версии

Ты хочешь удалить process definition или history process instance?

History process instance

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