Ansluta till Azure Service Bus från arbetsflöden i Azure Logic Apps
Gäller för: Azure Logic Apps (Förbrukning + Standard)
Den här guiden visar hur du får åtkomst till Azure Service Bus från ett arbetsflöde i Azure Logic Apps med hjälp av Service Bus-anslutningsappen. Du kan sedan skapa automatiserade arbetsflöden som körs när de utlöses av händelser i en Service Bus eller kör åtgärder för att hantera Service Bus-objekt, till exempel:
- Övervaka när meddelanden tas emot (automatiskt slutförda) eller tas emot (peek-lock) i köer, ämnen och ämnesprenumerationer.
- Skicka meddelanden.
- Skapa och ta bort ämnesprenumerationer.
- Hantera meddelanden i köer och ämnesprenumerationer, till exempel hämta, skjuta upp, slutföra, skjuta upp, överge och obeställbara meddelanden.
- Förnya lås på meddelanden och sessioner i köer och ämnesprenumerationer.
- Stäng sessioner i köer och ämnen.
Du kan använda utlösare som får svar från Azure Service Bus och göra utdata tillgängliga för andra åtgärder i dina arbetsflöden. Du kan också låta andra åtgärder använda utdata från Service Bus-åtgärder.
Teknisk referens för anslutningsprogram
Service Bus-anslutningsappen har olika versioner, baserat på logikappens arbetsflödestyp och värdmiljö.
| Logikapp | Environment | Anslutningsversion |
|---|---|---|
| Förbrukning | Azure Logic Apps med flera klientorganisationer | Hanterad anslutningsapp, som visas i anslutningsgalleriet under Runtime>Shared. Obs! Service Bus-hanterade anslutningsutlösare följer det långa avsökningsutlösarmönstret, vilket innebär att utlösaren regelbundet söker efter meddelanden i kön eller ämnesprenumerationen. Mer information finns i följande dokumentation: - Referens för hanterad Service Bus-anslutningsapp - Hanterade anslutningsappar i Azure Logic Apps |
| Standard | Azure Logic Apps för en klientorganisation och App Service-miljön v3 (endast Windows-abonnemang) | Hanterad anslutningsapp (Azure-värdbaserad), som visas i anslutningsgalleriet under Runtime>Shared och inbyggd anslutningsapp, som visas i anslutningsgalleriet under Runtime>In App och är tjänstleverantörsbaserad. De hanterade Anslutningsutlösarna för Service Bus följer det långa avsökningsutlösarmönstret, vilket innebär att utlösaren regelbundet söker efter meddelanden i kön eller ämnesprenumerationen. De inbyggda utlösarna för Service Bus-anslutningstjänsten som inte är sessionsutlösare följer ett mönster för kontinuerlig avsökningsutlösare som hanteras helt av anslutningsappen. Det här mönstret har utlösaren som ständigt söker efter meddelanden i kön eller ämnesprenumerationen. Sessionsutlösare följer utlösarmönstret för lång avsökning, men dess konfiguration styrs av Azure Functions-inställningen clientRetryOptions :tryTimeout. Den inbyggda versionen ger vanligtvis bättre prestanda, funktioner, priser och så vidare. |
Mer information finns i följande dokumentation: - Referens för hanterad Service Bus-anslutningsapp - Inbyggda Service Bus-anslutningsåtgärder - Inbyggda anslutningsappar i Azure Logic Apps |
Förutsättningar
Ett Azure-konto och prenumeration. Om du heller inte har någon Azure-prenumeration kan du registrera ett kostnadsfritt Azure-konto.
En Service Bus-namnrymd och meddelandeentitet, till exempel en kö. Mer information finns i följande dokumentation:
Arbetsflödet för logikappen där du ansluter till din Service Bus-namnrymd och meddelandeentitet. Om du vill starta arbetsflödet med en Service Bus-utlösare måste du börja med ett tomt arbetsflöde. Om du vill använda en Service Bus-åtgärd i arbetsflödet startar du arbetsflödet med valfri utlösare.
Om logikappresursen använder en hanterad identitet för att autentisera åtkomsten till din Service Bus-namnrymd och meddelandeentitet kontrollerar du att du har tilldelat rollbehörigheter på motsvarande nivåer. För att få åtkomst till en kö kräver den hanterade identiteten till exempel en roll som har de behörigheter som krävs för kön.
Varje logikappresurs bör endast använda en hanterad identitet, även om logikappens arbetsflöde har åtkomst till olika meddelandeentiteter.
Varje hanterad identitet som har åtkomst till en kö- eller ämnesprenumeration bör använda sin egen Service Bus API-anslutning.
Service Bus-åtgärder som utbyter meddelanden med olika meddelandeentiteter och kräver olika behörigheter bör använda sina egna Service Bus API-anslutningar.
Mer information om hanterade identiteter finns i Autentisera åtkomst till Azure-resurser med hanterade identiteter i Azure Logic Apps.
Som standard är de inbyggda Service Bus-anslutningsåtgärderna tillståndslösa. Information om hur du kör dessa åtgärder i tillståndskänsligt läge finns i Aktivera tillståndskänsligt läge för tillståndslösa inbyggda anslutningsappar.
Överväganden för Azure Service Bus-åtgärder
Oändliga loopar
Viktigt!
Var försiktig när du väljer både en utlösare och en åtgärd som har samma anslutningstyp och använder dem för att arbeta med samma entitet, till exempel en meddelandekö eller ämnesprenumeration. Den här kombinationen kan skapa en oändlig loop, vilket resulterar i en logikapp som aldrig slutar.
Gräns för sparade sessioner i anslutningscachen
Per Service Bus-meddelandeentitet, till exempel en prenumeration eller ett ämne, kan Service Bus-anslutningstjänsten spara upp till 1 500 unika sessioner åt gången i anslutningscachen. Om antalet sessioner överskrider den här gränsen tas gamla sessioner bort från cacheminnet. Mer information finns i Meddelandesessioner.
Skicka korrelerade meddelanden i ordning
När du behöver skicka relaterade meddelanden i en viss ordning kan du skapa ett arbetsflöde med hjälp av Service Bus-anslutningsappen och mönstret för sekventiell konvoj. Korrelerade meddelanden har en egenskap som definierar relationen mellan dessa meddelanden, till exempel ID:t för sessionen i Azure Service Bus.
När du skapar ett arbetsflöde för förbrukningslogikappen kan du välja mallen Korrelerad leverans i ordning med hjälp av service bus-sessionsmallen , som implementerar det sekventiella konvojmönstret. Mer information finns i Skicka relaterade meddelanden i ordning.
Stöd för stora meddelanden
Stöd för stora meddelanden är endast tillgängligt för Standard-arbetsflöden när du använder de inbyggda Service Bus-anslutningsåtgärderna. Du kan till exempel ta emot och stora meddelanden med hjälp av de inbyggda utlösarna respektive åtgärderna.
För den hanterade Service Bus-anslutningsappen är den maximala meddelandestorleken begränsad till 1 MB, även när du använder ett Service Bus-namnområde på premiumnivå.
Öka tidsgränsen för att ta emot och skicka meddelanden
I Standard-arbetsflöden som använder de inbyggda Service Bus-åtgärderna kan du öka tidsgränsen för att ta emot och skicka meddelanden. Om du till exempel vill öka tidsgränsen för att ta emot ett meddelande ändrar du följande inställning i Azure Functions-tillägget:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
"version": "[1.*, 2.0.0)"
},
"extensions": {
"serviceBus": {
"batchOptions": {
"operationTimeout": "00:15:00"
}
}
}
}
Om du vill öka tidsgränsen för att skicka ett meddelande lägger du till appinställningen ServiceProviders.ServiceBus.MessageSenderOperationTimeout.
Service Bus-hanterade anslutningsutlösare
För den hanterade Service Bus-anslutningsappen är alla utlösare långa avsökningar. Den här utlösartypen bearbetar alla meddelanden och väntar sedan 30 sekunder på att fler meddelanden ska visas i kön eller ämnesprenumerationen. Om inga meddelanden visas efter 30 sekunder hoppas utlösarkörningen över. Annars fortsätter utlösaren att läsa meddelanden tills kön eller ämnesprenumerationen är tom. Nästa utlösaravsökning baseras på det upprepningsintervall som anges i utlösarens egenskaper.
Vissa utlösare, till exempel utlösaren När ett eller flera meddelanden tas emot i en kö (automatisk komplettering) kan returnera ett eller flera meddelanden. När dessa utlösare utlöses returnerar de mellan ett och antalet meddelanden som anges av utlösarens egenskap Maximalt antal meddelanden.
Kommentar
Utlösaren för automatisk komplettering slutför automatiskt ett meddelande, men slutförandet sker bara vid nästa anrop till Service Bus. Det här beteendet kan påverka arbetsflödets design. Undvik till exempel att ändra samtidigheten för utlösaren för automatisk komplettering eftersom den här ändringen kan resultera i dubbletter av meddelanden om arbetsflödet har ett begränsat tillstånd. Om du ändrar samtidighetskontrollen skapas följande villkor:
Begränsade utlösare hoppas över med
WorkflowRunInProgresskoden.Slutförandeåtgärden körs inte.
Nästa utlösarkörning sker efter avsökningsintervallet.
Du måste ange varaktigheten för Service Bus-låset till ett värde som är längre än avsökningsintervallet. Trots den här inställningen kanske meddelandet fortfarande inte slutförs om arbetsflödet förblir i ett begränsat tillstånd vid nästa avsökningsintervall.
Men om du aktiverar en Service Bus-utlösares samtidighetsinställning är standardvärdet för
maximumWaitingRunsegenskapen 10. Baserat på service bus-entitetens inställning för låsvaraktighet och körningstiden för arbetsflödet kan det här standardvärdet vara för stort och kan orsaka ett undantag om att låset går förlorat. Om du vill hitta det optimala värdet för ditt scenario börjar du testa med värdet 1 eller 2 förmaximumWaitingRunsegenskapen. Om du vill ändra värdet för maximalt antal väntande körningar läser du Ändra gränsen för väntande körningar.
Inbyggda Anslutningsutlösare för Service Bus
För den inbyggda Service Bus-anslutningsappen följer utlösare som inte är sessioner ett mönster för kontinuerlig avsökningsutlösare som hanteras helt av anslutningsappen. Det här mönstret har utlösaren som ständigt söker efter meddelanden i kön eller ämnesprenumerationen. Sessionsutlösare följer utlösningsmönstret för lång avsökning, och dess konfiguration styrs av Azure Functions-inställningen clientRetryOptions :tryTimeout. För närvarande delas konfigurationsinställningarna för den inbyggda Service Bus-utlösaren mellan Azure Functions-värdtillägget, som definieras i logikappens host.json-fil, och de utlösarinställningar som definierats i logikappens arbetsflöde, som du kan konfigurera antingen via designer- eller kodvyn. Det här avsnittet beskriver båda inställningsplatserna.
I Standard-arbetsflöden kan vissa utlösare, till exempel När meddelanden är tillgängliga i en köutlösare , returnera ett eller flera meddelanden. När dessa utlösare utlöses returnerar de mellan ett och antalet meddelanden. För den här typen av utlösare och där parametern Maximalt antal meddelanden inte stöds kan du fortfarande styra antalet meddelanden som tas emot med hjälp av egenskapen maxMessageBatchSize i filen host.json. Information om hur du hittar den här filen finns i Redigera värd- och appinställningar för standardlogikappar.
"extensions": { "serviceBus": { "maxMessageBatchSize": 25 } }Du kan också aktivera samtidighet på Service Bus-utlösaren, antingen via designern eller i kod:
"runtimeConfiguration": { "concurrency": { "runs": 100 } }När du konfigurerar samtidighet med hjälp av en batch behåller du antalet samtidiga körningar som är större än den totala batchstorleken. På så sätt hamnar läsmeddelanden inte i väntetillstånd och hämtas alltid när de läss. I vissa fall kan utlösaren ha upp till dubbelt så stor batchstorlek.
Om du aktiverar samtidighet minskas gränsen för SplitOn till 100 objekt. Det här beteendet gäller för alla utlösare, inte bara Service Bus-utlösaren. Kontrollera att den angivna batchstorleken är mindre än den här gränsen för alla utlösare där du aktiverar samtidighet.
Vissa scenarier finns där utlösaren kan överskrida samtidighetsinställningarna. I stället för att misslyckas köar Azure Logic Apps dem i vänteläge tills de kan startas. Inställningen maximumWaitingRuns styr antalet körningar som tillåts i väntetillståndet:
"runtimeConfiguration": { "concurrency": { "runs": 100, "maximumWaitingRuns": 50 } }Med Service Bus-utlösaren kontrollerar du att du noggrant testar dessa ändringar så att körningarna inte väntar längre än tidsgränsen för meddelandelåset. Mer information om standardvärdena finns i Concurrency and de-batching limits here (Samtidighets- och debatcheringsgränser här).
Om du aktiverar samtidighet finns det som standard en fördröjning på 30 sekunder mellan batchläsningar. Den här fördröjningen saktar ned utlösaren för att uppnå följande mål:
Minska antalet lagringsanrop som skickas för att kontrollera hur många körningar som samtidigheten ska tillämpas på.
Efterlikna beteendet för den hanterade Anslutningsutlösaren för Service Bus, som har en 30 sekunder lång avsökning när inga meddelanden hittas.
Du kan ändra den här fördröjningen, men kontrollera att du noggrant testar alla ändringar i standardvärdet:
"workflow": { "settings": { "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30" } }
Steg 1: Kontrollera åtkomsten till Service Bus-namnområdet
Använd följande steg för att bekräfta att logikappresursen har behörighet att komma åt Service Bus-namnområdet:
I Azure Portal öppnar du Service Bus-namnområdet.
På namnområdesmenyn går du till Inställningar och väljer Principer för delad åtkomst. Under Anspråk kontrollerar du att du har Hantera behörigheter för det namnområdet.
Steg 2: Hämta krav för anslutningsautentisering
Senare, när du lägger till en Service Bus-utlösare eller åtgärd för första gången, uppmanas du att ange anslutningsinformation, inklusive typ av anslutningsautentisering. Baserat på arbetsflödestypen för logikappen, Service Bus-anslutningsversionen och den valda autentiseringstypen behöver du följande:
Autentisering av hanterad anslutningsapp (förbrukning och standardarbetsflöden)
| Authentication type | Nödvändig information |
|---|---|
| Åtkomstnyckel | Anslutningssträng för Service Bus-namnområdet. Mer information finns i Hämta anslutningssträng för Service Bus-namnområdet |
| Microsoft Entra-integrerat | Slutpunkts-URL:en för Service Bus-namnområdet. Mer information finns i Hämta slutpunkts-URL för Service Bus-namnområdet. |
| Hanterad identitet för Logic Apps | Slutpunkts-URL:en för Service Bus-namnområdet. Mer information finns i Hämta slutpunkts-URL för Service Bus-namnområdet. |
Inbyggd autentisering av anslutningsappar (endast standardarbetsflöden)
| Authentication type | Nödvändig information |
|---|---|
| Anslutningssträng | Anslutningssträng för Service Bus-namnområdet. Mer information finns i Hämta anslutningssträng för Service Bus-namnområdet |
| Active Directory OAuth | – Det fullständigt kvalificerade namnet på ditt Service Bus-namnområde, <till exempel your-Service-Bus-namespace.servicebus.windows.net.> Mer information finns i Hämta fullständigt kvalificerat namn för Service Bus-namnområdet. De andra egenskapsvärdena finns i OAuth med Microsoft Entra-ID. |
| Hanterade identiteter | Det fullständigt kvalificerade namnet på ditt Service Bus-namnområde, <till exempel din-Service-Bus-namespace.servicebus.windows.net.> Mer information finns i Hämta fullständigt kvalificerat namn för Service Bus-namnområdet. |
Hämta anslutningssträng för Service Bus-namnområdet
Om du vill skapa en anslutning när du lägger till en Service Bus-utlösare eller -åtgärd måste du ha anslutningssträng för Service Bus-namnområdet. Anslutningssträng börjar med prefixet sb://.
I Azure Portal öppnar du Service Bus-namnområdet.
På namnområdesmenyn går du till Inställningar och väljer Principer för delad åtkomst.
I fönstret Principer för delad åtkomst väljer du RootManageSharedAccessKey.
Bredvid den primära eller sekundära anslutningssträng väljer du kopieringsknappen.
Kommentar
Om du vill kontrollera att strängen är för namnområdet, inte en specifik meddelandeentitet, söker du efter parametern
EntityPathi anslutningssträng. Om du hittar den här parametern är anslutningssträng för en viss entitet och är inte rätt sträng att använda med arbetsflödet.Spara anslutningssträng för senare användning.
Hämta slutpunkts-URL för Service Bus-namnområdet
Om du använder den hanterade Service Bus-anslutningsappen behöver du den här slutpunkts-URL:en om du väljer antingen autentiseringstyp för Microsoft Entra-integrerad eller Logic Apps Managed Identity. Slutpunkts-URL:en börjar med prefixet sb:// .
I Azure Portal öppnar du Service Bus-namnområdet.
På namnområdesmenyn går du till Inställningar och väljer Egenskaper.
Under Egenskaper, bredvid Service Bus-slutpunkten, kopierar du slutpunkts-URL:en och sparar för senare användning när du måste ange SERVICE Bus-slutpunkts-URL:en.
Hämta fullständigt kvalificerat namn för Service Bus-namnområdet
I Azure Portal öppnar du Service Bus-namnområdet.
På namnområdesmenyn väljer du Översikt.
I fönstret Översikt letar du reda på egenskapen Värdnamn och kopierar det fullständigt kvalificerade namnet, som ser ut som< your-Service-Bus-namespace.servicebus.windows.net.>
Steg 3: Alternativ 1 – Lägg till en Service Bus-utlösare
Följande steg använder Azure Portal, men med lämpligt Azure Logic Apps-tillägg kan du också använda följande verktyg för att skapa arbetsflöden för logikappar:
Arbetsflöden för förbrukningslogikapp: Visual Studio eller Visual Studio Code
Arbetsflöden för standardlogikapp: Visual Studio Code
I Azure Portal öppnar du din förbrukningslogikappresurs med ett tomt arbetsflöde i designern.
I designern följer du de här allmänna stegen för att lägga till den Azure Service Bus-utlösare som du vill använda.
Det här exemplet fortsätter med utlösaren med namnet When a message is received in a queue (auto-complete).
Ange följande information för anslutningen om du uppmanas att göra det. Välj Skapa när du är klar.
Property Obligatoriskt Beskrivning Anslutningens namn Ja Ett namn på anslutningen Autentiseringstyp Ja Den typ av autentisering som ska användas för åtkomst till Service Bus-namnområdet. Mer information finns i Hanterad anslutningsappsautentisering. Anslutningssträng Ja Den anslutningssträng som du kopierade och sparade tidigare. Den här anslutningen använder till exempel åtkomstnyckelautentisering och tillhandahåller anslutningssträng för ett Service Bus-namnområde:
När informationsrutan för utlösaren visas anger du nödvändig information, till exempel:
Property Obligatoriskt Beskrivning Könamn Ja Den valda kön för åtkomst Kötyp Nej Typen för den valda kön Hur ofta vill du söka efter objekt? Ja Avsökningsintervallet och frekvensen för att kontrollera kön efter objekt 
Om du vill lägga till andra tillgängliga egenskaper i utlösaren öppnar du listan Lägg till ny parameter och väljer de egenskaper som du vill använda.
Lägg till åtgärder som ditt arbetsflöde behöver.
Du kan till exempel lägga till en åtgärd som skickar e-post när ett nytt meddelande kommer. När utlösaren kontrollerar kön och hittar ett nytt meddelande kör arbetsflödet de valda åtgärderna för det hittade meddelandet.
Spara arbetsflödet när du är klar. I verktygsfältet för designern väljer du Spara.
Steg 3: Alternativ 2 – Lägg till en Service Bus-åtgärd
Följande steg använder Azure Portal, men med lämpligt Azure Logic Apps-tillägg kan du också använda följande verktyg för att skapa arbetsflöden för logikappar:
Arbetsflöden för förbrukningslogikapp: Visual Studio eller Visual Studio Code
Arbetsflöden för standardlogikapp: Visual Studio Code
Öppna logikappen och arbetsflödet för förbrukning i designern i Azure Portal.
I designern följer du de här allmänna stegen för att lägga till den Azure Service Bus-åtgärd som du vill använda.
Det här exemplet fortsätter med åtgärden Skicka meddelande .
Ange följande information för anslutningen om du uppmanas att göra det. Välj Skapa när du är klar.
Property Obligatoriskt Beskrivning Anslutningens namn Ja Ett namn på anslutningen Autentiseringstyp Ja Den typ av autentisering som ska användas för åtkomst till Service Bus-namnområdet. Mer information finns i Hanterad anslutningsappsautentisering. Anslutningssträng Ja Den anslutningssträng som du kopierade och sparade tidigare. Den här anslutningen använder till exempel åtkomstnyckelautentisering och tillhandahåller anslutningssträng för ett Service Bus-namnområde:
När åtgärdsinformationsrutan visas anger du nödvändig information, till exempel:
Property Obligatoriskt Beskrivning Kö-/ämnesnamn Ja Den valda kön eller ämnesmålet för att skicka meddelandet Sessions-ID Nej Sessions-ID:t om du skickar meddelandet till en sessionsmedveten kö eller ett ämne Systemegenskaper Nej - None
- Kör information: Lägg till information om metadataegenskap om körningen som anpassade egenskaper i meddelandet.
Om du vill lägga till andra tillgängliga egenskaper i åtgärden öppnar du listan Lägg till ny parameter och väljer de egenskaper som du vill använda.
Lägg till andra åtgärder som ditt arbetsflöde behöver.
Du kan till exempel lägga till en åtgärd som skickar e-post för att bekräfta att meddelandet har skickats.
Spara arbetsflödet när du är klar. I verktygsfältet för designern väljer du Spara.
Inställningar för den inbyggda anslutningsappen i Service Bus
I en standardlogikappresurs innehåller den inbyggda Service Bus-anslutningsappen appinställningar som styr olika tröskelvärden, till exempel timeout för att skicka meddelanden och antal meddelandeavsändare per processorkärna i meddelandepoolen. Mer information finns i Referens för appinställningar – local.settings.json.
Läsa meddelanden från köer med obeställbara meddelanden med inbyggda Service Bus-utlösare
Följ dessa steg med de angivna utlösarna för att läsa ett meddelande från en kö med obeställbara meddelanden i en kö eller en ämnesprenumeration i Standard-arbetsflöden:
I ditt tomma arbetsflöde, baserat på ditt scenario, lägger du till den inbyggda Anslutningsutlösaren för Service Bus med namnet När meddelanden är tillgängliga i en kö eller När ett meddelande är tillgängligt i en ämnesprenumeration (peek-lock).
I utlösaren anger du följande parametervärden för att ange kön eller ämnesprenumerationens standardkö med obeställbara meddelanden, som du kan komma åt som alla andra köer:
När meddelanden är tillgängliga i en köutlösare : Ange parametern Könamn till queuename/$deadletterqueue.
När ett meddelande är tillgängligt i en ämnesprenumeration (peek-lock) -utlösare: Ange parametern Ämnesnamn till topicname/Subscriptions/subscriptionname/$deadletterqueue.
Mer information finns i Översikt över köer med obeställbara servicebussar.
Felsökning
Fördröjningar i uppdateringar av arbetsflödet börjar gälla
Om avsökningsintervallet för en Service Bus-utlösare är litet, till exempel 10 sekunder, kanske uppdateringar av arbetsflödet inte börjar gälla på upp till 10 minuter. Du kan lösa det här problemet genom att inaktivera logikappresursen, göra ändringarna och sedan aktivera logikappresursen igen.
Ingen session är tillgänglig eller kan vara låst av en annan mottagare
Ibland kan åtgärder som att slutföra ett meddelande eller förnya en session generera följande fel:
{
"status": 400,
"error": {
"message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
}
}
Ibland kan en sessionsbaserad utlösare misslyckas med följande fel:
{
"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."
}
}
Service Bus-anslutningsappen använder minnesintern cache för att stödja alla åtgärder som är associerade med sessionerna. Service Bus-meddelandemottagaren cachelagras i minnet för rollinstansen (virtuell dator) som tar emot meddelandena. För att bearbeta alla begäranden dirigeras alla anrop för anslutningen till samma rollinstans. Det här beteendet krävs eftersom alla Service Bus-åtgärder i en session kräver samma mottagare som tar emot meddelandena för en viss session.
På grund av orsaker som en infrastrukturuppdatering, anslutningsdistribution och så vidare finns det en möjlighet för begäranden att inte dirigeras till samma rollinstans. Om den här händelsen inträffar misslyckas begäranden av någon av följande orsaker:
Mottagaren som utför åtgärderna i sessionen är inte tillgänglig i rollinstansen som hanterar begäran.
Den nya rollinstansen försöker hämta sessionen, som antingen överskrider tidsgränsen i den gamla rollinstansen eller inte stängdes.
Så länge det här felet bara inträffar ibland förväntas felet. När felet inträffar bevaras meddelandet fortfarande i Service Bus. Nästa utlösare eller arbetsflödeskörning försöker bearbeta meddelandet igen.