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 přistupovat k prostředkům služby Service Bus ve službě Azure Service Bus z pracovních postupů automatizace a integrace v Azure Logic Apps pomocí konektoru Service Bus. Události služby Service Bus můžou aktivovat váš pracovní postup nebo spustit akce, které komunikují s položkami 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í, opuštění, přesměrování a označení jako mrtvé.
  • Obnovte zámky 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 a akce, které z Azure Service Bus získávají odpovědi, a pak zpřístupnit výstup jiným akcím ve vašich pracovních postupech.

Technické reference ke konektoru

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 konektoru
Využití Azure Logic Apps s více tenanty Spravovaný konektor, který se zobrazí v galerii konektorů pod modul runtime>Sdílené.

Poznámka: Triggery spravovaného konektoru služby Service Bus se řídí vzorcem triggeru dlouhodobého dotazování, což znamená, že trigger pravidelně kontroluje zprávy ve frontě nebo odběru tématu. Další informace najdete tady:
- Referenční informace ke spravovanému konektoru služby Service Bus
- Spravované konektory v Azure Logic Apps
Standard Azure Logic Apps s jedním tenantem, App Service Environment v3 (jenom plány Windows) a hybridní nasazení Spravovaný konektor, který se zobrazí v galerii konektorů v části moduly runtime>Sdílené, a integrovaný konektor, který se zobrazí v galerii konektorů v části moduly runtime>Integrované a je založený na poskytovateli služeb.

Poznámka: Triggery spravovaného konektoru služby Service Bus se řídí vzorcem triggeru dlouhodobého dotazování, což znamená, že trigger pravidelně kontroluje zprávy ve frontě nebo odběru tématu.

Triggery mimo relaci integrovaného konektoru služby Service Bus se řídí vzorem triggeru průběžného dotazování , který konektor plně spravuje. V tomto vzoru trigger neustále kontroluje zprávy ve frontě nebo odběru tématu. Triggery relací se řídí vzorcem triggeru s dlouhým dotazováním, ale nastavení Azure Functions s názvem clientRetryOptions:tryTimeout řídí jejich konfiguraci. Integrovaný konektor obecně poskytuje lepší výkon, možnosti, ceny atd.

Další informace najdete tady:

- Referenční informace ke spravovanému konektoru služby Service Bus
- Integrované operace konektoru pro Service Bus
- Integrované konektory v Azure Logic Apps

Požadavky

  • Účet a předplatné Azure. Získejte bezplatný účet Azure.

  • Obor názvů služby Service Bus a entita zasílání zpráv, například fronta.

    Další informace najdete tady:

  • Prostředek a pracovní postup aplikace logiky, kde chcete získat přístup k oboru názvů služby Service Bus a entitě zasílání zpráv.

    • Pokud chcete spustit pracovní postup pomocí triggeru služby Service Bus, vytvořte prázdný pracovní postup. Pokud chcete ve svém pracovním postupu použít akci služby Service Bus, spusťte pracovní postup libovolným triggerem, který nejlépe vyhovuje vašemu scénáři.

    • Pokud prostředek aplikace logiky používá spravovanou identitu k ověření přístupu k vašemu oboru názvů Service Bus a entitě pro zasílání zpráv, přiřaďte potřebná oprávnění role na odpovídajících úrovních. Například pro přístup k frontě vyžaduje spravovaná identita roli s potřebnými oprávněními pro danou frontu.

      • Každý prostředek aplikace logiky může 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, musí používat vlastní připojení rozhraní API služby Service Bus.

      • Každá operace služby Service Bus, která vyměňuje zprávy s různými entitami zasílání zpráv a vyžaduje různá oprávnění, musí 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é

Ujistěte se, že váš pracovní postup nevytvoří nekonečnou smyčku, když použijete spouštěč a akci se stejným typem konektoru pro práci se stejnou entitou, jako je například fronta zpráv nebo odběr tématu. Výsledkem této smyčky je pracovní postup, který se nikdy nedokončí.

Omezení uložených relací v mezipaměti konektoru

Pro každou entitu zasílání zpráv Service Bus, jako je předplatné nebo téma, může konektor Service Bus uložit až 1 500 jedinečných relací najednou v mezipaměti konektoru. Pokud počet relací překročí tento limit, mezipaměť konektoru odebere staré relace. 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í, vytvořte 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. Velké zprávy můžete například přijímat a zpracovávat 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 nastavení v následujícím příkladu kódu v rozšíření Azure Functions:

