Connessione bus di servizio di Azure dai flussi di lavoro in App per la logica di Azure
Si applica a: App per la logica di Azure (consumo + standard)
Questa guida illustra come accedere alle bus di servizio di Azure da un flusso di lavoro in App per la logica di Azure usando il connettore bus di servizio. È quindi possibile creare flussi di lavoro automatizzati eseguiti quando vengono attivati da eventi in un bus di servizio o eseguire azioni per gestire 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 che ottengono risposte da bus di servizio di Azure e rendono l'output disponibile per altre azioni nei flussi di lavoro. È anche possibile fare in modo che altre azioni usino l'output delle azioni del service bus.
Riferimento tecnico Connessione or
Il connettore bus di servizio ha versioni diverse, in base al tipo di flusso di lavoro dell'app per la logica e all'ambiente host.
| App per la logica | Ambiente | versione di Connessione or |
|---|---|---|
| Consumo | App per la logica di Azure multi-tenant | Connettore gestito (classe Standard). Per altre informazioni, vedere la documentazione seguente: - Informazioni di riferimento sul connettore gestito bus di servizio - Connettori gestiti in App per la logica di Azure |
| Consumo | Ambiente del servizio di integrazione | Connettore gestito (classe Standard) e I edizione Standard versione, che presenta limiti di messaggio diversi rispetto alla classe Standard. Per altre informazioni, vedere la documentazione seguente: - Informazioni di riferimento sul connettore gestito bus di servizio - I edizione Standard limiti dei messaggi - 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 in Azure) e connettore predefinito, basato sul provider di servizi. La versione predefinita offre in genere prestazioni, funzionalità, prezzi e così via migliori. Nota: bus di servizio trigger predefiniti del connettore seguono il modello di trigger di polling, il che significa che il trigger controlla continuamente la presenza di messaggi nella sottoscrizione della coda o dell'argomento. Per altre informazioni, vedere la documentazione seguente: - Informazioni di riferimento sul connettore gestito bus di servizio - bus di servizio operazioni predefinite del connettore - 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:
Flusso di lavoro dell'app per la logica in cui ci si connette all'entità dello spazio dei nomi e della messaggistica bus di servizio. Per avviare il flusso di lavoro con un trigger bus di servizio, è necessario iniziare con un flusso di lavoro vuoto. Per usare un'azione 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à dello spazio dei nomi e della messaggistica 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 una coda o di un argomento deve usare la propria connessione API bus di servizio.
bus di servizio operazioni che scambiano messaggi con entità di messaggistica diverse e richiedono autorizzazioni diverse devono usare le proprie connessioni API 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 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 di bus di servizio di Azure
Cicli infiniti
Importante
Prestare attenzione quando si selezionano sia un trigger che un'azione con lo stesso tipo di connettore e usarli per lavorare con la stessa entità, ad esempio una coda di messaggistica o una sottoscrizione di argomenti. Questa combinazione può creare un ciclo infinito, che comporta un'app per la logica che non termina mai.
Limite per le sessioni salvate nella cache del connettore
Per bus di servizio entità di messaggistica, ad esempio una sottoscrizione o un argomento, il connettore bus di servizio può salvare fino a 1.500 sessioni univoce alla volta nella cache del connettore. Se il numero di sessioni supera questo limite, le sessioni precedenti vengono rimosse dalla cache. Per altre informazioni, vedere Sessioni di messaggi.
Inviare messaggi correlati in ordine
Quando è necessario inviare messaggi correlati in un ordine specifico, è possibile creare un flusso di lavoro usando bus di servizio connettore 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 in 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 usando il modello sessioni del bus di servizio, che implementa il modello di convoglio sequenziale. Per altre informazioni, vedere Inviare messaggi correlati in ordine.
Supporto di messaggi di grandi dimensioni
Il supporto di messaggi di grandi dimensioni è disponibile solo per i flussi di lavoro Standard quando si usano le operazioni predefinite del connettore bus di servizio. Ad esempio, è possibile ricevere e inviare messaggi di grandi dimensioni usando rispettivamente i trigger e le azioni predefiniti.
Per il connettore gestito bus di servizio, la dimensione massima dei messaggi è limitata a 1 MB, anche quando si usa uno spazio dei nomi 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 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.
bus di servizio trigger del connettore gestito
Per il connettore gestito bus di servizio, tutti i trigger sono di polling lungo. Questo tipo di trigger elabora tutti i messaggi e quindi attende 30 secondi per visualizzare 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 quando uno o più messaggi arrivano in una coda (completamento automatico), possono restituire uno o più messaggi. Quando questi trigger vengono attivati, restituiscono tra uno e il numero di messaggi specificati dalla proprietà Maximum message count del trigger.
Nota
Il trigger di completamento automatico completa automaticamente un messaggio, ma il completamento avviene solo alla chiamata successiva a 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 comportare messaggi duplicati se il flusso di lavoro entra in uno stato limitato. La modifica del controllo di concorrenza crea le condizioni seguenti:
I trigger limitati vengono ignorati con il
WorkflowRunInProgresscodice.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 di concorrenza di un trigger di bus di servizio, il valore predefinito per la
maximumWaitingRunsproprietà è 10. In base all'impostazione di durata del blocco dell'entità 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 lo scenario, iniziare a testare con un valore pari a 1 o 2 per lamaximumWaitingRunsproprietà. Per modificare il valore massimo delle esecuzioni in attesa, vedere Modificare il limite di esecuzioni in attesa.
bus di servizio trigger del connettore predefiniti
Attualmente, le impostazioni di configurazione per il trigger predefinito bus di servizio vengono condivise tra l'estensione host Funzioni di Azure, definita nel file di 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 codice. Questa sezione illustra entrambe le posizioni delle impostazioni.
Nei flussi di lavoro Standard alcuni trigger, ad esempio Quando i messaggi sono disponibili in un trigger di coda , possono restituire uno o più messaggi. Quando questi trigger vengono attivati, restituiscono tra uno e il numero di messaggi. Per questo tipo di trigger e in cui 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 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, leggere i messaggi non passano in uno stato di attesa e vengono sempre prelevati quando vengono letti. In alcuni casi, il trigger può avere fino a due volte le dimensioni 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 di 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 di concorrenza. Invece di non eseguire queste esecuzioni, App per la logica di Azure li accoda in uno stato di attesa fino a quando non possono essere avviati. L'impostazione maximumWaitingRuns controlla il numero di esecuzioni consentite nello stato di attesa:
"runtimeConfiguration": { "concurrency": { "runs": 100, "maximumWaitingRuns": 50 } }Con il trigger bus di servizio, assicurarsi di testare attentamente queste modifiche in modo che le esecuzioni non attendino più a lungo del timeout del blocco del messaggio. Per altre informazioni sui valori predefiniti, vedere 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 di bus di servizio, che ha un polling lungo 30 secondi quando non viene trovato alcun messaggio.
È 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 bus di servizio
Per verificare che la risorsa dell'app per la logica disponga delle autorizzazioni per accedere allo spazio dei nomi bus di servizio, seguire questa procedura:
Nella portale di Azure aprire lo spazio dei nomi bus di servizio.
Nel menu 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
Successivamente, quando si aggiunge un trigger o un'azione 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 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 |
|---|---|
| Chiave di accesso | Il stringa di connessione per lo spazio dei nomi bus di servizio. Per altre informazioni, vedere Ottenere stringa di connessione per bus di servizio spazio dei nomi |
| Integrato in Microsoft Entra | URL dell'endpoint per lo spazio dei nomi bus di servizio. Per altre informazioni, vedere Ottenere l'URL dell'endpoint per bus di servizio spazio dei nomi. |
| Identità gestita di App per la logica | URL dell'endpoint per lo spazio dei nomi bus di servizio. Per altre informazioni, vedere Ottenere l'URL dell'endpoint per bus di servizio spazio dei nomi. |
Autenticazione predefinita del connettore (solo flussi di lavoro Standard)
| Tipo di autenticazione | Informazioni necessarie |
|---|---|
| Stringa di connessione | Il stringa di connessione per lo spazio dei nomi bus di servizio. Per altre informazioni, vedere Ottenere stringa di connessione per bus di servizio spazio dei nomi |
| Active Directory OAuth | - Nome completo per lo spazio dei nomi bus di servizio, <ad esempio your-Service-Bus-namespace.servicebus.windows.net.> Per altre informazioni, vedere Ottenere un nome completo per bus di servizio spazio dei nomi. Per gli altri valori delle proprietà, vedere Microsoft Entra ID Open Authentication. |
| Identità gestita | Nome completo per lo spazio dei nomi bus di servizio, <ad esempio your-Service-Bus-namespace.servicebus.windows.net.> Per altre informazioni, vedere Ottenere un nome completo per bus di servizio spazio dei nomi. |
Ottenere stringa di connessione per lo spazio dei nomi bus di servizio
Per creare una connessione quando si aggiunge un trigger o un'azione bus di servizio, è necessario disporre del stringa di connessione per lo spazio dei nomi bus di servizio. Il stringa di connessione inizia con il prefisso sb://.
Nella portale di Azure aprire lo spazio dei nomi bus di servizio.
Nel menu dello spazio dei nomi, in Impostazioni, selezionare Criteri di accesso condiviso.
Nel riquadro Criteri di accesso condiviso selezionare RootManageSharedAccessKey.
Accanto al stringa di connessione primario o secondario, selezionare il pulsante Copia.
Nota
Per verificare che la stringa sia relativa allo spazio dei nomi, non a un'entità di messaggistica specifica, cercare il parametro nel stringa di connessione
EntityPath. Se si trova questo parametro, il stringa di connessione è destinato a 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 bus di servizio
Se si usa il connettore gestito bus di servizio, è necessario questo URL dell'endpoint se si seleziona il tipo di autenticazione per Identità gestita di Microsoft Entra integrata o App per la logica. L'URL dell'endpoint inizia con il prefisso sb:// .
Nella portale di Azure aprire lo spazio dei nomi bus di servizio.
Nel menu dello spazio dei nomi, in Impostazioni, selezionare Proprietà.
In Proprietà, accanto all'endpoint 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 un nome completo per lo spazio dei nomi bus di servizio
Nella portale di Azure aprire lo spazio dei nomi bus di servizio.
Nel menu dello spazio dei nomi selezionare Panoramica.
Nel riquadro Panoramica individuare 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 bus di servizio
I passaggi seguenti usano la 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 dell'app per la logica:
Flussi di lavoro delle app per la logica a consumo: Visual Studio o Visual Studio Code
Flussi di lavoro dell'app per la logica standard: Visual Studio Code
Nella portale di Azure aprire la risorsa dell'app per la logica a consumo con un flusso di lavoro vuoto nella finestra di progettazione.
Nella finestra di progettazione seguire questa procedura generale per aggiungere il trigger bus di servizio di Azure desiderato.
Questo esempio continua con il trigger denominato Quando viene ricevuto un messaggio in una coda (completamento automatico) .
Se richiesto, specificare le informazioni seguenti per la connessione. Al termine, seleziona Crea.
Proprietà Richiesto Descrizione Nome connessione Sì Nome della connessione Tipo di autenticazione Sì Tipo di autenticazione da usare per l'accesso allo spazio dei nomi bus di servizio. Per altre informazioni, vedere Autenticazione del connettore gestito. Stringa di connessione Sì Il stringa di connessione copiato e salvato in precedenza. Ad esempio, questa connessione usa l'autenticazione della chiave di accesso e fornisce il stringa di connessione per uno spazio dei nomi bus di servizio:
Dopo aver visualizzato la casella delle informazioni sul trigger, specificare le informazioni necessarie, ad esempio:
Proprietà Richiesto Descrizione Nome coda Sì Coda selezionata per accedere Tipo di coda No Tipo per la coda selezionata Specificare la frequenza in base a cui verificare gli elementi. Sì Intervallo di polling e 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 di bus di servizio
I passaggi seguenti usano la 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 dell'app per la logica:
Flussi di lavoro delle app per la logica a consumo: Visual Studio o Visual Studio Code
Flussi di lavoro dell'app per la logica standard: Visual Studio Code
Nella portale di Azure aprire l'app per la logica a consumo e il flusso di lavoro nella finestra di progettazione.
Nella finestra di progettazione seguire questa procedura generale per aggiungere l'azione bus di servizio di Azure desiderata.
Questo esempio continua con l'azione Invia messaggio .
Se richiesto, specificare le informazioni seguenti per la connessione. Al termine, seleziona Crea.
Proprietà Richiesto Descrizione Nome connessione Sì Nome della connessione Tipo di autenticazione Sì Tipo di autenticazione da usare per l'accesso allo spazio dei nomi bus di servizio. Per altre informazioni, vedere Autenticazione del connettore gestito. Stringa di connessione Sì Il stringa di connessione copiato e salvato in precedenza. Ad esempio, questa connessione usa l'autenticazione della chiave di accesso e fornisce il stringa di connessione per uno spazio dei nomi bus di servizio:
Dopo aver visualizzato la casella delle informazioni sull'azione, specificare le informazioni necessarie, ad esempio:
Proprietà Richiesto Descrizione Nome coda/argomento Sì Destinazione della coda o dell'argomento selezionato per l'invio del messaggio ID sessione No ID sessione se si invia il messaggio a una coda o a un argomento compatibile con la sessione Proprietà di 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 eventuali altre azioni necessarie per il flusso di lavoro.
Ad esempio, è possibile aggiungere un'azione che invia un messaggio di posta elettronica per confermare che il messaggio è stato inviato.
Al termine, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.
bus di servizio impostazioni predefinite dell'app del connettore
In una risorsa dell'app per la logica Standard, il connettore predefinito 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, vedere Informazioni di riferimento sulle impostazioni dell'app - local.settings.json.
Leggere i messaggi da code di messaggi non recapitabili con trigger predefiniti bus di servizio
Nei flussi di lavoro Standard, per leggere un messaggio da una coda di messaggi non recapitabili in una coda o in una sottoscrizione di argomenti, seguire questa procedura usando i trigger specificati:
Nel flusso di lavoro vuoto, in base allo scenario in uso, aggiungere il trigger del connettore predefinito bus di servizio denominato When messages are available in a queue (Quando i messaggi sono disponibili in una coda) o Quando un messaggio è disponibile in una sottoscrizione di argomento (peek-lock).
Nel trigger impostare i valori dei parametri seguenti per specificare la coda o la coda di messaggi non recapitabili predefinita della sottoscrizione dell'argomento, a cui è possibile accedere come qualsiasi altra coda:
Quando i messaggi sono disponibili in un trigger della coda : impostare il parametro Nome coda su queuename/$deadletterqueue.
Quando un messaggio è disponibile in una sottoscrizione dell'argomento (peek-lock) trigger: impostare il parametro Nome argomento su topicname/Subscriptions/subscriptionname/$deadletterqueue.
Per altre informazioni, vedere bus di servizio panoramica delle code di messaggi non recapitabili.
Risoluzione dei problemi
Ritardi negli aggiornamenti apportati al flusso di lavoro
Se l'intervallo di polling di un trigger di bus di servizio è ridotto, ad esempio 10 secondi, gli aggiornamenti al flusso di lavoro potrebbero non essere effettivi per un 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
In alcuni casi, le 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 bus di servizio usa la cache in memoria per supportare tutte le operazioni associate alle sessioni. Il ricevitore di messaggi 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 è obbligatorio perché tutte le operazioni di bus di servizio in una sessione richiedono lo stesso ricevitore che riceve i messaggi per una sessione specifica.
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 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, l'errore è previsto. Quando si verifica l'errore, il messaggio viene ancora mantenuto nel bus di servizio. Il trigger successivo o l'esecuzione del flusso di lavoro tenta di elaborare di nuovo il messaggio.