Adiamento de mensagens

Quando um cliente de fila ou assinatura recebe uma mensagem que está disposto a processar, mas o processamento não é possível no momento devido a circunstâncias especiais, ele tem a opção de “adiar” a recuperação da mensagem para um ponto posterior. A mensagem permanece na fila ou assinatura, mas é reservada.

Observação

As mensagens adiadas não expiram e são movidas automaticamente para uma fila de mensagens mortas até que um aplicativo cliente tente recebê-las usando uma API e o número de sequência. Esse comportamento é por design. Quando um cliente tenta recuperar uma mensagem adiada, ele é verificado quanto à condição expirada e movido para uma fila de mensagens mortas se já tiver expirado. Uma mensagem expirada é movida para uma subfila de mensagens mortas, somente quando o recurso de mensagens mortas está habilitado para a entidade (fila ou assinatura).

Exemplo de cenários

O adiamento é um recurso especificamente criado para cenários de processamento de fluxo de trabalho. As estruturas de fluxo de trabalho podem exigir que determinadas operações sejam processadas em uma ordem específica. Talvez seja necessário adiar o processamento de algumas mensagens recebidas até que o trabalho anterior prescrito informado por outras mensagens tenha sido concluído.

Um exemplo ilustrativo simples é uma sequência de processamento de ordem em que uma notificação de pagamento de um provedor de pagamento externo aparece em um sistema antes que a ordem de compra correspondente tenha sido propagada da frente da loja para o sistema de atendimento. Nesse caso, o sistema de atendimento pode adiar o processamento da notificação de pagamento até que haja um pedido ao qual associá-la. Em cenários de reunião, em que mensagens de origens diferentes movem o fluxo de trabalho adiante, a ordem de execução em tempo real pode realmente estar correta, mas as mensagens refletindo os resultados podem chegar fora de ordem.

Por fim, o adiamento ajuda na reordenação das mensagens da ordem de chegada em uma ordem na qual elas possam ser processadas, deixando essas mensagens com segurança no repositório de mensagens para as quais o processamento precisa ser adiado.

Se uma mensagem não puder ser processada porque um recurso específico para lidar com essa mensagem está temporariamente indisponível, mas o processamento de mensagem não pode ser suspenso sumariamente, uma maneira de colocar essa mensagem de lado por alguns minutos é lembrar o número de sequência em uma mensagem agendada para ser postada em alguns minutos, e recuperar a mensagem adiada novamente quando a mensagem agendada chegar. Se um manipulador de mensagens depender de um banco de dados para todas as operações e o banco de dados estiver temporariamente indisponível, ele não deverá usar o adiamento, mas suspender o recebimento de mensagens completamente até o banco de dados estar disponível novamente.

Recuperando mensagens adiadas

As mensagens adiadas permanecem na fila principal junto a todas as outras mensagens ativas (ao contrário de mensagens mortas que residem em uma subfila), mas elas não podem mais ser recebidas usando as operações de recebimento regulares. Mensagens adiadas podem ser descobertas por meio da procura ou espionagem de mensagens, se um aplicativo perder o controle delas.

Para recuperar uma mensagem adiada, seu proprietário é responsável por memorizar o número de sequência conforme ele a adia. Todo destinatário que conhecer o número de sequência de uma mensagem adiada pode receber a mensagem mais tarde usando métodos recebimento que usam o número de sequência como um parâmetro. Para obter mais informações sobre números de sequência, consulte Sequenciamento de mensagem e carimbos de data/hora.

Próximas etapas

Experimente os exemplos no idioma de sua escolha para explorar os recursos do Barramento de Serviço do Azure.

Veja exemplos de bibliotecas de clientes .NET e Java mais antigas aqui:

Em 30 de setembro de 2026, desativaremos as bibliotecas do SDK do Barramento de Serviço do Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, que não estão em conformidade com as diretrizes do SDK do Azure. Também encerraremos o suporte ao protocolo SBMP, portanto, ele não poderá mais ser usado após 30 de setembro de 2026. Antes dessa data, migre para as bibliotecas mais recentes do SDK do Azure, que oferecem atualizações de segurança críticas e funcionalidades aprimoradas.

Embora as bibliotecas mais antigas ainda poderão ser usadas após 30 de setembro de 2026, elas não receberão mais suporte e atualizações oficiais da Microsoft. Para obter mais informações, confira o anúncio de desativação do suporte.