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 alle risorse del bus di servizio nel bus di servizio di Azure da flussi di lavoro di automazione e integrazione in App per la logica di Azure usando il connettore del bus di servizio. È possibile che gli eventi del bus di servizio attivino il flusso di lavoro o eseguano azioni che interagiscono con gli 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 e azioni che ottengono risposte dal bus di servizio di Azure e quindi rendono l'output disponibile per altre azioni nei flussi di lavoro.

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

• Un account e una sottoscrizione di Azure. Ottenere un account Azure gratuito.

• Uno spazio dei nomi del bus di servizio e un'entità di messaggistica, ad esempio una coda.

  Per ulteriori informazioni, vedere:

  • 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

• La risorsa e il flusso di lavoro della Logic App in cui si vuole accedere allo spazio dei nomi del Service Bus e all'entità di messaggistica.

  • Per iniziare il flusso di lavoro con un trigger del Bus di Servizio, creare 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 più adatto allo scenario.

  • Se la risorsa dell'app per la logica utilizza un'identità gestita per autenticare l'accesso al namespace del Service Bus e all'entità di messaggistica, è necessario assegnare le autorizzazioni di 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 può 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 coda o una sottoscrizione di un argomento deve usare la propria connessione API del bus di servizio.

    • Ogni operazione del bus di servizio che scambia messaggi con entità di messaggistica diverse e richiede autorizzazioni diverse deve usare la propria connessione 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 predefinite del connettore 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 ogni 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 univoci alla volta nella cache del connettore. Se il numero di sessioni supera questo limite, la cache del connettore rimuove le sessioni precedenti. Per altre informazioni, vedere Sessioni di messaggistica.

Inviare messaggi correlati in ordine

Quando è necessario inviare messaggi correlati in un ordine specifico, creare un flusso di lavoro usando il connettore del bus di servizio e il modello di convoglio 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 gestire messaggi di grandi dimensioni usando rispettivamente i trigger e le azioni 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 nell'esempio di codice 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 utilizzano il modello di 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.

Trigger del connettore predefinito del bus di servizio

Per il connettore integrato del bus di servizio, i trigger non sessione seguono un modello di trigger di polling continuo gestito dal connettore. In questo modello, il trigger verifica costantemente la presenza di messaggi nella coda o nell'abbonamento a un argomento. Al contrario, i trigger di sessione seguono lo schema di attivazione long-polling. L'impostazione delle Funzioni Azure, clientRetryOptions:tryTimeout, regola la loro configurazione. L'estensione host di Azure Functions, definita nel file host.json della app per la logica, e le impostazioni del trigger definite nel flusso di lavoro dell'app per la logica, configurate tramite la finestra di progettazione o la visualizzazione codice, condividono le impostazioni di configurazione per il trigger integrato di Service Bus. Questa sezione illustra entrambe le posizioni delle impostazioni. Si notino i dettagli seguenti sui trigger di Service Bus:

• Alcuni trigger predefiniti, ad esempio Quando i messaggi sono disponibili in un trigger di coda , possono restituire uno o più messaggi. Quando questi trigger si attivano, restituiscono tra uno e il numero di messaggi.

• Il trigger predefinito denominato Quando i messaggi sono disponibili in una coda (V1) non supporta il parametro denominato Dimensioni massime del batch di messaggi. Se si usa questo parametro, è necessario usare invece la versione V2. Per usare un trigger in cui il parametro non è supportato, è possibile controllare il numero di messaggi ricevuti aggiungendo il maxMessageBatchSize parametro alla definizione del trigger 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
     }
  }
  

• È possibile abilitare la concorrenza in un trigger del bus di servizio, tramite la finestra di progettazione o nel codice, ad esempio:

  "runtimeConfiguration": {
     "concurrency": {
          "runs": 50
      }
  }
  

  • Quando si configura la concorrenza usando un batch, mantenere il numero di esecuzioni simultanee maggiore delle 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 sul trigger denominato Quando i messaggi sono disponibili in una coda (V1) e si inviano 100 o più messaggi alla coda, il trigger instrada tutti i messaggi alla coda dei messaggi non recapitabili.

  • Se si abilita la concorrenza, il limite per il comportamento di debatching o Dividi al 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.

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

      Anche se è possibile modificare questo ritardo, assicurarsi di testare attentamente le modifiche apportate al valore predefinito:

      "workflow": {
          "settings": {
             "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30"
          }
      }
      

  • 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'impostazionemaximumWaitingRuns 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.