{
   "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 používají všechny triggery dlouhý vzor 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ě spouštěč pokračuje ve čtení zpráv, dokud nejsou fronta nebo odběr z 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í počet zpráv v rozmezí od jedné do počtu zpráv určeného 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ě paralelismu u spouštěče automatického dokončování, protože tato změna může vést k duplicitním zprávám, pokud se váš pracovní postup dostane do stavu s omezením. 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í spouštěče proběhne po uplynutí 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 ve škrceném stavu při dalším dotazování.

Pokud musíte změnit souběžnost u triggeru automatického dokončování služby Service Bus, neprovádějte tuto změnu před počátečním uložením pracovního postupu. Nejprve vytvořte a uložte pracovní postup před úpravou spouštěče ke změně souběžnosti.

Integrované konektory a jejich aktivace v systému Service Bus

U integrovaného konektoru Service Bus se triggery mimo relaci řídí vzorem triggeru průběžného dotazování, který konektor plně spravuje. V tomto vzoru trigger neustále kontroluje zprávy ve frontě nebo odběru tématu. Naproti tomu triggery relace se řídí vzorcem triggeru dlouhodobého dotazování . Nastavení Azure Functions, clientRetryOptions:tryTimeout, řídí jejich konfiguraci. Rozšíření hostitele Azure Functions definované v souboru host.json vaší aplikace logiky a definovaná nastavení triggeru v pracovním postupu vaší aplikace logiky, která jste nastavili prostřednictvím návrháře nebo zobrazení kódu, sdílí nastavení konfigurace vestavěného spouštěče Service Bus. Tato část popisuje obě umístění nastavení. Všimněte si následujících podrobností o triggerech služby Service Bus:

  • Některé předdefinované triggery, například Když jsou zprávy k dispozici ve frontě, můžou vrátit jednu nebo více zpráv. Když se tyto triggery aktivují, vrátí se mezi jedním a počtem zpráv.

  • Předdefinovaný spouštěč s názvem Když jsou zprávy k dispozici ve frontě (V1) nepodporuje parametr s názvem Maximální velikost dávky zpráv. Pokud použijete tento parametr, musíte místo toho použít verzi V2. Pokud chcete použít trigger, ve kterém není parametr podporovaný, můžete určit počet zpráv přijatých přidáním maxMessageBatchSize parametru do definice triggeru v souboruhost.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
   }
}

  • Souběžnost můžete povolit u triggeru služby Service Bus, a to buď prostřednictvím návrháře, nebo v kódu, například:

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

    • Pokud nastavíte souběžnost pomocí dávky, ponechte počet souběžných spuštění větší než celková velikost dávky. Tím pádem přečtené zprávy nevstoupí do stavu čekání a při čtení jsou vždy zpracovány. V některých případech může mít trigger až dvojnásobek velikosti dávky.

    • Pokud povolíte souběžnost u spouštěče s názvem Když jsou zprávy dostupné ve frontě (V1) a do fronty odešlete 100 nebo více zpráv, spouštěč směruje všechny zprávy do fronty nedoručených zpráv.

    • Pokud povolíte souběžnost, limit pro dávkování nebo Split on chování 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.

    • Pokud ve výchozím nastavení povolíte souběžnost, mezi dávkovým čtením existuje 30sekundové zpoždění. Toto zpoždění zpomalí spouštěč, aby dosáhl následujících cílů:

      • Snižte počet volání úložiště pro kontrolu počtu spuštění, na které se má použít souběžnost.

      • Napodobujte chování spouštěče spravovaného konektoru Service Bus, který má 30sekundové dlouhé dotazování, pokud nejsou nalezeny žádné zprávy.

        I když toto zpoždění můžete změnit, ujistěte se, že pečlivě otestujete všechny změny výchozí hodnoty:

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

    • Existují některé scénáře, kdy spouštěč může překročit nastavení souběžnosti. Namísto toho, aby tato spuštění selhala, Azure Logic Apps je zařadí do fronty do stavu čekání, dokud se nedají spustit. NastavenímaximumWaitingRuns ří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 procesy 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.

Krok 1: Kontrola přístupu k názvovému prostoru služby Service Bus

Pokud chcete ověřit, že váš prostředek aplikace logiky má oprávnění pro přístup k oboru názvů Service Bus, postupujte následovně:

  1. Na webu Azure Portal otevřete obor názvů služby Service Bus.

  2. Na bočním panelu oboru názvů v části Nastavení vyberte Zásady sdíleného přístupu. V části Příspěvky zkontrolujte, jestli máte oprávnění Spravovat pro tento jmenný prostor.

    Snímek obrazovky, který ukazuje portál Azure, obor názvů Service Bus, otevřenou stránku zásad sdíleného přístupu a zvýrazněné nastavení Spravovat.

Krok 2: Získání požadavků na ověření připojení

Když 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í potřebujete položky popsané v následujících částech.

