IB
Но tl;dr - не надо ставить сенд таску, а за ней ресив для ожидания ответа)
Size: a a a
2020 November 08
IB
DK
Но tl;dr - не надо ставить сенд таску, а за ней ресив для ожидания ответа)
Надо параллельно ставить
AD
У нас есть в продакшне проект, где асинхронное взаимодействие с внешними системами реализовано на парах send-receive тасок, там регулярно сыплются ошибки из-за того что, когда запрос вовне отрабатывает слишком быстро, процесс не успевает повиснуть на ресив таске, и движок ругается, что некого с неё сталкивать. Мы долго думали, что и почему, судя по всему, это в принципе архитектурно неправильное использование ресив таски, и в этом случае делать надо только через external
Мы в итоге решаем проблему ретраями (обычно на 4-5 раз процесс уже получается протолкнуть), где-то на форуме ещё был вопрос на эту тему, там разраб из камунды в качестве ва предлагает ставить таски в параллельный гейтвей и ещё галочку асинхронности на сенд таску
Мы в итоге решаем проблему ретраями (обычно на 4-5 раз процесс уже получается протолкнуть), где-то на форуме ещё был вопрос на эту тему, там разраб из камунды в качестве ва предлагает ставить таски в параллельный гейтвей и ещё галочку асинхронности на сенд таску
Спасибо, эта проблема нам тоже известна.
Как у вас был ресив сервис реализован? Вызываемый сервис слал ответ в процес через Camuy Rest API или через вебСервис, который пытался скорелировать ответ в процес ?
Как у вас был ресив сервис реализован? Вызываемый сервис слал ответ в процес через Camuy Rest API или через вебСервис, который пытался скорелировать ответ в процес ?
IB
Надо параллельно ставить
Ну да, я скинул как раз пост про это с форума
IB
Artur Dauer
Спасибо, эта проблема нам тоже известна.
Как у вас был ресив сервис реализован? Вызываемый сервис слал ответ в процес через Camuy Rest API или через вебСервис, который пытался скорелировать ответ в процес ?
Как у вас был ресив сервис реализован? Вызываемый сервис слал ответ в процес через Camuy Rest API или через вебСервис, который пытался скорелировать ответ в процес ?
Там была пара очередей от ядра, где бегает камунда, к адаптерам для каждой внешней системы
IB
Сообщение поступало в выходную очередь, и мы коррерировались по message name и бизнес ключу
IB
Короче, скорее второй вариант, рест апи мы не юзали
IK
блин как-то сложно с мессаджами на концептуальном уровне, не понятно тогда где их использовать вообще можно как промежуточные
IB
Что имеешь в виду под "промежуточные" ?
IK
не баундари и не стартовые ресив эвенты. Там же всегда ожидание будет чего-то что происходит в ответ на что-то что произошло раньше. и всегда без корреляции будет гонка
или нужно говорить что мы их можем использовать только если вторую часть процесса которая их шлет контроллируем или делать хитрые технические схемы
или нужно говорить что мы их можем использовать только если вторую часть процесса которая их шлет контроллируем или делать хитрые технические схемы
IB
2 примера сразу из текущего проекта, делаем синхронную обработку банковского платежа. В схеме есть проверка, идёт ли закрытие операционного дня, если идёт - то встаём на ресив таску (не баундари, посреди процесса), ждём пока прилетит уведомление о том, что можно продолжать процессить платёж
IB
В конце ставим, чтобы сформировать ответ фронту, используя переменные из контекста бпмнного, когда сформировали - кидаем сообщение, процесс завершается
IB
Хотя насчёт второго я не уверен, насколько это концептуально правильно, просто лучше ничего в голову с ходу не пришло
IK
если я правильно понял "проверить что опердень не на закрытии" -> "если на закрытии" -> "ждать когда закрытие завершиться"?
IK
если закрытие завершиться пока едет токен в серединке - произойдет тоже потеря, которую нужно обрабатывать
ну то есть это атомарный какой-то шаг должен быть "проверить и дождаться если еще не настало"
ну то есть это атомарный какой-то шаг должен быть "проверить и дождаться если еще не настало"
IB
если я правильно понял "проверить что опердень не на закрытии" -> "если на закрытии" -> "ждать когда закрытие завершиться"?
+
IK
*я если что могу говорить полную чушь т.к. только вникаю
IB
если закрытие завершиться пока едет токен в серединке - произойдет тоже потеря, которую нужно обрабатывать
ну то есть это атомарный какой-то шаг должен быть "проверить и дождаться если еще не настало"
ну то есть это атомарный какой-то шаг должен быть "проверить и дождаться если еще не настало"
Да, такое чисто теоретически может быть, но шанс крайне мал)
IK
ну блин) везде это вероятностное программирование