Differimento dei messaggi
Quando un client di coda o di sottoscrizione riceve un messaggio che è disposto a elaborare, ma l'elaborazione non è attualmente possibile a causa di circostanze particolari, ha la possibilità di "rinviare" il recupero del messaggio in un secondo momento. Il messaggio rimane nella coda o nella sottoscrizione, ma viene messo da parte.
Nota
I messaggi posticipati non vengono scaduti e spostati automaticamente in una coda di messaggi non recapitabili fino a quando un'app client non tenta di riceverli usando un'API e il numero di sequenza. Questo comportamento è impostato a livello di progettazione. Quando un client tenta di recuperare un messaggio posticipato, viene verificata la condizione scaduta e spostata in una coda di messaggi non recapitabili se è già scaduta. Un messaggio scaduto viene spostato in una coda secondaria non recapitabili solo quando la funzionalità di messaggi non recapitabili è abilitata per l'entità (coda o sottoscrizione).
Scenari di esempio
Il rinvio è una funzionalità creata in modo specifico per gli scenari di elaborazione del flusso di lavoro. I framework del flusso di lavoro potrebbero richiedere l'elaborazione di determinate operazioni in un ordine specifico. Potrebbe essere necessario posticipare l'elaborazione di alcuni messaggi ricevuti fino a quando non sono state completate le operazioni precedenti informate da altri messaggi.
Un semplice esempio illustrativo è dato da una sequenza di elaborazione degli ordini in cui la notifica di pagamento del fornitore esterno dei servizi di pagamento viene visualizzata in un sistema prima che l'ordine di acquisto corrispondente sia stato propagato dal negozio al sistema di evasione degli ordini. In tal caso, il sistema di evasione potrebbe rinviare l'elaborazione della notifica di pagamento fino a quando non è presente un ordine con cui associarlo. Negli scenari di incontro, in cui i messaggi provenienti da origini diverse indirizzano un flusso di lavoro in avanti, l'ordine di esecuzione in tempo reale potrebbe effettivamente essere corretto, ma i messaggi che riflettono i risultati potrebbero arrivare fuori ordine.
Il differimento consente di riordinare i messaggi, sostituendo l'ordine di arrivo con un ordine in cui possono essere elaborati, lasciando nell'archivio i messaggi per cui l'elaborazione deve essere posticipata.
Se non è possibile elaborare un messaggio perché una particolare risorsa per la gestione del messaggio è temporaneamente non disponibile, ma l'elaborazione dei messaggi non deve essere sospesa in modo riepilogo, un modo per inserire tale messaggio sul lato per alcuni minuti consiste nel ricordare il numero di sequenza in un messaggio pianificato da pubblicare in pochi minuti e recuperare nuovamente il messaggio posticipato quando arriva il messaggio pianificato. Se un gestore di messaggi dipende da un database per tutte le operazioni e tale database non è temporaneamente disponibile, non deve usare rinvio, ma sospendere completamente la ricezione dei messaggi fino a quando il database non sarà nuovamente disponibile.
Recupero di messaggi posticipati
I messaggi posticipati rimangono nella coda principale insieme a tutti gli altri messaggi attivi (a differenza dei messaggi non recapitabili che risiedono in una coda secondaria), ma non possono più essere ricevuti usando le normali operazioni di ricezione. I messaggi posticipati possono essere individuati tramite l'esplorazione o la visualizzazione di messaggi se un'applicazione perde traccia di tali messaggi.
Per recuperare un messaggio posticipato, il proprietario è responsabile della memorizzazione del numero di sequenza mentre lo sfida. Qualsiasi ricevitore che conosce il numero di sequenza di un messaggio posticipato può ricevere successivamente il messaggio usando metodi di ricezione che accettano il numero di sequenza come parametro. Per altre informazioni sui numeri di sequenza, vedere Sequenziazione dei messaggi e timestamp.
Passaggi successivi
Provare gli esempi nel linguaggio preferito per esplorare bus di servizio di Azure funzionalità.
- bus di servizio di Azure esempi di libreria client per .NET (versione più recente): vedere l'esempio di Settling Messages.
- esempi di libreria client bus di servizio di Azure per Java (versione più recente)
- bus di servizio di Azure esempi di libreria client per Python. Vedere l'esempio di receive_deferred_message_queue.py.
- bus di servizio di Azure esempi di libreria client per JavaScript: vedere l'esempio avanzato/deferral.js.
- bus di servizio di Azure esempi di libreria client per TypeScript: vedere l'esempio avanzato/deferral.ts.
Vedere gli esempi per le librerie client .NET e Java precedenti qui:
- bus di servizio di Azure esempi di libreria client per .NET (legacy) - Vedere l'esempio di rinvio.
- esempi di libreria client bus di servizio di Azure per Java (legacy)
Il 30 settembre 2026 verranno ritirate le librerie dell'SDK del bus di servizio di Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, che non sono conformi alle linee guida di Azure SDK. Verrà terminato anche il supporto del protocollo SBMP, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti di Azure SDK, che offrono aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.
Anche se le librerie precedenti possono ancora essere usate oltre il 30 settembre 2026, non riceveranno più il supporto e gli aggiornamenti ufficiali da Microsoft. Per altre informazioni, vedere l'annuncio del ritiro del supporto.