Připojení ke službě Azure Service Bus z pracovních postupů v Azure Logic Apps
Platí pro: Azure Logic Apps (Consumption + Standard)
Tento průvodce ukazuje, jak získat přístup ke službě Azure Service Bus z pracovního postupu v Azure Logic Apps pomocí konektoru Service Bus. Pak můžete vytvořit automatizované pracovní postupy, které se spouštějí při aktivaci událostmi ve službě Service Bus nebo spouštět akce pro správu položek služby Service Bus, například:
- Monitorujte, kdy zprávy přicházejí (automatické dokončování) nebo se přijímají (náhled uzamčení) ve frontách, tématech a odběrech témat.
- Odesílání zpráv.
- Vytváření a odstraňování odběrů témat
- Spravujte zprávy ve frontách a odběrech témat, například získání, odložení, dokončení, odložení, opuštění a nedoručených zpráv.
- Obnovte zámky u zpráv a relací ve frontách a odběrech témat.
- Ukončete relace ve frontách a tématech.
Můžete použít triggery, které z Azure Service Bus získávají odpovědi a zpřístupní výstup jiným akcím ve vašich pracovních postupech. Můžete také mít další akce, které používají výstup z akcí služby Service Bus.
Připojení otechnické referenční informace
Konektor Service Bus má různé verze založené na typu pracovního postupu aplikace logiky a hostitelském prostředí.
| Aplikace logiky | Prostředí | verze Připojení oru |
|---|---|---|
| Využití | Azure Logic Apps s více tenanty | Spravovaný konektor (třída Standard) Další informace najdete v následující dokumentaci: - Referenční informace ke spravovanému konektoru služby Service Bus - Spravované konektory v Azure Logic Apps |
| Využití | Prostředí integrační služby (ISE) | Spravovaný konektor (třída Standard) a verze ISE, která má různá omezení zpráv než standardní třída. Další informace najdete v následující dokumentaci: - Referenční informace ke spravovanému konektoru služby Service Bus - Omezení zpráv ISE - Spravované konektory v Azure Logic Apps |
| Standard | Azure Logic Apps a App Service Environment v3 s jedním tenantem (pouze plány Windows) | Spravovaný konektor (hostovaný v Azure) a integrovaný konektor, což je poskytovatel služeb. Integrovaná verze obvykle poskytuje lepší výkon, možnosti, ceny atd. Poznámka: Integrované triggery konektoru služby Service Bus se řídí vzorem triggeru dotazování, což znamená, že trigger průběžně kontroluje zprávy ve frontě nebo odběru tématu. Další informace najdete v následující dokumentaci: - Referenční informace ke spravovanému konektoru služby Service Bus - Integrované operace konektoru služby Service Bus - Integrované konektory v Azure Logic Apps |
Požadavky
Účet a předplatné Azure. Pokud nemáte předplatné Azure, zaregistrujte si bezplatný účet Azure.
Obor názvů služby Service Bus a entita zasílání zpráv, například fronta. Další informace najdete v následující dokumentaci:
Pracovní postup aplikace logiky, ve kterém se připojujete k oboru názvů služby Service Bus a entitě zasílání zpráv. Pokud chcete spustit pracovní postup triggerem služby Service Bus, musíte začít s prázdným pracovním postupem. Pokud chcete ve svém pracovním postupu použít akci služby Service Bus, spusťte pracovní postup libovolným triggerem.
Pokud prostředek aplikace logiky používá spravovanou identitu pro ověřování přístupu k entitě oboru názvů služby Service Bus a zasílání zpráv, ujistěte se, že jste přiřadili oprávnění role na odpovídajících úrovních. Například pro přístup k frontě vyžaduje spravovaná identita roli, která má potřebná oprávnění pro danou frontu.
Každý prostředek aplikace logiky by měl používat jenom jednu spravovanou identitu, i když pracovní postup aplikace logiky přistupuje k různým entitám zasílání zpráv.
Každá spravovaná identita, která přistupuje k odběru fronty nebo tématu, by měla používat vlastní připojení rozhraní API služby Service Bus.
Operace služby Service Bus, které vyměňují zprávy s různými entitami zasílání zpráv a vyžadují různá oprávnění, by měly používat vlastní připojení rozhraní API služby Service Bus.
Další informace o spravovaných identitách najdete v tématu Ověřování přístupu k prostředkům Azure pomocí spravovaných identit v Azure Logic Apps.
Ve výchozím nastavení jsou integrované operace konektoru služby Service Bus bezstavové. Pokud chcete tyto operace spustit v stavovém režimu, přečtěte si téma Povolení stavového režimu pro bezstavové integrované konektory.
Důležité informace o operacích služby Azure Service Bus
Nekonečné smyčky
Důležité
Při výběru triggeru i akce se stejným typem konektoru používejte upozornění a používejte je k práci se stejnou entitou, jako je například fronta zasílání zpráv nebo odběr tématu. Tato kombinace může vytvořit nekonečnou smyčku, což vede k tomu, že aplikace logiky, která nikdy nekončí.
Omezení uložených relací v mezipaměti konektoru
Na entitu zasílání zpráv service Bus, jako je předplatné nebo téma, může konektor Service Bus ušetřit až 1 500 jedinečných relací najednou do mezipaměti konektoru. Pokud počet relací překročí tento limit, staré relace se z mezipaměti odeberou. Další informace naleznete v tématu Relace zpráv.
Odesílání korelovaných zpráv v pořadí
Pokud potřebujete odesílat související zprávy v určitém pořadí, můžete vytvořit pracovní postup pomocí konektoru Service Bus a sekvenčního vzoru konvoje. Korelované zprávy mají vlastnost, která definuje vztah mezi těmito zprávami, například ID relace ve službě Azure Service Bus.
Při vytváření pracovního postupu aplikace logiky Consumption můžete vybrat korelované doručování v pořadí pomocí šablony relací služby Service Bus, která implementuje sekvenční vzor konvoje. Další informace naleznete v tématu Odesílání souvisejících zpráv v pořadí.
Podpora velkých zpráv
Podpora velkých zpráv je k dispozici pouze pro standardní pracovní postupy při použití integrovaných operací konektoru služby Service Bus. Můžete například přijímat a velké zprávy pomocí předdefinovaných triggerů a akcí.
Pro spravovaný konektor Service Bus je maximální velikost zprávy omezena na 1 MB, i když používáte obor názvů služby Service Bus úrovně Premium.
Zvýšení časového limitu pro příjem a odesílání zpráv
Ve standardních pracovních postupech, které používají integrované operace služby Service Bus, můžete zvýšit časový limit pro příjem a odesílání zpráv. Pokud například chcete zvýšit časový limit pro příjem zprávy, změňte v rozšíření Azure Functions následující nastavení:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
"version": "[1.*, 2.0.0)"
},
"extensions": {
"serviceBus": {
"batchOptions": {
"operationTimeout": "00:15:00"
}
}
}
}
Pokud chcete zvýšit časový limit pro odeslání zprávy, přidejte nastavení aplikace ServiceProviders.ServiceBus.MessageSenderOperationTimeout.
Triggery spravovaného konektoru služby Service Bus
U spravovaného konektoru Service Bus jsou všechny triggery dlouhé dotazování. Tento typ triggeru zpracuje všechny zprávy a potom počká 30 sekund, než se další zprávy zobrazí ve frontě nebo odběru tématu. Pokud se během 30 sekund nezobrazí žádné zprávy, spuštění triggeru se přeskočí. V opačném případě trigger pokračuje ve čtení zpráv, dokud nejsou fronta nebo odběr tématu prázdné. Další dotaz aktivační události vychází z intervalu opakování zadaného ve vlastnostech triggeru.
Některé triggery, například když jedna nebo více zpráv dorazí do fronty (automatické dokončování), můžou vrátit jednu nebo více zpráv. Když se tyto triggery aktivují, vrátí se mezi jednou a počtem zpráv určených vlastností maximálního počtu zpráv triggeru.
Poznámka:
Trigger automatického dokončování automaticky dokončí zprávu, ale dokončení proběhne pouze při příštím volání služby Service Bus. Toto chování může ovlivnit návrh pracovního postupu. Vyhněte se například změně souběžnosti u triggeru automatického dokončování, protože tato změna může vést k duplicitním zprávám, pokud váš pracovní postup zadá omezený stav. Změna ovládacího prvku souběžnosti vytvoří následující podmínky:
Omezené triggery se přeskočí kódem
WorkflowRunInProgress.Operace dokončení se nespustí.
Další spuštění triggeru proběhne po intervalu dotazování.
Dobu trvání uzamčení služby Service Bus musíte nastavit na hodnotu, která je delší než interval dotazování. I přes toto nastavení se ale zpráva nemusí dokončit, pokud váš pracovní postup zůstane v omezeném stavu v dalším intervalu dotazování.
Pokud ale zapnete nastavení souběžnosti triggeru služby Service Bus, bude výchozí hodnota vlastnosti
maximumWaitingRuns10. Na základě nastavení doby trvání uzamčení entity Service Bus a doby trvání spuštění pracovního postupu může být tato výchozí hodnota příliš velká a může způsobit výjimku "Zámek ztracený". Pokud chcete najít optimální hodnotu pro váš scénář, začněte testovat s hodnotou 1 nebo 2 promaximumWaitingRunsvlastnost. Pokud chcete změnit hodnotu maximálního počtu čekajících spuštění, zkontrolujte limit čekání na změnu.
Aktivační události integrovaného konektoru služby Service Bus
V současné době se nastavení konfigurace integrované aktivační události služby Service Bus sdílí mezi rozšířením hostitele Azure Functions, které je definované v souboru host.json vaší aplikace logiky, a nastavením triggeru definovaným v pracovním postupu vaší aplikace logiky, které můžete nastavit prostřednictvím návrháře nebo zobrazení kódu. Tato část popisuje obě umístění nastavení.
Ve standardních pracovních postupech můžou některé triggery, například Když jsou zprávy k dispozici v triggeru fronty , vrátit jednu nebo více zpráv. Když se tyto triggery aktivují, vrátí se mezi jedním a počtem zpráv. Pro tento typ triggeru a kde parametr Maximální počet zpráv není podporován, můžete stále řídit počet zpráv přijatých pomocí maxMessageBatchSize vlastnost v souboru host.json . Pokud chcete tento soubor najít, přečtěte si téma Úprava nastavení hostitele a aplikace pro standardní aplikace logiky.
"extensions": { "serviceBus": { "maxMessageBatchSize": 25 } }V triggeru služby Service Bus můžete také povolit souběžnost, a to buď prostřednictvím návrháře, nebo v kódu:
"runtimeConfiguration": { "concurrency": { "runs": 100 } }Když nastavíte souběžnost pomocí dávky, ponechte počet souběžných spuštění větší než celková velikost dávky. Čtení zpráv tak nepřejde do stavu čekání a při čtení se vždy vyzvedne. V některých případech může mít aktivační událost až dvojnásobek velikosti dávky.
Pokud povolíte souběžnost, limit SplitOn se sníží na 100 položek. Toto chování platí pro všechny triggery, nejen pro trigger služby Service Bus. Ujistěte se, že je zadaná velikost dávky menší než tento limit u všech triggerů, u kterých povolíte souběžnost.
Existují některé scénáře, kdy trigger může překročit nastavení souběžnosti. Místo selhání těchto spuštění je Azure Logic Apps zařadí do fronty ve stavu čekání, dokud se nedají spustit. Nastavení maximum WaitingRuns řídí počet spuštění povolených ve stavu čekání:
"runtimeConfiguration": { "concurrency": { "runs": 100, "maximumWaitingRuns": 50 } }S triggerem služby Service Bus se ujistěte, že tyto změny pečlivě otestujete, aby spuštění nečekaly déle, než je časový limit uzamčení zprávy. Další informace o výchozích hodnotách najdete v tématu Omezení souběžnosti a de-batchingu.
Pokud povolíte souběžnost, ve výchozím nastavení mezi dávkovým čtením existuje 30sekundové zpoždění. Toto zpoždění zpomalí trigger, aby dosáhl následujících cílů:
Snižte počet odeslaných volání úložiště a zkontrolujte počet spuštění, u kterých se má použít souběžnost.
Napodobujte chování triggeru spravovaného konektoru služby Service Bus, který má 30sekundové dlouhé dotazování, když se nenašly žádné zprávy.
Toto zpoždění můžete změnit, ale ujistěte se, že pečlivě otestujete všechny změny výchozí hodnoty:
"workflow": { "settings": { "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30" } }
Krok 1: Kontrola přístupu k oboru názvů služby Service Bus
Pokud chcete ověřit, že prostředek aplikace logiky má oprávnění pro přístup k oboru názvů služby Service Bus, postupujte takto:
Na webu Azure Portal otevřete obor názvů služby Service Bus.
V nabídce oboru názvů v části Nastavení vyberte Zásady sdíleného přístupu. V části Deklarace identity zkontrolujte, jestli máte oprávnění Spravovat pro tento obor názvů.
Krok 2: Získání požadavků na ověření připojení
Když později poprvé přidáte trigger nebo akci služby Service Bus, zobrazí se výzva k zadání informací o připojení, včetně typu ověřování připojení. Na základě typu pracovního postupu aplikace logiky, verze konektoru Service Bus a vybraného typu ověřování budete potřebovat následující položky:
Ověřování spravovaných konektorů (pracovní postupy Consumption a Standard)
| Authentication type | Požadované informace |
|---|---|
| Přístupový klíč | Připojovací řetězec pro váš obor názvů služby Service Bus. Další informace najdete v tématu Získání připojovací řetězec pro obor názvů služby Service Bus. |
| Integrovaná aplikace Microsoft Entra | Adresa URL koncového bodu pro váš obor názvů služby Service Bus. Další informace najdete v tématu Získání adresy URL koncového bodu pro obor názvů služby Service Bus. |
| Spravovaná identita Logic Apps | Adresa URL koncového bodu pro váš obor názvů služby Service Bus. Další informace najdete v tématu Získání adresy URL koncového bodu pro obor názvů služby Service Bus. |
Integrované ověřování konektoru (pouze standardní pracovní postupy)
| Authentication type | Požadované informace |
|---|---|
| Připojovací řetězec | Připojovací řetězec pro váš obor názvů služby Service Bus. Další informace najdete v tématu Získání připojovací řetězec pro obor názvů služby Service Bus. |
| Active Directory OAuth | – Plně kvalifikovaný název vašeho oboru názvů služby Service Bus, <například your-Service-Bus-namespace.servicebus.windows.net>. Další informace najdete v tématu Získání plně kvalifikovaného názvu oboru názvů služby Service Bus. U ostatních hodnot vlastností zkontrolujte ověřování Microsoft Entra ID Open Authentication. |
| Spravovaná identita | Plně kvalifikovaný název vašeho oboru názvů služby Service Bus, <například your-Service-Bus-namespace.servicebus.windows.net>. Další informace najdete v tématu Získání plně kvalifikovaného názvu oboru názvů služby Service Bus. |
Získání připojovací řetězec pro obor názvů služby Service Bus
Pokud chcete vytvořit připojení při přidání triggeru nebo akce služby Service Bus, musíte mít připojovací řetězec pro váš obor názvů služby Service Bus. Připojovací řetězec začíná předponou sb://.
Na webu Azure Portal otevřete obor názvů služby Service Bus.
V nabídce oboru názvů v části Nastavení vyberte Zásady sdíleného přístupu.
V podokně Zásady sdíleného přístupu vyberte RootManageSharedAccessKey.
Vedle primárního nebo sekundárního připojovací řetězec vyberte tlačítko kopírovat.
Poznámka:
Pokud chcete zkontrolovat, jestli je řetězec pro obor názvů, ne pro konkrétní entitu zasílání zpráv, vyhledejte parametr v připojovací řetězec
EntityPath. Pokud tento parametr najdete, připojovací řetězec je určená pro konkrétní entitu a není správným řetězcem pro použití s pracovním postupem.Uložte připojovací řetězec pro pozdější použití.
Získání adresy URL koncového bodu pro obor názvů služby Service Bus
Pokud používáte spravovaný konektor služby Service Bus, potřebujete tuto adresu URL koncového bodu, pokud vyberete typ ověřování pro integrovanou microsoft Entra nebo spravovanou identitu Logic Apps. Adresa URL koncového bodu začíná předponou sb:// .
Na webu Azure Portal otevřete obor názvů služby Service Bus.
V nabídce oboru názvů v části Nastavení vyberte Vlastnosti.
V části Vlastnosti vedle koncového bodu služby Service Bus zkopírujte adresu URL koncového bodu a uložte ji pro pozdější použití, pokud potřebujete zadat adresu URL koncového bodu služby Service Bus.
Získání plně kvalifikovaného názvu pro obor názvů služby Service Bus
Na webu Azure Portal otevřete obor názvů služby Service Bus.
V nabídce oboru názvů vyberte Přehled.
V podokně Přehled vyhledejte vlastnost Název hostitele a zkopírujte plně kvalifikovaný název, který vypadá jako< váš-Service-Bus-namespace.servicebus.windows.net.>
Krok 3: Možnost 1 – Přidání triggeru služby Service Bus
Následující kroky používají Azure Portal, ale s příslušným rozšířením Azure Logic Apps můžete k vytvoření pracovních postupů aplikace logiky použít také následující nástroje:
Pracovní postupy aplikace logiky Consumption: Visual Studio nebo Visual Studio Code
Pracovní postupy standardní aplikace logiky: Visual Studio Code
Na webu Azure Portal otevřete prostředek aplikace logiky Consumption s prázdným pracovním postupem v návrháři.
V návrháři podle těchto obecných kroků přidejte požadovanou aktivační událost služby Azure Service Bus.
Tento příklad pokračuje triggerem s názvem Při přijetí zprávy ve frontě (automatické dokončování).
Pokud se zobrazí výzva, zadejte následující informace pro vaše připojení. Až budete hotovi, vyberte Vytvořit.
Vlastnost Požadováno Popis Název připojení Ano Název připojení Typ ověření Ano Typ ověřování, který se má použít pro přístup k oboru názvů služby Service Bus. Další informace najdete v tématu Ověřování spravovaného konektoru. Připojovací řetězec Ano Připojovací řetězec, kterou jste zkopírovali a uložili dříve. Toto připojení například používá ověřování pomocí přístupového klíče a poskytuje připojovací řetězec pro obor názvů služby Service Bus:
Po zobrazení informačního pole triggeru zadejte potřebné informace, například:
Vlastnost Požadováno Popis Název fronty Ano Vybraná fronta pro přístup Typ fronty No Typ vybrané fronty Jak často chcete zkontrolovat položky? Ano Interval a frekvence dotazování pro kontrolu fronty pro položky 
Pokud chcete do triggeru přidat další dostupné vlastnosti, otevřete seznam přidat nový parametr a vyberte požadované vlastnosti.
Přidejte všechny akce, které váš pracovní postup potřebuje.
Můžete například přidat akci, která odešle e-mail při přijetí nové zprávy. Když trigger zkontroluje vaši frontu a najde novou zprávu, spustí váš pracovní postup vybrané akce pro nalezenou zprávu.
Po dokončení uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.
Krok 3: Možnost 2 – Přidání akce služby Service Bus
Následující kroky používají Azure Portal, ale s příslušným rozšířením Azure Logic Apps můžete k vytvoření pracovních postupů aplikace logiky použít také následující nástroje:
Pracovní postupy aplikace logiky Consumption: Visual Studio nebo Visual Studio Code
Pracovní postupy standardní aplikace logiky: Visual Studio Code
Na webu Azure Portal otevřete aplikaci logiky Consumption a pracovní postup v návrháři.
V návrháři postupujte podle těchto obecných kroků a přidejte požadovanou akci služby Azure Service Bus.
Tento příklad pokračuje akcí Odeslat zprávu .
Pokud se zobrazí výzva, zadejte následující informace pro vaše připojení. Až budete hotovi, vyberte Vytvořit.
Vlastnost Požadováno Popis Název připojení Ano Název připojení Typ ověření Ano Typ ověřování, který se má použít pro přístup k oboru názvů služby Service Bus. Další informace najdete v tématu Ověřování spravovaného konektoru. Připojovací řetězec Ano Připojovací řetězec, kterou jste zkopírovali a uložili dříve. Toto připojení například používá ověřování pomocí přístupového klíče a poskytuje připojovací řetězec pro obor názvů služby Service Bus:
Po zobrazení pole s informacemi o akci zadejte potřebné informace, například:
Vlastnost Požadováno Popis Název fronty nebo tématu Ano Vybraná fronta nebo cíl tématu pro odeslání zprávy ID relace No ID relace při odesílání zprávy do fronty nebo tématu pracujícím s relacemi Systémové vlastnosti No - Nic
- Podrobnosti o spuštění: Přidejte do zprávy informace o vlastnosti metadat o spuštění jako vlastní vlastnosti.
Pokud chcete do akce přidat další dostupné vlastnosti, otevřete seznam přidat nový parametr a vyberte požadované vlastnosti.
Přidejte všechny další akce, které váš pracovní postup potřebuje.
Můžete například přidat akci, která odešle e-mail, abyste potvrdili, že zpráva byla odeslána.
Po dokončení uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.
Nastavení integrované aplikace konektoru služby Service Bus
V prostředku standardní aplikace logiky obsahuje integrovaný konektor Service Bus nastavení aplikace, která řídí různé prahové hodnoty, jako je vypršení časového limitu pro odesílání zpráv a počet odesílatelů zpráv na jádro procesoru ve fondu zpráv. Další informace najdete v referenčních informacích k nastavení aplikace – local.settings.json.
Čtení zpráv z front nedoručených zpráv pomocí integrovaných triggerů služby Service Bus
Pokud chcete ve standardních pracovních postupech číst zprávu z fronty nedoručených zpráv ve frontě nebo odběru tématu, postupujte podle těchto kroků pomocí zadaných triggerů:
V prázdném pracovním postupu v závislosti na vašem scénáři přidejte trigger integrovaného konektoru služby Service Bus s názvem Když jsou zprávy k dispozici ve frontě nebo Když jsou zprávy k dispozici v odběru tématu (náhled uzamčení).
V triggeru nastavte následující hodnoty parametrů, abyste zadali výchozí frontu fronty nebo odběr tématu, ke které máte přístup stejně jako k jakékoli jiné frontě:
Pokud jsou zprávy k dispozici v triggeru fronty : Nastavte parametr název fronty na název_fronty/$deadletterqueue.
Pokud je v odběru tématu k dispozici zpráva (peek-lock): Nastavte parametr názvu tématu na topicname/Subscriptions/subscriptionname/$deadletterqueue.
Další informace najdete v tématu Přehled front nedoručených zpráv služby Service Bus.
Řešení problému
Zpoždění v aktualizacích pracovního postupu se projeví
Pokud je interval dotazování triggeru služby Service Bus malý, například 10 sekund, nemusí aktualizace pracovního postupu trvat až 10 minut. Tento problém můžete obejít tak, že zakážete prostředek aplikace logiky, provedete změny a pak znovu povolíte prostředek aplikace logiky.
Žádná relace není k dispozici.
V některých případech operace, jako je například dokončení zprávy nebo prodloužení relace, způsobí následující chybu:
{
"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'."
}
}
Konektor Service Bus používá mezipaměť v paměti k podpoře všech operací přidružených k relacím. Příjemce zpráv služby Service Bus se ukládá do mezipaměti v paměti instance role (virtuálního počítače), která přijímá zprávy. Ke zpracování všech požadavků se všechna volání připojení směrují do stejné instance role. Toto chování je povinné, protože všechny operace služby Service Bus v relaci vyžadují stejného příjemce, který přijímá zprávy pro určitou relaci.
Existuje šance, že se požadavky nemusí směrovat do stejné instance role, a to z důvodů, jako je aktualizace infrastruktury, nasazení konektoru atd. Pokud k této události dojde, požadavky selžou, protože příjemce, který provádí operace v relaci, není k dispozici v instanci role, která požadavek obsluhuje.
Pokud k této chybě dochází jen občas, očekává se chyba. Když dojde k chybě, zpráva se v service busu zachová. Další trigger nebo spuštění pracovního postupu se pokusí zprávu znovu zpracovat.