Connettersi al bus di servizio di Azure da flussi di lavoro in App per la logica di Azure
Si applica a: App per la logica di Azure (a consumo e standard)
Questa guida illustra come accedere al bus di servizio di Azure da un flusso di lavoro in App per la logica di Azure usando il connettore del bus di servizio. È possibile, quindi, creare flussi di lavoro automatizzati che vengono eseguiti se attivati da eventi in un bus di servizio o eseguire azioni per gestire elementi del bus di servizio, ad esempio:
- Monitorare quando i messaggi arrivano (completamento automatico) o vengono ricevuti (blocco di visualizzazione) nelle code, negli argomenti e nelle sottoscrizioni di argomento.
- Inviare messaggi.
- Creare ed eliminare sottoscrizioni di argomento.
- Gestire i messaggi nelle code e nelle sottoscrizioni di argomento, ad esempio recuperare messaggi, recuperare messaggi posticipati, completare, posticipare, abbandonare e inserire nella coda dei messaggi non recapitabili.
- Rinnovare i blocchi su messaggi e sessioni nelle code e nelle sottoscrizioni di argomento.
- Chiudere le sessioni nelle code e negli argomenti.
È possibile usare trigger per ottenere risposte dal bus di servizio e rendere disponibile l'output per altre azioni nei flussi di lavoro. È anche possibile fare in modo che altre azioni usino l'output delle azioni del service bus.
Informazioni tecniche sul connettore
Il connettore del bus di servizio ha versioni diverse, in base all'ambiente host e al tipo di flusso di lavoro dell'app per la logica.
| App per la logica | Ambiente | Versione del connettore |
|---|---|---|
| Consumo | App per la logica di Azure multi-tenant | Connettore gestito, visualizzato nella raccolta di connettori in Runtime>Condiviso. Nota: i trigger del connettore gestito del bus di servizio seguono il modello di trigger di polling lungo, vale a dire che il trigger controlla periodicamente la presenza di messaggi nella sottoscrizione dell'argomento o della coda. Per altre informazioni, vedere la documentazione seguente: - Informazioni di riferimento sul connettore gestito del bus di servizio - Connettori gestiti in App per la logica di Azure |
| Standard | App per la logica di Azure a tenant singolo e ambiente del servizio app v3 (solo piani di Windows) | Connettore gestito (ospitato da Azure) visualizzato nella raccolta di connettori in Runtime>Condiviso e connettore predefinito visualizzato nella raccolta di connettori in Runtime>In app e basato sul provider di servizi. I trigger del connettore gestito del bus di servizio seguono il modello di trigger di polling lungo, vale a dire che il trigger controlla periodicamente la presenza di messaggi nella sottoscrizione dell'argomento o della coda. Il bus di servizio trigger predefiniti non di sessione del connettore seguono un modello di trigger di polling continuo completamente gestito dal connettore. Questo modello include il trigger per verificare costantemente la presenza di messaggi nella sottoscrizione della coda o dell'argomento. I trigger di sessione seguono il modello di trigger di polling lungo, ma la configurazione è governata dall'impostazione di Funzioni di Azure denominata clientRetryOptions:tryTimeout. La versione predefinita offre in genere prestazioni, funzionalità, prezzi e così via migliori. |
Per altre informazioni, vedere la documentazione seguente: - Informazioni di riferimento sul connettore gestito del bus di servizio - Operazioni del connettore predefinito del bus di servizio - Connettori predefiniti in App per la logica di Azure |
Prerequisiti
Account e sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, iscriversi per creare un account Azure gratuito.
Uno spazio dei nomi del bus di servizio e un'entità di messaggistica, ad esempio una coda. Per altre informazioni, vedere la documentazione seguente:
Il flusso di lavoro dell'app per la logica in cui ci si connette all'entità di messaggistica e allo spazio dei nomi del bus di servizio. Per avviare il flusso di lavoro con un trigger del bus di servizio, è necessario iniziare con un flusso di lavoro vuoto. Per usare un'azione del bus di servizio nel flusso di lavoro, avviare il flusso di lavoro con qualsiasi trigger.
Se la risorsa dell'app per la logica usa un'identità gestita per autenticare l'accesso all'entità della messaggistica e dello spazio dei nomi del bus di servizio, assicurarsi di avere assegnato le autorizzazioni del ruolo ai livelli corrispondenti. Ad esempio, per accedere a una coda, l'identità gestita richiede un ruolo con le autorizzazioni necessarie per tale coda.
Ogni risorsa dell'app per la logica deve usare una sola identità gestita, anche se il flusso di lavoro dell'app per la logica accede a entità di messaggistica diverse.
Ogni identità gestita che accede a una sottoscrizione di un argomento o una coda deve usare la propria connessione API del bus di servizio.
Le operazioni del bus di servizio che scambiano messaggi con entità di messaggistica diverse e richiedono autorizzazioni diverse devono usare le proprie connessioni API del bus di servizio.
Per altre informazioni sulle identità gestite, vedere Autenticare l'accesso alle risorse di Azure con identità gestite in App per la logica di Azure.
Per impostazione predefinita, le operazioni del connettore predefinito del bus di servizio sono senza stato. Per eseguire queste operazioni in modalità con stato, vedere Abilitare la modalità con stato per i connettori predefiniti senza stato.
Considerazioni sulle operazioni del bus di servizio di Azure
Cicli infiniti
Importante
Prestare attenzione quando si seleziona sia un trigger che un'azione con lo stesso tipo di connettore e li si utilizza per lavorare con la medesima entità, ad esempio una coda di messaggistica o una sottoscrizione dell'argomento. Questa combinazione può creare un ciclo infinito, che si traduce in un'app per la logica che non ha mai fine.
Limite per le sessioni salvate nella cache del connettore
Per entità di messaggistica del bus di servizio, ad esempio una sottoscrizione o un argomento, il connettore del bus di servizio può salvare fino a 1.500 sessioni univoche alla volta nella cache del connettore. Se il numero di sessioni supera tale limite, le sessioni precedenti vengono rimosse dalla cache. Per altre informazioni, vedere Sessioni di messaggistica.
Inviare messaggi correlati in ordine
Quando è necessario inviare messaggi correlati in un ordine specifico, è possibile creare un flusso di lavoro usando il connettore del bus di servizio e il modello di serie di istruzioni sequenziale. I messaggi correlati hanno una proprietà che definisce la relazione tra tali messaggi, ad esempio l'ID per la sessione nel bus di servizio di Azure.
Quando si crea un flusso di lavoro dell'app per la logica A consumo, è possibile selezionare il modello Recapito in ordine correlato tramite sessioni del bus di servizio, che implementa il modello di serie di istruzioni sequenziale. Per altre informazioni, vedere Inviare messaggi correlati in ordine.
Supporto di grandi messaggi
Il supporto di grandi messaggi è disponibile solo per i flussi di lavoro Standard quando si usano le operazioni del connettore predefinito del bus di servizio. Ad esempio, è possibile ricevere e inviare grandi messaggi usando rispettivamente le azioni e i trigger predefiniti.
Per il connettore gestito del bus di servizio, le dimensioni massime dei messaggi sono limitate a 1 MB, anche quando si usa uno spazio dei nomi del bus di servizio di livello Premium.
Aumentare il timeout per la ricezione e l'invio di messaggi
Nei flussi di lavoro Standard che usano le operazioni predefinite del bus di servizio, è possibile aumentare il timeout per la ricezione e l'invio di messaggi. Ad esempio, per aumentare il timeout per la ricezione di un messaggio, modificare l'impostazione seguente nell'estensione Funzioni di Azure:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
"version": "[1.*, 2.0.0)"
},
"extensions": {
"serviceBus": {
"batchOptions": {
"operationTimeout": "00:15:00"
}
}
}
}
Per aumentare il timeout per l'invio di un messaggio, aggiungere l'impostazione dell'app ServiceProviders.ServiceBus.MessageSenderOperationTimeout.
Trigger del connettore gestito del bus di servizio
Per il connettore gestito del bus di servizio, tutti i trigger sono a polling lungo. Questo tipo di trigger elabora tutti i messaggi e attende 30 secondi che vengano visualizzati altri messaggi nella sottoscrizione della coda o dell'argomento. Se non vengono visualizzati messaggi per 30 secondi, l'esecuzione del trigger viene ignorata. In caso contrario, il trigger continua a leggere i messaggi finché la coda o la sottoscrizione dell'argomento non sono vuote. Il polling successivo si baserà sull'intervallo di ricorrenza specificato nelle proprietà del trigger.
Alcuni trigger, ad esempio il trigger Quando uno o più messaggi arriva in una coda (completamento automatico), può restituire uno o più messaggi. Quando questi trigger si attivano, restituiscono il numero di messaggi tra uno e quello specificato dalla proprietà Numero massimo di messaggi del trigger.
Nota
Il trigger di completamento automatico completa automaticamente un messaggio, ma il completamento avviene solo alla chiamata successiva al bus di servizio. Questo comportamento può influire sulla progettazione del flusso di lavoro. Ad esempio, evitare di modificare la concorrenza nel trigger di completamento automatico perché questa modifica potrebbe produrre messaggi duplicati se il flusso di lavoro entra in uno stato limitato. La modifica del controllo della concorrenza crea le condizioni seguenti:
I trigger limitati vengono ignorati con il codice
WorkflowRunInProgress.L'operazione di completamento non verrà eseguita.
L'esecuzione del trigger successiva si verifica dopo l'intervallo di polling.
È necessario impostare la durata del blocco del bus di servizio su un valore più lungo dell'intervallo di polling. Nonostante questa impostazione, tuttavia, il messaggio potrebbe comunque non essere completato se il flusso di lavoro rimane in uno stato limitato al successivo intervallo di polling.
Tuttavia, se si attiva un'impostazione della concorrenza dei trigger del bus di servizio, il valore predefinito per la proprietà
maximumWaitingRunsè 10. In base all'impostazione di durata del blocco dell'entità del bus di servizio e alla durata dell'esecuzione per il flusso di lavoro, questo valore predefinito potrebbe essere troppo grande e potrebbe causare un'eccezione di blocco perso. Per trovare il valore ottimale per il proprio scenario, cominciare provando un valore pari a 1 o 2 per la proprietàmaximumWaitingRuns. Per modificare il valore massimo delle esecuzioni in attesa, esaminare Modificare il limite di esecuzioni in attesa.
Trigger del connettore predefinito del bus di servizio
Per bus di servizio connettore predefinito, i trigger non di sessione seguono un modello di trigger di polling continuo completamente gestito dal connettore. Questo modello include il trigger per verificare costantemente la presenza di messaggi nella sottoscrizione della coda o dell'argomento. I trigger di sessione seguono il modello di trigger di polling lungo, con la relativa configurazione è governata dall'impostazione di Funzioni di Azure denominata clientRetryOptions:tryTimeout. Attualmente, le impostazioni di configurazione per il trigger predefinito del bus di servizio sono condivise tra l'estensione host Funzioni di Azure, definita nel file host.json dell'app per la logica, e le impostazioni del trigger definite nel flusso di lavoro dell'app per la logica, che è possibile configurare tramite la finestra di progettazione o la visualizzazione del codice. Questa sezione illustra entrambe le posizioni delle impostazioni.
Nei flussi di lavoro Standard, alcuni trigger, ad esempio il trigger Quando sono disponibili messaggi in una coda, può restituire uno o più messaggi. Quando questi trigger si attivano, restituiscono tra uno e il numero di messaggi. Per questo tipo di trigger e dove il parametro Numero massimo di messaggi non è supportato, è comunque possibile controllare il numero di messaggi ricevuti usando la proprietà maxMessageBatchSize nel file host.json. Per trovare questo file, vedere Modificare le impostazioni dell'host e dell'app per le app per la logica Standard.
"extensions": { "serviceBus": { "maxMessageBatchSize": 25 } }È anche possibile abilitare la concorrenza nel trigger del bus di servizio tramite la finestra di progettazione o nel codice:
"runtimeConfiguration": { "concurrency": { "runs": 100 } }Quando si configura la concorrenza usando un batch, mantenere il numero di esecuzioni simultanee superiori alle dimensioni complessive del batch. In questo modo, i messaggi letti non passano in uno stato di attesa e vengono sempre prelevati quando vengono letti. In alcuni casi, le dimensioni del trigger possono essere anche doppie rispetto a quelle del batch.
Se si abilita la concorrenza, il limite SplitOn viene ridotto a 100 elementi. Questo comportamento è vero per tutti i trigger, non solo per il trigger del bus di servizio. Assicurarsi che le dimensioni del batch specificate siano inferiori a questo limite per qualsiasi trigger in cui si abilita la concorrenza.
Esistono alcuni scenari in cui il trigger può superare le impostazioni della concorrenza. Anziché non eseguire queste esecuzioni, App per la logica di Azure le accoda in uno stato di attesa fino a quando non possono essere avviate. L'impostazione maximumWaitingRuns controlla il numero di esecuzioni consentite nello stato di attesa:
"runtimeConfiguration": { "concurrency": { "runs": 100, "maximumWaitingRuns": 50 } }Con il trigger del bus di servizio, assicurarsi di testare attentamente queste modifiche in modo che le esecuzioni non attendano più a lungo del timeout di blocco del messaggio. Per altre informazioni sui valori predefiniti, vedere i limiti di concorrenza e de-batch qui.
Se si abilita la concorrenza, per impostazione predefinita esiste un ritardo di 30 secondi tra le letture batch. Questo ritardo rallenta il trigger per raggiungere gli obiettivi seguenti:
Ridurre il numero di chiamate di archiviazione inviate per controllare il numero di esecuzioni in cui applicare la concorrenza.
Simulare il comportamento del trigger del connettore gestito del bus di servizio, che ha un polling lungo 30 secondi quando non vengono trovati messaggi.
È possibile modificare questo ritardo, ma assicurarsi di testare attentamente le modifiche apportate al valore predefinito:
"workflow": { "settings": { "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30" } }
Passaggio 1: controllare l'accesso allo spazio dei nomi del bus di servizio
Per assicurarsi che la risorsa dell'app per la logica disponga delle autorizzazioni per accedere allo spazio dei nomi del bus di servizio, usare i passaggi seguenti:
Nel portale di Azure, aprire lo spazio dei nomi del bus di servizio.
Nel menu dello spazio dei nomi, selezionare Criteri di accesso condivisi in Impostazioni. In Attestazioni controllare di avere le autorizzazioni di gestione per lo spazio dei nomi.
Passaggio 2: ottenere i requisiti di autenticazione della connessione
Successivamente, quando si aggiunge un trigger o un'azione del bus di servizio per la prima volta, vengono richieste le informazioni di connessione, incluso il tipo di autenticazione della connessione. In base al tipo di flusso di lavoro dell'app per la logica, alla versione del connettore del bus di servizio e al tipo di autenticazione selezionato, sono necessari gli elementi seguenti:
Autenticazione del connettore gestito (flussi di lavoro A consumo e Standard)
| Tipo di autenticazione | Informazioni necessarie |
|---|---|
| Access Key | La stringa di connessione per lo spazio dei nomi del bus di servizio. Per altre informazioni, esaminare Ottenere la stringa di connessione per lo spazio dei nomi del bus di servizio |
| Integrato in Microsoft Entra | L'URL dell'endpoint per lo spazio dei nomi del bus di servizio. Per altre informazioni, esaminare Ottenere l'URL dell'endpoint per lo spazio dei nomi del bus di servizio. |
| Identità gestita di App per la logica | L'URL dell'endpoint per lo spazio dei nomi del bus di servizio. Per altre informazioni, esaminare Ottenere l'URL dell'endpoint per lo spazio dei nomi del bus di servizio. |
Autenticazione del connettore predefinito (solo flussi di lavoro Standard)
| Tipo di autenticazione | Informazioni necessarie |
|---|---|
| Stringa di connessione | La stringa di connessione per lo spazio dei nomi del bus di servizio. Per altre informazioni, esaminare Ottenere la stringa di connessione per lo spazio dei nomi del bus di servizio |
| Active Directory OAuth | - Il nome completo dello spazio dei nomi del bus di servizio, ad esempio <your-Service-Bus-namespace>.servicebus.windows.net. Per altre informazioni, esaminare Ottenere il nome completo dello spazio dei nomi del bus di servizio. Per i valori delle altre proprietà, vedere OAuth con Microsoft Entra ID. |
| Identità gestita | Il nome completo dello spazio dei nomi del bus di servizio, ad esempio <your-Service-Bus-namespace>.servicebus.windows.net. Per altre informazioni, esaminare Ottenere il nome completo dello spazio dei nomi del bus di servizio. |
Ottenere la stringa di connessione per lo spazio dei nomi del bus di servizio
Per creare una connessione quando si aggiunge un trigger o un'azione del bus di servizio, è necessario avere la stringa di connessione per lo spazio dei nomi del bus di servizio. La stringa di connessione inizia con il prefisso sb://.
Nel portale di Azure, aprire lo spazio dei nomi del bus di servizio.
Nel menu dello spazio dei nomi, selezionare Criteri di accesso condivisi in Impostazioni.
Nella pagina Criteri di accesso condiviso selezionare RootManageSharedAccessKey.
Accanto alla stringa di connessione primaria o secondaria, selezionare il pulsante Copia.
Nota
Per controllare se la stringa riguarda lo spazio dei nomi e non a un'entità di messaggistica specifica, cercare il parametro
EntityPathnella stringa di connessione. Se questo parametro è presente, la stringa di connessione riguarda un'entità specifica e non è la stringa corretta da usare con il flusso di lavoro.Salvare la stringa di connessione per usarla successivamente.
Ottenere l'URL dell'endpoint per lo spazio dei nomi del bus di servizio
Se si usa il connettore gestito del bus di servizio, è necessario questo URL dell'endpoint se si seleziona il tipo di autenticazione per Microsoft Entra integrato o Identità gestita dell'App per la logica. L'URL dell'endpoint inizia con il prefisso sb://.
Nel portale di Azure, aprire lo spazio dei nomi del bus di servizio.
Nel menu dello spazio dei nomi, in Impostazioni, selezionare Proprietà.
In Proprietà, accanto all'endpoint del bus di servizio, copiare l'URL dell'endpoint e salvarlo per usarlo in un secondo momento quando è necessario specificare l'URL dell'endpoint del bus di servizio.
Ottenere il nome completo dello spazio dei nomi del bus di servizio
Nel portale di Azure, aprire lo spazio dei nomi del bus di servizio.
Nel menù dello spazio dei nomi, selezionare Panoramica.
Nel riquadro Panoramica, trovare la proprietà Nome host e copiare il nome completo, simile a <your-Service-Bus-namespace>.servicebus.windows.net.
Passaggio 3: Opzione 1 - Aggiungere un trigger del bus di servizio
I passaggi seguenti usano il portale di Azure, ma con l'estensione app per la logica di Azure appropriata, è anche possibile usare gli strumenti seguenti per creare flussi di lavoro delle app per la logica:
Flussi di lavoro dell'app per la logica A consumo: Visual Studio o Visual Studio Code
Creare flussi di lavoro dell'app per la logica Standard: Visual Studio Code
Nel portale di Azure, aprire la risorsa dell'app per la logica A consumo e il flusso di lavoro vuoto nella finestra di progettazione.
Nella finestra di progettazione, seguire questi passaggi generali per aggiungere il trigger del bus di servizio di Azure desiderato.
Questo esempio continua con il trigger denominato Quando viene ricevuto un messaggio in una coda (completamento automatico).
Se viene chiesto, specificare le informazioni seguenti per la connessione. Al termine, seleziona Crea.
Proprietà Richiesto Descrizione Nome connessione Sì Un nome per la connessione Tipo di autenticazione Sì Il tipo di autenticazione da usare per l'accesso allo spazio dei nomi del bus di servizio. Per altre informazioni, esaminare Autenticazione del connettore gestito. Stringa di connessione Sì La stringa di connessione copiata e salvata precedentemente. Ad esempio, questa connessione usa l'autenticazione della chiave di accesso e fornisce la stringa di connessione per uno spazio dei nomi del bus di servizio:
Dopo la visualizzazione della casella delle informazioni sul trigger, specificare le informazioni necessarie, ad esempio:
Proprietà Richiesto Descrizione Nome coda Sì La coda selezionata per accedere Tipo di coda No Il tipo per la coda selezionata Specificare la frequenza in base a cui verificare gli elementi. Sì L'intervallo di polling e la frequenza per controllare la presenza di elementi nella coda 
Per aggiungere altre proprietà disponibili al trigger, aprire l'elenco Aggiungi nuovo parametro e selezionare le proprietà desiderate.
Aggiungere tutte le azioni necessarie per il flusso di lavoro.
È ad esempio possibile aggiungere un'azione che invia un messaggio di posta elettronica quando arriva un nuovo messaggio. Quando il trigger controlla la coda e trova un nuovo messaggio, il flusso di lavoro esegue le azioni selezionate per il messaggio trovato.
Al termine, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.
Passaggio 3: Opzione 2 - Aggiungere un'azione del bus di servizio
I passaggi seguenti usano il portale di Azure, ma con l'estensione app per la logica di Azure appropriata, è anche possibile usare gli strumenti seguenti per creare flussi di lavoro delle app per la logica:
Flussi di lavoro dell'app per la logica A consumo: Visual Studio o Visual Studio Code
Creare flussi di lavoro dell'app per la logica Standard: Visual Studio Code
Nel portale di Azure, aprire l'app per la logica e il flusso di lavoro A consumo nella finestra di progettazione.
Nella finestra di progettazione, seguire questi passaggi generali per aggiungere l'azione del bus di servizio di Azure desiderata.
Questo esempio continua con l'azione Invia messaggio.
Se viene chiesto, specificare le informazioni seguenti per la connessione. Al termine, seleziona Crea.
Proprietà Richiesto Descrizione Nome connessione Sì Un nome per la connessione Tipo di autenticazione Sì Il tipo di autenticazione da usare per l'accesso allo spazio dei nomi del bus di servizio. Per altre informazioni, esaminare Autenticazione del connettore gestito. Stringa di connessione Sì La stringa di connessione copiata e salvata precedentemente. Ad esempio, questa connessione usa l'autenticazione della chiave di accesso e fornisce la stringa di connessione per uno spazio dei nomi del bus di servizio:
Dopo la visualizzazione della casella delle informazioni sull'azione, specificare le informazioni necessarie, ad esempio:
Proprietà Richiesto Descrizione Nome coda/argomento Sì La destinazione della coda o dell'argomento selezionato per l'invio del messaggio Id sessione No L'ID sessione se si invia il messaggio a una coda o a un argomento compatibile con la sessione Proprietà del sistema No - Nessuno
- Dettagli esecuzione: aggiungere informazioni sulle proprietà dei metadati sull'esecuzione come proprietà personalizzate nel messaggio.
Per aggiungere altre proprietà disponibili all'azione, aprire l'elenco Aggiungi nuovo parametro e selezionare le proprietà desiderate.
Aggiungere tutte le altre azioni necessarie per il flusso di lavoro.
Ad esempio, è possibile aggiungere un'azione che invia un'e-mail per confermare l'invio del messaggio.
Al termine, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.
Impostazioni dell'app del connettore predefinito del bus di servizio
In una risorsa dell'app per la logica Standard, il connettore predefinito del bus di servizio include impostazioni dell'app che controllano varie soglie, ad esempio il timeout per l'invio di messaggi e il numero di mittenti di messaggi per ogni core del processore nel pool di messaggi. Per altre informazioni, esaminare Informazioni di riferimento per le impostazioni dell'app - local.settings.json.
Leggere messaggi da code di messaggi non recapitabili con trigger predefiniti del bus di servizio
Nei flussi di lavoro Standard, per leggere un messaggio da una coda di messaggi non recapitabili in una sottoscrizione di argomento o coda, seguire questi passaggi usando i trigger specificati:
Nel flusso di lavoro vuoto, in base allo scenario, aggiungere il trigger del connettore predefinito del bus di servizio denominato Quando sono disponibili messaggi in una coda o Quando è disponibile un messaggio in una sottoscrizione di argomento (peek-lock).
Nel trigger, impostare i valori dei parametri seguenti per specificare la coda di messaggi non recapitabili predefinita della sottoscrizione di argomento o coda, a cui è possibile accedere come qualsiasi altra coda:
Trigger Quando sono disponibili messaggi in una coda: impostare il parametro Nome coda su nome coda/$deadletterqueue.
Trigger Quando è disponibile un messaggio in una sottoscrizione di argomento (peek-lock): impostare il parametro Nome argomento su topicname/Subscriptions/subscriptionname/$deadletterqueue.
Per altre informazioni, vedere Panoramica delle code di messaggi non recapitabili del bus di servizio.
Risoluzione dei problemi
Ritardi nell'applicazione degli aggiornamenti apportati al flusso di lavoro
Se l'intervallo di polling di un trigger del bus di servizio è ridotto, ad esempio 10 secondi, gli aggiornamenti apportati al flusso di lavoro potrebbero non essere applicati per un periodo massimo di 10 minuti. Per risolvere questo problema, è possibile disabilitare la risorsa dell'app per la logica, apportare le modifiche e quindi abilitare nuovamente la risorsa dell'app per la logica.
Nessuna sessione disponibile o potrebbe essere bloccata da un altro ricevitore
Occasionalmente, operazioni come il completamento di un messaggio o il rinnovo di una sessione generano l'errore seguente:
{
"status": 400,
"error": {
"message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
}
}
In alcuni casi, un trigger basato su sessione potrebbe non riuscire con l'errore seguente:
{
"status": 400,
"error": {
"message": "Communication with the Service Bus namespace 'xxxx' and 'yyyy' entity failed. The requested session 'zzzz' cannot be accepted. It may be locked by another receiver."
}
}
Il connettore del bus di servizio usa la cache in memoria per supportare tutte le operazioni associate alle sessioni. Il ricevitore di messaggi del bus di servizio viene memorizzato nella cache nella memoria dell'istanza del ruolo (macchina virtuale) che riceve i messaggi. Per elaborare tutte le richieste, tutte le chiamate per la connessione vengono instradate a questa stessa istanza del ruolo. Questo comportamento è necessario perché tutte le operazioni del bus di servizio in una sessione richiedono lo stesso ricevitore che riceve i messaggi per una sessione specifica.
Esiste la probabilità che le richieste non vengano indirizzate alla stessa istanza del ruolo, a causa di motivi come un aggiornamento dell'infrastruttura, la distribuzione del connettore e così via. Se questo evento si verifica, le richieste hanno esito negativo per uno dei motivi seguenti:
Il ricevitore che esegue le operazioni nella sessione non è disponibile nell'istanza del ruolo che gestisce la richiesta.
La nuova istanza del ruolo tenta di ottenere la sessione, che si è timeout nell'istanza del ruolo precedente o non è stata chiusa.
Finché questo errore si verifica solo occasionalmente, è previsto. Quando si verifica l'errore, il messaggio viene ancora mantenuto nel bus di servizio. L'esecuzione del flusso di lavoro o il trigger successivo tenta di elaborare nuovamente il messaggio.