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.
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ů v části Sdílené modul runtime> Poznámka: Triggery spravovaného konektoru služby Service Bus se řídí dlouhým vzorem triggeru dotazování, což znamená, že trigger pravidelně 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 - 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), který se zobrazí v galerii konektorů v části Sdílené moduly runtime>a integrovaný konektor, který se zobrazí v galerii konektorů v části Modul runtime>v aplikaci a je založený na poskytovateli služeb. Triggery spravovaného konektoru služby Service Bus se řídí dlouhým vzorem triggeru dotazování, což znamená, že trigger pravidelně kontroluje zprávy ve frontě nebo odběru tématu. Předdefinované aktivační události konektoru služby Service Bus, které nejsou relacemi, se řídí vzorem triggeru průběžného dotazování, který je plně spravovaný konektorem. Tento vzor má trigger neustále kontrolovat zprávy ve frontě nebo odběru tématu. Triggery relací se řídí vzorcem triggeru dlouhodobého dotazování, ale jeho konfigurace se řídí nastavením Azure Functions s názvem clientRetryOptions:tryTimeout. Integrovaná verze obvykle poskytuje lepší výkon, možnosti, ceny atd. |
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 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 triggeru, aby se změnila souběžnost.
Aktivační události integrovaného konektoru služby Service Bus
U integrovaného konektoru služby Service Bus se triggery mimo relaci řídí vzorem triggeru průběžného dotazování, který je plně spravovaný konektorem. Tento vzor má trigger neustále kontrolovat zprávy ve frontě nebo odběru tématu. Triggery relací se řídí vzorcem triggeru dlouhodobého dotazování a jeho konfigurace se řídí nastavením Azure Functions s názvem clientRetryOptions:tryTimeout. 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. Další hodnoty vlastností najdete v tématu 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 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 consumption: Visual Studio Code
- Standardní pracovní postupy: 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 vytváření pracovních postupů aplikace logiky použít také následující nástroje:
- Pracovní postupy consumption: Visual Studio Code
- Standardní pracovní postupy: 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.
Není k dispozici žádná relace nebo ji může uzamknout jiný příjemce.
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,
"error": {
"message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
}
}
Trigger založený na relaci může občas selhat s následující chybou:
{
"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."
}
}
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.
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.