Size: a a a

Camunda BPM Group

2019 December 19

SD

Serg D. in Camunda BPM Group
Если мы в БП используем автоматизированные системы мы в любом случае сталкиваемся с возможными техническими проблемами. Т.е. мы, как мне кажется, должны ожидать что БП не может быть завершён и эта ситуация должна быть как-то отработана с пониманием причин инцидента. Нет?
источник

DK

Denis Kotov in Camunda BPM Group
Конечно. Но как это касается непосредственно схем?
источник

DK

Denis Kotov in Camunda BPM Group
Отработка технических ошибок техническим же способом на схемах - путь в никуда.
источник

SP

Sergey Potekhin in Camunda BPM Group
Такой стиль называется "Программирование на Камунде"
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
Sergey Potekhin
Такой стиль называется "Программирование на Камунде"
оу, я назвал его для себя "программрование на BPMN")
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
имхо так себе вариант, для этого есть более удобные инструменты (C#, Java) + паттерны (retry, saga)
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
а некоторые вообще "забивают" на ошибки) если инфраструктура позволяет держать процент ошибок на удовлетворительном уровне
источник

SP

Sergey Potekhin in Camunda BPM Group
источник

SP

Sergey Potekhin in Camunda BPM Group
источник

SD

Serg D. in Camunda BPM Group
Ну ок, добавим конкретики, есть некий экстернал таск. Он внутри получает техническую ошибку. Ретраи, тайм-ауты, залогировали. И что дальше? Бизнесово задача не выполнена, что я должен выкинуть наверх в схему?
источник

SP

Sergey Potekhin in Camunda BPM Group
Ну как вариант, вызов внешней обработки делать через брокер сообщений. Из обработчика возвращать два вида колбеков : нормальный и с признаком ошибки. Нормальный закрывает таску, а ошибочный инициирует обработку.
источник

SP

Sergey Potekhin in Camunda BPM Group
И все это за кулисами сбоку, не в схеме процесса
источник

SP

Sergey Potekhin in Camunda BPM Group
Если уж совсем по феншую, то ошибочный колбек может стартавать процесс обслуживания инцидента, в котором специальные люди пофиксят данные или код, а экстернал таск будет просто ждать, пока не прилетит долгожданный Complete колбэк
источник

DK

Denis Kotov in Camunda BPM Group
Serg D.
Ну ок, добавим конкретики, есть некий экстернал таск. Он внутри получает техническую ошибку. Ретраи, тайм-ауты, залогировали. И что дальше? Бизнесово задача не выполнена, что я должен выкинуть наверх в схему?
что за задача?
источник

DK

Denis Kotov in Camunda BPM Group
наверх в схему надо выкинуть инцидент
источник

SD

Serg D. in Camunda BPM Group
Sergey Potekhin
Если уж совсем по феншую, то ошибочный колбек может стартавать процесс обслуживания инцидента, в котором специальные люди пофиксят данные или код, а экстернал таск будет просто ждать, пока не прилетит долгожданный Complete колбэк
Экстернал таск же не будет просто ждать. Рано или поздно истечет lock и он отправится на выполнение повторно.
источник

SD

Serg D. in Camunda BPM Group
Denis Kotov
наверх в схему надо выкинуть инцидент
Ок. Тут яснее. крутимся на ретраях, а оповещаем и инициируем работы под копотом в коде, спасибо
источник

DG

Dmitrii Goncharov in Camunda BPM Group
Sergey Potekhin
Если уж совсем по феншую, то ошибочный колбек может стартавать процесс обслуживания инцидента, в котором специальные люди пофиксят данные или код, а экстернал таск будет просто ждать, пока не прилетит долгожданный Complete колбэк
Мы так сделали. Ответ с ошибкой стартует процесс обработки, для специального человека возникает задача и он решает, что делать дальше.
источник

SD

Serg D. in Camunda BPM Group
Что подразумевается под "ответ с ошибкой"? то, что по идее должно было бы быть обработано через externalTaskService.handleBpmnError?
источник

DG

Dmitrii Goncharov in Camunda BPM Group
Serg D.
Что подразумевается под "ответ с ошибкой"? то, что по идее должно было бы быть обработано через externalTaskService.handleBpmnError?
Не все ошибки должны отражаться в схеме. В данном случае имеются ввиду технические ошибки, которым не место в схеме.
источник