Ověřování spravovaných konektorů (pracovní postupy Consumption a Standard)

Typ autentizace Požadované informace
Přístupový klíč Připojovací řetězec pro váš Service Bus obor názvů. Další informace naleznete v tématu Získání připojovacího řetězce pro obor názvů služby Service Bus.
Integrovaná aplikace Microsoft Entra URL koncového bodu pro vaši oborovou oblast služby Service Bus. Další informace najdete v tématu Získání 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í URL koncového bodu v oboru názvů služby Service Bus.

Integrované ověřování konektoru (pouze standardní pracovní postupy)

Typ autentizace Požadované informace
Připojovací řetězec Připojovací řetězec pro váš obor názvů služby Service Bus. Další informace naleznete v článku Získání připojovacího řetězce 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 naleznete v tématu Získání plně kvalifikovaného názvu pro obor názvů služby Service Bus. K dalším hodnotám vlastností se podívejte na OAuth s ID Microsoft Entra.
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 naleznete v tématu Získání plně kvalifikovaného názvu pro obor názvů služby Service Bus.

Získání připojovacího řetězce 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, potřebujete připojovací řetězec pro obor názvů služby Service Bus. Připojovací řetězec začíná předponou sb://.

  1. Na webu Azure Portal otevřete obor názvů služby Service Bus.

  2. Na bočním panelu oboru názvů v části Nastavení vyberte Zásady sdíleného přístupu.

  3. V podokně Zásady sdíleného přístupu vyberte RootManageSharedAccessKey.

  4. Vedle primárního nebo sekundárního připojovacího řetězce vyberte tlačítko kopírovat.

    Snímek obrazovky znázorňující obor názvů služby Service Bus, otevřenou stránku zásad sdíleného přístupu, vybranou zásadu RootManageSharedAccessKey a otevřené podokno zásady SAS, a je vybráno tlačítko pro kopírování primárního připojovacího řetězce.

    Poznámka:

    Pokud chcete ověřit, že je řetězec pro obor názvů, a ne pro konkrétní entitu zasílání zpráv, vyhledejte v připojovacím řetězci parametr EntityPath. Pokud tento parametr najdete, připojovací řetězec je určený pro konkrétní entitu a není tím správným řetězcem pro použití s vaším pracovním postupem.

  5. Uložte připojovací řetězec pro pozdější použití.

Získání koncové URL adresy pro obor názvů Service Bus

Pokud používáte spravovaný konektor služby Service Bus, potřebujete tuto adresu URL koncového bodu, pokud vyberete některý z typů ověřování pro Microsoft Entra integrated nebo Logic Apps Managed Identity. Adresa URL koncového bodu začíná předponou sb:// .

  1. Na webu Azure Portal otevřete obor názvů služby Service Bus.

  2. Na bočním panelu oboru názvů rozbalte Nastavení a pak vyberte Vlastnosti.

  3. V části Essentials vedle ID zkopírujte a uložte adresu URL koncového bodu pro pozdější použití.

Získání plně kvalifikovaného názvu pro obor názvů služby Service Bus

  1. Na webu Azure Portal otevřete obor názvů služby Service Bus.

  2. Na bočním panelu oboru názvů vyberte Přehled.

  3. Na stránce Přehled rozbalte položku Základy a vyhledejte vlastnost Název hostitele .

  4. Zkopírujte a uložte plně kvalifikovaný název, který vypadá jako <váš-Service-Bus-namespace.servicebus.windows.net> pro pozdější použití.

Krok 3: Možnost 1 – Přidání triggeru služby Service Bus

