Esplorare o visualizzare in anteprima i messaggi
L'esplorazione (o visualizzazione in anteprima) dei messaggi consente a un client del bus di servizio di enumerare tutti i messaggi presenti in una coda o in una sottoscrizione a scopo diagnostico o di debug.
L'operazione Peak eseguita su una coda o una sottoscrizione restituisce al massimo il numero di messaggi richiesto. Nella tabella seguente sono riportati i tipi di messaggi restituiti dall'operazione Peak.
Tipo di messaggi | Incluso |
---|---|
Messaggi attivi | Sì |
Messaggi non recapitabili | No |
Messaggi bloccati | Sì |
Messaggi rinviati | Sì |
Messaggi scaduti | Probabilmente (prima del loro inserimento nella coda di messaggi non recapitabili) |
Messaggi pianificati | Sì per le code No per le sottoscrizioni |
Messaggi non recapitabili
Per visualizzare in anteprima i messaggi non recapitabili di una coda o di una sottoscrizione, l'operazione Peak deve essere eseguita nella coda dei messaggi non recapitabili associata alla coda o alla sottoscrizione. Per altre informazioni, vedere Accesso alle code di messaggi non recapitabili.
Messaggi scaduti
I messaggi scaduti potrebbero essere inclusi nei risultati restituiti dall'operazione Peak. I messaggi usati e scaduti vengono puliti da un'esecuzione asincrona di "Garbage Collection". Questo passaggio non necessariamente potrebbe verificarsi subito dopo la scadenza dei messaggi. Ecco perché un'operazione Peak potrebbe restituire messaggi che sono già scaduti. Questi messaggi verranno rimossi o impostati come non recapitabili quando successivamente viene richiamata un'operazione di ricezione nella coda o nella sottoscrizione. Tenere presente questo comportamento quando si tenta di recuperare i messaggi rinviati dalla coda.
Un messaggio scaduto non è più idoneo per il recupero normale con qualsiasi altra modalità, anche se viene restituito dal metodo Peek. La restituzione di questi messaggi è un'operazione predefinita, dato che il metodo Peek è uno strumento di diagnostica che visualizza lo stato attuale del log.
Messaggi bloccati
Il metodo Peek restituisce anche i messaggi bloccati attualmente elaborati da altri ricevitori. Tuttavia, poiché l'operazione Peak restituisce uno snapshot disconnesso, lo stato di blocco di un messaggio non può essere osservato nei messaggi visualizzati.
Messaggi rinviati
I messaggi rinviati rimangono nella coda principale insieme a tutti gli altri messaggi attivi (a differenza dei messaggi non recapitabili che rimangono in una coda secondaria), ma non possono essere più ricevuti usando le normali funzioni di ricezione. I messaggi rinviati possono essere individuati tramite l'esplorazione dei messaggi se un'applicazione ne perde traccia.
Per recuperare un messaggio rinviato, il proprietario deve ricordarsi il numero di sequenza perché si tratta dell'informazione in base alla quale il messaggio viene rinviato. Qualsiasi ricevitore che conosce il numero di sequenza di un messaggio rinviato 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.
API Peek
Il metodo Peek funziona nelle code, nelle sottoscrizioni e nelle rispettive code di messaggi non recapitabili.
Quando viene chiamata ripetutamente, l'operazione Peak enumera tutti i messaggi nella coda o nella sottoscrizione, in ordine, dal numero di sequenza disponibile più basso al più alto. Si tratta dell'ordine in cui i messaggi sono stati accodati e non dell'ordine in cui i messaggi potrebbero essere recuperati.
È anche possibile passare un oggetto SequenceNumber a un'operazione Peak. Viene usato per determinare da dove iniziare l'operazione di visualizzazione in anteprima. È possibile effettuare chiamate successive all'operazione Peak senza specificare il parametro da enumerare ulteriormente.
Numero massimo di messaggi
È possibile specificare il numero massimo di messaggi che devono essere restituiti dall'operazione Peak. Tuttavia, non è possibile garantire una dimensione minima per il batch. Il numero di messaggi restituiti dipende da diversi fattori, di cui il più impattante è la velocità con cui la rete può trasmettere messaggi al client.
Ecco un frammento di codice di esempio per visualizzare tutti i messaggi con .NET SDK. È possibile usare SequenceNumber
per tenere traccia dell'ultimo messaggio visualizzato e avviare l'esplorazione al messaggio successivo.
using Azure.Messaging.ServiceBus;
// Create a Service Bus client for your namespace
ServiceBusClient client = new ServiceBusClient("NAMESPACECONNECTIONSTRING");
// Create Service Bus receiver for your queue in the namespace
ServiceBusReceiver receiver = client.CreateReceiver("QUEUENAME");
// Peek operation with max count set to 5
var peekedMessages = await receiver.PeekMessagesAsync(maxMessages: 5);
// Keep receiving while there are messages in the queue
while (peekedMessages.Count > 0)
{
int counter = 0; // To get the sequence number of the last peeked message
int countPeekedMessages = peekedMessages.Count;
if (countPeekedMessages > 0)
{
// For each peeked message, print the message body
foreach (ServiceBusReceivedMessage msg in peekedMessages)
{
Console.WriteLine(msg.Body);
counter++;
}
Console.WriteLine("Peek round complete");
Console.WriteLine("");
}
// Start receiving from the message after the last one
var fromSeqNum = peekedMessages[counter-1].SequenceNumber + 1;
peekedMessages = await receiver.PeekMessagesAsync(maxMessages: 5, fromSequenceNumber: fromSeqNum);
}
L'output di esempio seguente proviene dalla visualizzazione in anteprima di una coda contenente 13 messaggi.
Message 1
Message 2
Message 3
Message 4
Message 5
Peek round complete
Message 6
Message 7
Message 8
Message 9
Message 10
Peek round complete
Message 11
Message 12
Message 13
Peek round complete
Contenuto correlato
Provare gli esempi nel linguaggio preferito per esplorare le funzionalità del bus di servizio di Azure.
- Esempi di libreria client del bus di servizio di Azure per .NET (versione più recente) - esempio di invio e ricezione di messaggi.
- Esempi di libreria client del bus di servizio di Azure per Java (versione più recente) - Esempio di visualizzazione in anteprima di un messaggio
- Esempi di libreria client del bus di servizio di Azure per Python - Esempio di receive_peek.py
- Esempi di libreria client del bus di servizio di Azure per JavaScript - Esempio di browseMessages.js
- Esempi di libreria client del bus di servizio di Azure per TypeScript - Esempio di browseMessages.js
Cercare gli esempi per le librerie client .NET e Java precedenti qui:
- Esempi di libreria client del bus di servizio di Azure per .NET (legacy) - Esempio di esplorazione dei messaggi (anteprima rapida)
- Esempi di libreria client del bus di servizio di Azure per Java (legacy) - Esempio di esplorazione dei messaggi
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.