Сервисная шина Azure - добавление сообщения в очередь в отложенном состоянии

Question

Мне интересно, можно ли отправить посредническое сообщение в очередь / тему, где сообщение уже находится в отложенном состоянии?

Я спрашиваю об этом, потому что в настоящее время у меня есть процесс, который выполняетследующее ...

1. Процесс начинается, и сообщение с посредником отправляется в очередь (при этом запускается функция, которая записывает тело сообщения как сущность в хранилище таблицы со статусом «Обработка»).
2. В процессе выполняется дополнительная работа
3. Если мы дойдем до конца процесса без каких-либо проблем, другое очередное сообщение отправляется в очередь с сообщением о завершении (это вызывает ту же функциюэто обновляет сущность в хранилище таблиц со статусом «Завершено»).

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

Я думал о настройкеScheduledEnqueueTimeUtc, но я не могу гарантировать, когда процесс завершится (я думаю, здесь наихудший сценарий), поэтому я не уверен, как долго его устанавливать.

Я также посмотрел на *Опция 1018 * для BrokeredMessage, но, похоже, это может быть установлено только с приемника и изначально не может быть в отложенном состоянии.

Возможно ли то, что я пытаюсь сделать с помощью сообщений брокера Service Bus?Могу ли я установить время запланированной постановки в очередь на какое-то смехотворно долгое время (например, 2 часа), и если оно достигает этого времени, оно автоматически истекает и перемещается в очередь мертвых писем?Должен ли я отправлять начальное сообщение в очередь мертвых писем, а затем, когда процесс будет завершен, извлечь его и отправить повторно?

Кто-нибудь имел опыт реализации такого процесса ... отправить сообщение запуска иобрабатывать сообщение только после получения уведомления о завершении?Мне нужно, чтобы это было как можно более надежным, так как я имею дело с финансовыми транзакциями в этом процессе.

Надеюсь, мое объяснение имеет смысл.

Answer 1

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

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

Answer 2

Мне интересно, можно ли отправить посредническое сообщение в очередь / тему, где сообщение уже находится в отложенном состоянии?

Это невозможно.Вы можете только отложить новое сообщение, но не отложить его.При отсрочке требуется, чтобы сообщение было получено первым, чтобы оно имело SequenceNumber.

Использование ScheduledEnqueueTimeUtc сопряжено с трудностями, поскольку вы будете отправлять его в будущем, но не сможете отменить его после завершения обработки.Вместо этого вы можете использовать QueueClient.ScheduleMessageAsync(), который немедленно возвращает обратно SequenceNumber.Таким образом, вы можете установить сообщение далеко в будущее, но также отменить его, если обработка завершена раньше.