Následující kroky používají Azure Portal, ale pomocí odpovídajícího rozšíření Azure Logic Apps můžete pomocí editoru Visual Studio Code vytvářet pracovní postupy aplikací logiky:

  1. Na Azure Portal otevřete prostředek Consumption Logic App. Otevřete prázdný pracovní postup v návrháři.

  2. V návrháři postupujte podle obecných kroků a přidejte trigger služby Azure Service Bus, který chcete pro svůj scénář použít.

    Tento příklad používá trigger s názvem Při přijetí zprávy ve frontě (automatické dokončování).

  3. Zadejte následující informace o připojení:

    Parameter 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, který jste zkopírovali a uložili dříve.

    Například následující připojení používá pro ověřování přístupový klíč a poskytuje připojovací řetězec pro obor názvů služby Service Bus:

    Snímek obrazovky znázorňující podokno Vytvořit připojení pro nový trigger služby Service Bus, který používá ověřování pomocí přístupového klíče v pracovním postupu Consumption

  4. Až skončíte, vyberte Vytvořit nový.

  5. V podokně informací o triggeru zadejte potřebné informace, například:

    Parameter Požadováno Popis
    Název fronty Ano Zvolená fronta pro přístup
    Typ fronty Ne Typ vybrané fronty
    Jak často chcete zkontrolovat položky? Ano Interval a frekvence dotazování pro kontrolu položek ve frontě

    Snímek obrazovky znázorňující nový spravovaný trigger služby Service Bus s ukázkovými informacemi v pracovním postupu Consumption

  6. 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 frontu a najde novou zprávu, spustí váš pracovní postup vybrané akce pro novou zprávu.

  7. 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 pomocí příslušného rozšíření Azure Logic Apps můžete pomocí editoru Visual Studio Code vytvářet pracovní postupy aplikací logiky:

  1. Na Azure Portal otevřete prostředek Consumption Logic App. Otevřete pracovní postup v návrháři.

  2. V návrháři postupujte podle obecných kroků a přidejte požadovanou akci služby Azure Service Bus pro váš scénář.

    V tomto příkladu se používá akce s názvem Odeslat zprávu.

  3. V podokně informací o připojení zadejte následující informace:

    Parameter 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, který 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:

    Snímek obrazovky znázorňující podokno Vytvořit připojení pro novou akci služby Service Bus, která používá ověřování pomocí přístupového klíče v pracovním postupu Consumption

  4. Až skončíte, vyberte Vytvořit nový.

  5. V podokně informací o akci zadejte potřebné informace, například:

    Parameter 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 Ne ID relace, pokud zprávu odesíláte do fronty nebo tématu s vědomím relací.
    Systémové vlastnosti Ne - Nic
    - Podrobnosti spuštění: Přidejte informace o vlastnostech metadat spuštění jako vlastní informace do zprávy.

    Snímek obrazovky znázorňující akci Odeslat zprávu Service Bus s ukázkovými informacemi v pracovním postupu Consumption

  6. Pokud chcete do akce přidat další dostupné vlastnosti, otevřete seznam rozšířených parametrů a vyberte požadované vlastnosti.

  7. Přidejte všechny další akce, které váš pracovní postup potřebuje.

    Můžete například přidat akci, která odešle e-mail a potvrdit, že zpráva byla odeslána.

  8. Po dokončení uložte pracovní postup. Na panelu nástrojů návrháře vyberte Uložit.

Nastavení aplikace integrovaného konektoru služby Service Bus

V standardním prostředku logické aplikace obsahuje vestavěný konektor Service Bus nastavení aplikace, která řídí různé prahové hodnoty. Tato nastavení například řídí časové limity 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 tématu Referenční informace o 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 přečí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ů:

  1. V závislosti na vašem scénáři v prázdném pracovním postupu přidejte spouštěč integrovaného konektoru služby Service Bus s názvem Když jsou zprávy k dispozici ve frontě nebo Když je zpráva k dispozici v odběru tématu, (peek-lock).

  2. 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 ve frontě, spusťte: Nastavte parametr název fronty na queuename/$deadletterqueue.

    • Když je ve schránce tématu k dispozici zpráva (peek-lock) spouštěč: Nastavte parametr Název tématu na .

    Další informace najdete v přehledu front nedoručených zpráv služby Service Bus.

Řešení problémů

Zpoždění při zavedení aktualizací pracovního postupu

Pokud je interval dotazování triggeru služby Service Bus krátký, například 10 sekund, nemusí se aktualizace vašeho pracovního postupu projevit do 10 minut. Chcete-li tento problém vyřešit, zakažte prostředek aplikace logiky, proveďte změny a pak znovu povolte prostředek aplikace logiky.

Není k dispozici žádná relace nebo ji zamkl jiný přijímač.

V některých případech operace, jako je dokončení zprávy nebo obnovení relace, generují ve spravovaném konektoru následující chybu:

{
  "status": 400,
  "error": {
    "message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
  }
}

V některých případech může trigger založený na relaci selhat s následující chybou ve spravovaném konektoru:

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

Někdy operace, jako je dokončení zprávy nebo obnovení relace, generují v integrovaném konektoru následující chybu:

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

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.

Vzhledem k důvodům, jako je aktualizace infrastruktury, nasazení konektoru atd., existuje možnost, že požadavky nebudou směrovány do stejné instance role. Pokud k této události dojde, požadavky selžou z jednoho z následujících důvodů:

  • Příjemce, který provádí operace v relaci, není v instanci role, která žádost obsluhuje, k dispozici.

  • Nová instance role se pokusí získat relaci, která vypršela v původní instanci role nebo nebyla uzavřena.

K tomuto chování může dojít jak ve spravovaném konektoru, tak v integrovaném konektoru. 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. Pokud k této chybě dochází jen občas, očekává se chyba.

Související obsah

  • Last updated on