Passaggio 1: controllare l'accesso allo spazio dei nomi del bus di servizio

Per verificare che la risorsa dell'applicazione logica disponga delle autorizzazioni per accedere al namespace del Service Bus, seguire questa procedura:

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

2. Nella barra laterale dello spazio dei nomi, in Impostazioni, selezionare Criteri di accesso condiviso. In Attestazioni controllare di avere le autorizzazioni di gestione per lo spazio dei nomi.

   

Passaggio 2: ottenere i requisiti di autenticazione della connessione

Quando si aggiunge un trigger o un'azione del bus di servizio per la prima volta, vengono richieste 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 descritti nelle sezioni 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, è necessaria 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. Nella barra laterale dello spazio dei nomi, in Impostazioni, selezionare Criteri di accesso condiviso.

3. Nella pagina Criteri di accesso condiviso selezionare RootManageSharedAccessKey.

4. Accanto alla stringa di connessione primaria o secondaria, selezionare il pulsante Copia.

   

   Note

   Per verificare che la stringa sia per lo spazio dei nomi, non per un'entità di messaggistica specifica, cercare il parametro nella EntityPath 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. Nella barra laterale dello spazio dei nomi espandere Impostazioni e quindi selezionare Proprietà.

3. In Informazioni di base, accanto a ID, copiare e salvare l'URL dell'endpoint per usarlo in un secondo momento.

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. Nella barra laterale dello spazio dei nomi selezionare Panoramica.

3. Nella pagina Panoramica, espandere Elementi Essenziali e trovare la proprietà Nome host .

4. Copiare e salvare il nome completo, che assomiglia a <your-Service-Bus-namespace>.servicebus.windows.net, per un uso successivo.

Passaggio 3: Opzione 1 - Aggiungere un trigger del bus di servizio

I passaggi seguenti usano il portale di Azure, ma usando l'estensione app per la logica di Azure corrispondente, è possibile usare Visual Studio Code per creare flussi di lavoro delle app per la logica:

• Flussi di lavoro a consumo: creare flussi di lavoro di app per la logica a consumo con Visual Studio Code
• Flussi di lavoro Standard: creare flussi di lavoro Standard per app logiche con Visual Studio Code

Passaggio 3: Opzione 2 - Aggiungere un'azione del bus di servizio

I passaggi seguenti usano il portale di Azure, ma usando l'estensione app per la logica di Azure appropriata, è possibile usare Visual Studio Code per creare flussi di lavoro delle app per la logica:

• Flussi di lavoro a consumo: creare flussi di lavoro di app per la logica a consumo con Visual Studio Code
• Flussi di lavoro standard: Creare flussi di lavoro con app di logica Standard utilizzando 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 le impostazioni dell'app che controllano varie soglie. Ad esempio, queste impostazioni controllano i 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, vedere Informazioni di riferimento sulle impostazioni dell'app - local.settings.json.

Leggere i messaggi dalle code di messaggi non recapitabili usando i trigger predefiniti del bus di servizio.

Nei flussi di lavoro Standard, per leggere un messaggio da una coda non recapitabile in una coda o una sottoscrizione di argomenti, seguire questa procedura 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:

   • Quando i messaggi sono disponibili in una coda trigger: impostare il parametro Nome coda su queuename/$deadletterqueue.

   • Quando un messaggio è disponibile in una sottoscrizione dell'argomento (peek-lock) trigger: Imposta 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, disabilitare la risorsa dell'app per la logica, apportare le modifiche e quindi riabilitare la risorsa dell'app per la logica.

Nessuna sessione disponibile o un altro ricevitore l'ha bloccata

In alcuni casi, le operazioni come il completamento di un messaggio o il rinnovo di una sessione generano l'errore seguente nel connettore gestito:

{
  "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 nel connettore gestito:

{
  "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."
  }
}

In alcuni casi, le operazioni come il completamento di un messaggio o il rinnovo di una sessione generano l'errore seguente nel connettore predefinito:

{
  "code": "ServiceProviderActionFailed",
  "message": "The service provider action failed with error code 'ServiceOperationFailed' and error message 'The Service Bus session was not found to perform operation 'getMessagesFromQueueSession' on session id '11115555'.'."
}

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.

Questo comportamento può verificarsi sia nel connettore gestito che nel connettore predefinito. 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. Finché questo errore si verifica solo occasionalmente, è previsto.

Contenuti correlati

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