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.

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:

  • Creare uno spazio dei nomi del bus di servizio

  • Creare una coda e uno spazio dei nomi del bus di servizio

  • Creare un argomento e uno spazio dei nomi del bus di servizio con sottoscrizione

• 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

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 il connettore predefinito del bus di servizio, i trigger non di sessione seguono il modello di trigger push, mentre i trigger basati sulla sessione forniscono la funzionalità di polling. 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:

1. Nel portale di Azure, aprire lo spazio dei nomi del bus di servizio.

2. 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)

Autenticazione del connettore predefinito (solo flussi di lavoro Standard)

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://.

1. Nel portale di Azure, aprire lo spazio dei nomi del bus di servizio.

2. Nel menu dello spazio dei nomi, selezionare Criteri di accesso condivisi in Impostazioni.

3. Nella pagina Criteri di accesso condiviso selezionare RootManageSharedAccessKey.

4. 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 EntityPath nella 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.

5. 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://.

1. Nel portale di Azure, aprire lo spazio dei nomi del bus di servizio.

2. Nel menu dello spazio dei nomi, in Impostazioni, selezionare Proprietà.

3. 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

1. Nel portale di Azure, aprire lo spazio dei nomi del bus di servizio.

2. Nel menù dello spazio dei nomi, selezionare Panoramica.

3. 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

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

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:

1. 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).

2. 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

Occasionalmente, operazioni come il completamento di un messaggio o il rinnovo di una sessione generano l'errore seguente:

{
  "status": 400,
  "message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'. clientRequestId: facae905-9ba4-44f4-a42a-888888888888",
  "error": {
    "message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
  }
}

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 si verifica questo evento, l'esito delle richieste è negativo perché il ricevitore che esegue le operazioni nella sessione non è disponibile nell'istanza del ruolo che gestisce la richiesta.

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.

Passaggi successivi

• Connettori gestiti per app per la logica di Azure
• Connettori predefiniti per App per la logica di Azure
• Cosa sono i connettori gestiti in App per la logica di Azure