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

Question

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

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

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

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

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

Я также посмотрел на Defer вариант для BrokeredMessage но кажется, что это может быть установлено только от приемника и не может быть первоначально в отложенном состоянии.

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

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

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

Answer 1

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

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

Answer 2

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

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

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