Skicka relaterade meddelanden i ordning med hjälp av en sekventiell konvoj i Azure Logic Apps med Azure Service Bus
Gäller för: Azure Logic Apps (förbrukning)
När du behöver skicka korrelerade meddelanden i en viss ordning kan du följa det sekventiella konvojmönstret när du använder Azure Logic Apps med hjälp av Azure Service Bus-anslutningsappen. Korrelerade meddelanden har en egenskap som definierar relationen mellan dessa meddelanden, till exempel ID:t för sessionen i Service Bus.
Anta till exempel att du har 10 meddelanden för en session med namnet "Session 1" och att du har 5 meddelanden för en session med namnet "Session 2" som alla skickas till samma Service Bus-kö. Du kan skapa en logikapp som bearbetar meddelanden från kön så att alla meddelanden från "Session 1" hanteras av en enda utlösarkörning och alla meddelanden från "Session 2" hanteras av nästa utlösarkörning.
Den här artikeln visar hur du skapar en logikapp som implementerar det här mönstret med hjälp av mallen Korrelerad leverans i ordning med hjälp av service bus-sessionsmallen . Den här mallen definierar ett arbetsflöde för logikappen som börjar med Service Bus-anslutningsappens När ett meddelande tas emot i en köutlösare (peek-lock), som tar emot meddelanden från en Service Bus-kö. Här är de övergripande stegen som den här logikappen utför:
Initiera en session baserat på ett meddelande som utlösaren läser från Service Bus-kön.
Läsa och bearbeta alla meddelanden från samma session i kön under den aktuella arbetsflödeskörningen.
Om du vill granska den här mallens JSON-fil kan du läsa GitHub: service-bus-sessions.json.
Mer information finns i Sekventiellt konvojmönster – Azure Architecture Cloud Design Patterns.
Förutsättningar
En Azure-prenumeration. Om du inte har någon prenumeration kan du registrera ett kostnadsfritt Azure-konto.
Ett Service Bus-namnområde och en Service Bus-kö, som är en meddelandeentitet som du ska använda i logikappen. Dessa objekt och logikappen måste använda samma Azure-prenumeration. Kontrollera att du väljer Aktivera sessioner när du skapar kön. Om du inte har de här objekten kan du lära dig hur du skapar ditt Service Bus-namnområde och en kö.
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.
Grundläggande kunskaper om hur du skapar logikappar. Om du inte har använt Azure Logic Apps tidigare kan du prova snabbstarten som skapar ett exempel på arbetsflödet för förbrukningslogikappen i Azure Logic Apps med flera klientorganisationer.
Kontrollera åtkomsten till Service Bus-namnområdet
Om du inte är säker på om logikappen har behörighet att komma åt Service Bus-namnområdet kontrollerar du dessa behörigheter.
Logga in på Azure-portalen. Leta upp och välj ditt Service Bus-namnområde.
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.
Hämta nu anslutningssträng för Service Bus-namnområdet. Du kan använda den här strängen senare när du skapar en anslutning till namnområdet från logikappen.
I fönstret Principer för delad åtkomst går du till Princip och väljer RootManageSharedAccessKey.
Bredvid din primära anslutningssträng väljer du kopieringsknappen. Spara anslutningssträng för senare användning.
Dricks
Om du vill bekräfta om din anslutningssträng är associerad med service bus-namnområdet eller en meddelandeentitet, till exempel en kö, söker du efter parametern
EntityPath
i anslutningssträng. Om du hittar den här parametern är anslutningssträng för en specifik entitet och är inte rätt sträng att använda med logikappen.
Skapa en logikapp
I det här avsnittet skapar du en logikapp med hjälp av mallen Korrelerad orderleverans med hjälp av service bus-sessionsmallen , som innehåller utlösaren och åtgärderna för att implementera det här arbetsflödesmönstret. Du skapar också en anslutning till Service Bus-namnområdet och anger namnet på den Service Bus-kö som du vill använda.
I Azure Portal skapar du en tom logikapp. På Startsidan för Azure väljer du Skapa en resursintegreringslogikapp>>.
När mallgalleriet visas bläddrar du förbi videon och de vanliga avsnitten för utlösare. I avsnittet Mallar väljer du mallen, Korrelerad leverans i ordning med service bus-sessioner.
När bekräftelserutan visas väljer du Använd den här mallen.
I form av Service Bus i Logikappdesignern väljer du Fortsätt och sedan plustecknet (+) som visas i formen.
Skapa nu en Service Bus-anslutning genom att välja något av alternativen:
Följ dessa steg om du vill använda anslutningssträng som du kopierade tidigare från Service Bus-namnområdet:
Välj Ange anslutningsinformation manuellt.
För Anslutningsnamn anger du ett namn för anslutningen. För Anslutningssträng klistrar du in ditt namnområde anslutningssträng och väljer Skapa, till exempel:
Dricks
Om du inte har den här anslutningssträng kan du lära dig hur du hittar och kopierar Service Bus-namnområdet anslutningssträng.
Följ dessa steg för att välja ett Service Bus-namnområde från din aktuella Azure-prenumeration:
För Anslutningsnamn anger du ett namn för anslutningen. För Service Bus-namnområde väljer du ditt Service Bus-namnområde, till exempel:
När nästa fönster visas väljer du din Service Bus-princip och väljer Skapa.
När du är klar väljer du Fortsätt.
Logikappdesignern visar nu den korrelerade leveransen i ordning med hjälp av service bus-sessionsmallen , som innehåller ett förifyllt arbetsflöde med en utlösare och åtgärder, inklusive två omfång som implementerar felhantering som följer
Try-Catch
mönstret.
Nu kan du antingen lära dig mer om utlösaren och åtgärderna i mallen eller gå vidare för att ange värdena för logikappmallen.
Mallsammanfattning
Här är arbetsflödet på den översta nivån i mallen Korrelerad orderleverans med hjälp av service bus-sessionsmallen när informationen är komprimerad:
Name | beskrivning |
---|---|
When a message is received in a queue (peek-lock) |
Baserat på den angivna upprepningen kontrollerar den här Service Bus-utlösaren den angivna Service Bus-kön efter meddelanden. Om det finns ett meddelande i kön utlöses utlösaren, vilket skapar och kör en arbetsflödesinstans. Termen peek-lock innebär att utlösaren skickar en begäran om att hämta ett meddelande från kön. Om ett meddelande finns hämtar och låser utlösaren meddelandet så att ingen annan bearbetning sker i meddelandet förrän låsperioden går ut. Mer information finns i Initiera sessionen. |
Init isDone |
Den här åtgärden Initiera variabel skapar en boolesk variabel som är inställd på false och anger när följande villkor är sanna:– Det finns inga fler meddelanden i sessionen att läsa. Mer information finns i Initiera sessionen. |
Try |
Den här omfångsåtgärden innehåller de åtgärder som körs för att bearbeta ett meddelande. Om ett problem inträffar i omfånget Try hanterar den efterföljande Catch omfångsåtgärden det problemet. Mer information finns i omfånget "Prova". |
Catch |
Den här omfångsåtgärden innehåller de åtgärder som körs om ett problem inträffar i föregående Try omfång. Mer information finns i omfånget "Catch". |
"Prova"-omfång
Här är det översta flödet i omfångsåtgärden Try
när informationen komprimeras:
Name | beskrivning |
---|---|
Send initial message to topic |
Du kan ersätta den här åtgärden med den åtgärd som du vill hantera det första meddelandet från sessionen i kön. Sessions-ID anger sessionen. För den här mallen skickar en Service Bus-åtgärd det första meddelandet till ett Service Bus-ämne. Mer information finns i Hantera det första meddelandet. |
(parallell gren) | Den här parallella grenåtgärden skapar två sökvägar: - Gren nr 1: Fortsätt bearbeta meddelandet. Mer information finns i Gren nr 1: Slutför det första meddelandet i kön. - Gren nr 2: Avbryt meddelandet om något går fel och släpp för upphämtning av en annan utlösarkörning. Mer information finns i Gren nr 2: Avbryt det första meddelandet från kön. Båda sökvägarna ansluts senare i close-sessionen i en kö och lyckas , som beskrivs i nästa rad. |
Close a session in a queue and succeed |
Den här Service Bus-åtgärden ansluter till de tidigare beskrivna grenarna och stänger sessionen i kön efter att någon av följande händelser inträffar: – Arbetsflödet slutför bearbetningen av tillgängliga meddelanden i kön. Mer information finns i Stäng en session i en kö och lyckas. |
Gren nr 1: Slutför det första meddelandet i kön
Name | beskrivning |
---|---|
Complete initial message in queue |
Den här Service Bus-åtgärden markerar ett meddelande som har hämtats som slutfört och tar bort meddelandet från kön för att förhindra ombearbetning. Mer information finns i Hantera det första meddelandet. |
While there are more messages for the session in the queue |
Den här Until-loopen fortsätter att hämta meddelanden medan meddelanden finns eller tills en timme passerar. Mer information om åtgärderna i den här loopen finns i Även om det finns fler meddelanden för sessionen i kön. |
Set isDone = true |
När det inte finns fler meddelanden anges den här variabelåtgärden till true .isDone |
Renew session lock until cancelled |
Den här Until-loopen ser till att sessionslåset hålls av den här logikappen medan meddelanden finns eller tills en timme passerar. Mer information om åtgärderna i den här loopen finns i Förnya sessionslås tills det har avbrutits. |
Gren nr 2: Avbryt det första meddelandet från kön
Om åtgärden som hanterar det första meddelandet misslyckas släpper Service Bus-åtgärden, Avbryt det första meddelandet från kön, meddelandet för en annan arbetsflödesinstans som körs för att hämta och bearbeta. Mer information finns i Hantera det första meddelandet.
"Catch"-omfång
Om åtgärderna i omfånget Try
misslyckas måste logikappen fortfarande stänga sessionen. Omfångsåtgärden Catch
körs när omfångsåtgärden Try
resulterar i statusen , Failed
, Skipped
eller TimedOut
. Omfånget returnerar ett felmeddelande som innehåller sessions-ID:t där problemet inträffade och avslutar logikappen.
Här är det översta flödet i omfångsåtgärden Catch
när informationen komprimeras:
Name | beskrivning |
---|---|
Close a session in a queue and fail |
Den här Service Bus-åtgärden stänger sessionen i kön så att sessionslåset inte förblir öppet. Mer information finns i Stäng en session i en kö och misslyckas. |
Find failure msg from 'Try' block |
Den här åtgärden filtermatris skapar en matris från indata och utdata från alla åtgärder i omfånget Try baserat på de angivna kriterierna. I det här fallet returnerar den här åtgärden utdata från de åtgärder som resulterade i Failed status. Mer information finns i Find failure msg from 'Try' block (Hitta fel i "Try"-blocket. |
Select error details |
Den här åtgärden Välj skapar en matris som innehåller JSON-objekt baserat på de angivna kriterierna. Dessa JSON-objekt skapas från värdena i matrisen som skapades av föregående åtgärd, Find failure msg from 'Try' block . I det här fallet returnerar den här åtgärden en matris som innehåller ett JSON-objekt som skapats från felinformationen som returnerades från föregående åtgärd. Mer information finns i Välj felinformation. |
Terminate |
Den här åtgärden Avsluta stoppar körningen för arbetsflödet, avbryter pågående åtgärder, hoppar över eventuella återstående åtgärder och returnerar den angivna statusen, sessions-ID:t och felresultatet från åtgärdenSelect error details . Mer information finns i Avsluta logikapp. |
Slutför mallen
Följ dessa steg om du vill ange värdena för utlösaren och åtgärderna i mallen Korrelerad orderleverans med service bus-sessioner . Du måste ange alla nödvändiga värden, som markeras med en asterisk (*), innan du kan spara logikappen.
Initiera sessionen
För utlösaren När ett meddelande tas emot i en kö (peek-lock) anger du den här informationen så att mallen kan initiera en session med hjälp av egenskapen Sessions-ID, till exempel:
Kommentar
Inledningsvis är avsökningsintervallet inställt på tre minuter så att logikappen inte körs oftare än förväntat och resulterar i oväntade faktureringsavgifter. Vi rekommenderar att du anger intervallet och frekvensen till 30 sekunder så att logikappen utlöses omedelbart när ett meddelande tas emot.
Property Krävs för det här scenariot Värde beskrivning Könamn Ja <queue-name> Namnet på din tidigare skapade Service Bus-kö. I det här exemplet används "Fabrikam-Service-Bus-Queue". Kötyp Ja Huvud Din primära Service Bus-kö Sessions-ID Ja Nästa tillgängliga Det här alternativet hämtar en session för varje utlösarkörning baserat på sessions-ID:t från meddelandet i Service Bus-kön. Sessionen är också låst så att ingen annan logikapp eller annan klient kan bearbeta meddelanden som är relaterade till den här sessionen. Arbetsflödets efterföljande åtgärder bearbetar alla meddelanden som är associerade med sessionen, enligt beskrivningen senare i den här artikeln. Här är mer information om de andra alternativen för sessions-ID :
- Ingen: Standardalternativet, som resulterar i inga sessioner och inte kan användas för att implementera det sekventiella konvojmönstret.
- Ange anpassat värde: Använd det här alternativet när du känner till det sessions-ID som du vill använda och du alltid vill köra utlösaren för sessions-ID:t.
Obs! Service Bus-anslutningsappen kan spara ett begränsat antal unika sessioner åt gången från Azure Service Bus till anslutningscachen. Om antalet sessioner överskrider den här gränsen tas gamla sessioner bort från cacheminnet. Mer information finns i Exchange-meddelanden i molnet med Azure Logic Apps och Azure Service Bus.
Intervall Ja <antal intervall> Antalet tidsenheter mellan upprepningar innan du söker efter ett meddelande. Frekvens Ja Second, Minute, Hour, Day, Week eller Month Tidsenheten för upprepningen som ska användas vid kontroll av ett meddelande. Tips: Om du vill lägga till en tidszon eller Starttid väljer du dessa egenskaper i listan Lägg till ny parameter .
Mer utlösarinformation finns i Service Bus – När ett meddelande tas emot i en kö (peek-lock). Utlösaren matar ut en ServiceBusMessage.
När sessionen har initierats använder arbetsflödet åtgärden Initiera variabel för att skapa en boolesk variabel som ursprungligen angavs till false
och anger när följande villkor är uppfyllda:
Inga fler meddelanden i sessionen är tillgängliga för läsning.
Sessionslåset behöver inte längre förnyas så att den aktuella arbetsflödesinstansen kan slutföras.
I try-blocket utför arbetsflödet sedan åtgärder för det första meddelandet som läse.
Hantera det första meddelandet
Den första åtgärden är en platshållaråtgärd för Service Bus, Skicka det första meddelandet till ämnet, som du kan ersätta med andra åtgärder som du vill hantera det första meddelandet från sessionen i kön. Sessions-ID anger den session från vilken meddelandet kommer.
Platshållaråtgärden Service Bus skickar det första meddelandet till ett Service Bus-ämne som anges av egenskapen Sessions-ID . På så sätt går alla meddelanden som är associerade med en specifik session till samma ämne. Alla sessions-ID-egenskaper för efterföljande åtgärder i den här mallen använder samma sessions-ID-värde.
I Service Bus-åtgärden slutför du det första meddelandet i kön, anger namnet på Service Bus-kön och behåller alla andra standardegenskapsvärden i åtgärden.
I Service Bus-åtgärden avger du det första meddelandet från kön, anger namnet på Service Bus-kön och behåller alla andra standardegenskapsvärden i åtgärden.
Därefter anger du nödvändig information för de åtgärder som följer på åtgärden Slutför det första meddelandet i kön . Du börjar med åtgärderna i Medan det finns fler meddelanden för sessionen i köloopen .
Det finns fler meddelanden för sessionen i kön
Den här Until-loopen kör dessa åtgärder medan meddelanden finns i kön eller tills en timme passerar. Om du vill ändra loopens tidsgräns redigerar du loopens timeout-egenskapsvärde.
Hämta ytterligare meddelanden från kön medan meddelanden finns.
Kontrollera antalet återstående meddelanden. Om det fortfarande finns meddelanden fortsätter du att bearbeta meddelanden. Om det inte finns fler meddelanden anger arbetsflödet variabeln
isDone
tilltrue
och avslutar loopen.
I Service Bus-åtgärden hämtar du ytterligare meddelanden från sessionen och anger namnet på Service Bus-kön. Annars behåller du alla andra standardegenskapsvärden i åtgärden.
Kommentar
Som standard är det maximala antalet meddelanden inställt på
175
, men den här gränsen påverkas av egenskapen meddelandestorlek och maximal meddelandestorlek i Service Bus. Mer information finns i Meddelandestorlek för en kö.Därefter delas arbetsflödet upp i dessa parallella grenar:
Om ett fel inträffar när du söker efter ytterligare meddelanden anger du variabeln
isDone
tilltrue
.Processmeddelandena om vi får något villkor kontrollerar om antalet återstående meddelanden är noll. Om det finns falska och fler meddelanden fortsätter du bearbetningen. Om sant och inga fler meddelanden finns anger arbetsflödet variabeln
isDone
tilltrue
.
I avsnittet If false (Om falskt) bearbetar en For each-loop varje meddelande i först-i-först-ut-ordning (FIFO). I loopens Inställningar är inställningen Samtidighetskontroll inställd på
1
, så endast ett enda meddelande bearbetas i taget.För Service Bus-åtgärderna slutför du meddelandet i en kö och avger meddelandet i en kö och anger namnet på Service Bus-kön.
När det finns fler meddelanden för sessionen i kön , anger arbetsflödet variabeln
isDone
tilltrue
.
Därefter anger du nödvändig information för åtgärderna i förnyelsesessionslåset tills den avbryts .
Förnya sessionslåset tills det har avbrutits
Den här Until-loopen ser till att sessionslåset hålls av den här logikappen medan meddelanden finns i kön eller tills en timme passerar genom att köra dessa åtgärder. Om du vill ändra loopens tidsgräns redigerar du loopens timeout-egenskapsvärde.
Fördröjning i 25 sekunder eller en tid som är mindre än tidsgränsen för låsning för kön som bearbetas. Den minsta låsvaraktigheten är 30 sekunder, så standardvärdet räcker. Du kan dock optimera antalet gånger som loopen körs genom att justera på rätt sätt.
Kontrollera om variabeln
isDone
är inställd påtrue
.Om
isDone
är inställttrue
på bearbetar arbetsflödet fortfarande meddelanden, så arbetsflödet förnyar låset på sessionen i kön och kontrollerar loopvillkoret igen.Du måste ange namnet på Service Bus-kön i Service Bus-åtgärden Förnya lås på sessionen i en kö.
Om
isDone
är inställttrue
på förnyar arbetsflödet inte låset på sessionen i kön och avslutar loopen.
Förnya låset för sessionen i en kö
Den här Service Bus-åtgärden förnyar låset på sessionen i kön medan arbetsflödet fortfarande bearbetar meddelanden.
I Service Bus-åtgärden förnyar du låset på sessionen i en kö och anger namnet på Service Bus-kön.
Därefter ska du ange nödvändig information för Service Bus-åtgärden Stäng en session i en kö och lyckas.
Stäng en session i en kö och lyckas
Den här Service Bus-åtgärden stänger sessionen i kön efter att arbetsflödet har slutfört bearbetningen av alla tillgängliga meddelanden i kön eller arbetsflödet överger det första meddelandet.
I Service Bus-åtgärden stänger du en session i en kö och lyckas, anger namnet på servicebusskön.
I följande avsnitt beskrivs åtgärderna i Catch
avsnittet som hanterar fel och undantag som inträffar i arbetsflödet.
Stäng en session i en kö och misslyckas
Den här Service Bus-åtgärden körs alltid som den första åtgärden i omfånget Catch
och stänger sessionen i kön.
I Service Bus-åtgärden stänger du en session i en kö och misslyckas. Ange namnet på Service Bus-kön.
Därefter skapar arbetsflödet en matris som har indata och utdata från alla åtgärder i omfånget Try
så att logikappen kan komma åt information om felet eller felet som inträffade.
Hitta msg-fel från try-blocket
Den här åtgärden filtermatris skapar en matris som har indata och utdata från alla åtgärder i omfånget Try
baserat på de angivna kriterierna med hjälp result()
av funktionen. I det här fallet returnerar den här åtgärden utdata från de åtgärder som har Failed
status med hjälp equals()
av funktionen och item()
funktionen.
Här är JSON-definitionen för den här åtgärden:
"Find_failure_msg_from_'Try'_block": {
"inputs": {
"from": "@Result('Try')",
"where": "@equals(item()['status'], 'Failed')"
},
"runAfter": {
"Close_the_session_in_the_queue_and_fail": [
"Succeeded"
]
},
"type": "Query"
},
Därefter skapar arbetsflödet en matris med ett JSON-objekt som innehåller felinformationen i matrisen som returneras från åtgärden Find failure msg from 'Try' block
.
Välj felinformation
Den här åtgärden Välj skapar en matris som innehåller JSON-objekt baserat på den indatamatris som utdata från föregående åtgärd, Find failure msg from 'Try' block
. Mer specifikt returnerar den här åtgärden en matris som bara har de angivna egenskaperna för varje objekt i matrisen. I det här fallet innehåller matrisen egenskaperna för åtgärdsnamn och felresultat.
Här är JSON-definitionen för den här åtgärden:
"Select_error_details": {
"inputs": {
"from": "@body('Find_failure_msg_from_''Try''_block')[0]['outputs']",
"select": {
"action": "@item()['name']",
"errorResult": "@item()"
}
},
"runAfter": {
"Find_failure_msg_from_'Try'_block": [
"Succeeded"
]
},
"type": "Select"
},
Därefter stoppar arbetsflödet körningen av logikappen och returnerar körningsstatusen tillsammans med mer information om felet eller felet som inträffade.
Avsluta logikappkörning
Den här åtgärden Avsluta stoppar körningen av logikappen och returnerar Failed
som status för logikappens körning tillsammans med sessions-ID:t och felresultatet från åtgärdenSelect error details
.
Här är JSON-definitionen för den här åtgärden:
"Terminate": {
"description": "This Failure Termination only runs if the Close Session upon Failure action runs - otherwise the LA will be terminated as Success",
"inputs": {
"runError": {
"code": "",
"message": "There was an error processing messages for Session ID @{triggerBody()?['SessionId']}. The following error(s) occurred: @{body('Select_error_details')['errorResult']}"
},
"runStatus": "Failed"
},
"runAfter": {
"Select_error_details": [
"Succeeded"
]
},
"type": "Terminate"
}
},
Spara och kör logikappen
När du har slutfört mallen kan du nu spara logikappen. I verktygsfältet för designern väljer du Spara.
Om du vill testa logikappen skickar du meddelanden till Service Bus-kön.