Возможность гарантировать, что сообщение было успешно отправлено в концентратор событий из APIM - PullRequest
0 голосов
/ 16 июня 2019

Можно ли гарантировать, что сообщение было успешно доставлено в концентратор событий при отправке с помощью политики log-to-eventhub в управлении API?

Изменить: В нашем решении мы не можем разрешить выполнение любого запроса, если сообщение не было доставлено в концентратор событий. Насколько я могу судить, политика log-to-eventhub не проверяет это.

Ответы [ 2 ]

0 голосов
/ 24 июня 2019

Концентраторы событий построены поверх служебной шины. Согласно сервисной шине документация ,

Используя любой из поддерживаемых клиентов API служебной шины, операции отправки в служебную шину всегда устанавливаются в явном виде, что означает, что операция API ожидает получения результата приема от сервисной шины, а затем завершает операцию отправки.

Если сообщение отклонено служебной шиной, отклонение содержит индикатор ошибки и текст с идентификатором отслеживания внутри него. Отклонение также включает в себя информацию о том, можно ли повторить операцию, ожидая успеха. В клиенте эта информация превращается в исключение и передается вызывающей стороне операции отправки. Если сообщение было принято, операция молча завершается.

При использовании протокола AMQP, который является эксклюзивным протоколом для клиента .NET Standard и Java-клиента и является опцией для клиента .NET Framework, передача сообщений и расчеты являются конвейерными и полностью асинхронными, и рекомендуется что вы используете варианты API модели асинхронного программирования.

Отправитель может быстро разместить несколько сообщений в сети, не дожидаясь подтверждения каждого сообщения, как в случае с протоколом SBMP или HTTP 1.1. Эти асинхронные операции отправки завершаются, когда соответствующие сообщения принимаются и сохраняются, на разделенных объектах или когда операции отправки на другие объекты перекрываются. Завершения также могут происходить из исходного заказа на отправку.

Я думаю, это означает, что SDK получает квитанцию ​​за каждое сообщение.

Этой теории дополнительно помогает класс RetryPolicy , используемый в свойстве ClientEntity.RetryPolicy класса EventHubSender .

В разделе Управление API на loging-to-eventhub есть также раздел о интервалах повторов. Ниже приведены разделы, посвященные изменению ответа на запрос или выполнению действий с определенными кодами состояния. После того, как коды состояния неудачной попытки записи в журнал станут известны, вы можете изменить политики, чтобы они действовали при неудачных попытках регистрации.

0 голосов
/ 17 июня 2019

Добро пожаловать в Stackoveflow!

Примечание: После передачи данных в концентратор событий они сохраняются и будут ждать, пока потребители концентратора событий их обработают.Event Hub не заботится о том, как он обрабатывается;он просто заботится о , чтобы убедиться, что сообщение будет успешно доставлено .

Подробнее см. в разделе « Зачем отправлять в концентратор событий Azure? ».

Надеюсь, это поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...