И что тут понятнее ?? Представь во внутренней рамке имеется 20 тасков, каждый из которых может бросить BPMError и когда это произойдет ты не будешь видеть какой шаг/таск выкинул bpmError.
И предложений тобой вариант имеет другой посыл, чем тот что в примере приведен - верхняя ветка это задача обрабатывается автоматически, а нижняя ветка это когда задача по какой то причине не обработана и должна например в ручную обработку идти!
А в твоём примере задача имеет одну сущность

Это решение тоже отличное решения для определенных задач, так же есть и должны быть другие подходы

Напиши в camunda, что мы в телеграмме не согласны с этим подходом

Хотя эта модель альтернатива для твоего и моего предложения и должно решить проблему с CallActivity

Вы меня неправильно поняли. Я никогда не оперирую понятием "верный" подход. Потому что сколько мнений столько и верных подходов. Я лишь исходжу из наглядности диаграммы для читателя. Лишь по этому поводу было возражение. Если для вас этот метод является наглядным и те кто будут смотреть эту диаграмму тоже скажут я все понял. Я не вижу никаких проблем с этим. Пользуйтесь так как вам удобно

Так мы и учимся 😉

Всем привет! Прошу помощи, подскажите, можно ли как-то завести счетчик повторов только средствами диаграммы?

Да, легко. Если очень хочется. Добавьте переменную в контекст и инкрименьте её при каждом повторе

Но в целом это не ответственность бизнес процесса

Нужно стараться избегать таких решений. Это нужно техническими средствами обрабатывать, а не камундой

Ретрай возник изза деталей реализации - идет продюсинг в кафку и если в момент обработки консюмер (в другой системе) киляют или он сам падает, то событие в принципе теряется. Показалось логичным контроллить процесс именно с диаграммы.
Где я допустил ошибку?

Ну это особенности реализации, не надо их тащить на схему, а то визуальное программирование будет

А не бизнес процессы

Но я сектант бизнес-процессов, у нас в секте свои загоны

В этом умозаключении) технически обрабатывайте отправку в кафку, в делегате делайте .get()  и дожидайтесь подтверждения отправки

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

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

А раз уж коснулись прогнозов - почему со слезами?

Потому что написать ретрай супер правильно на BPMN с первого раза скорее всего не получится)

Легче на java все сделать, там наверняка либы уже готовые есть