Porovnání prostředí s jedním tenantem a prostředím integrační služby pro Azure Logic Apps

Azure Logic Apps je cloudová platforma pro vytváření a spouštění automatizovaných pracovních postupů aplikací logiky, které integrují vaše aplikace, data, služby a systémy. Pomocí této platformy můžete rychle vyvíjet vysoce škálovatelná řešení integrace pro scénáře B2B (enterprise and business-to-business). K vytvoření aplikace logiky použijte typ prostředku Aplikace logiky (Consumption) nebo Typ prostředku Aplikace logiky (Standard). Typ prostředku Consumption běží v prostředí s více tenanty Azure Logic Apps prostředí integrační služby, zatímco typ prostředku Standard běží v jedno tenantské Azure Logic Apps prostředí.

Před výběrem typu prostředku, který chcete použít, si přečtěte tento článek, ve kterém se dozvíte, jak se typy prostředků a prostředí služeb vzájemně porovnávají. Pak se můžete rozhodnout, který typ je nejlepší použít, na základě potřeb vašeho scénáře, požadavků na řešení a prostředí, ve kterém chcete pracovní postupy nasadit, hostovat a spouštět.

Pokud s tímto Azure Logic Apps, projděte si následující dokumentaci:

• Co je Azure Logic Apps?
• Co je pracovní postup aplikace logiky?

Typy prostředků a prostředí

Pracovní postupy aplikací logiky vytvoříte tak, že zvolíte typ prostředku Aplikace logiky na základě vašeho scénáře, požadavků na řešení, možností, které chcete, a prostředí, ve kterém chcete pracovní postupy spouštět.

Následující tabulka stručně shrnuje rozdíly mezi typem prostředku Aplikace logiky (Standard) a Typem prostředku Aplikace logiky (Consumption). Dozvíte se také, jak se prostředí s jedním tenantem porovnává s prostředím integrační služby (ISE) s více tenanty pro nasazování, hostování a spouštění pracovních postupů aplikací logiky.

Prostředek aplikace logiky (Standard)

Typ prostředku Aplikace logiky (Standard) využívá přepracovaný modul runtime pro Azure Logic Apps tenanta. Tento modul runtime používá Azure Functions rozšiřitelnosti a je hostován jako rozšíření v Azure Functions runtime. Tento návrh poskytuje přenositelnost, flexibilitu a vyšší výkon pracovních postupů aplikací logiky a navíc další možnosti a výhody zděděné z platformy Azure Functions a ekosystému Azure App Service logiky. Můžete například vytvářet, nasazovat a spouštět aplikace logiky založené na jednom tenantovi a jejich pracovní postupy v Azure App Service Environment v3.

Typ prostředku Standard zavádí strukturu prostředků, která může hostovat více pracovních postupů, podobně jako může aplikace funkcí Azure hostovat více funkcí. Při mapování 1:M pracovní postupy ve stejné aplikaci logiky a tenantovi sdílejí výpočetní a výpočetní prostředky a poskytují tak lepší výkon z důvodu jejich blízkosti. Tato struktura se liší od prostředku Aplikace logiky (Consumption), kde máte mapování 1:1 mezi prostředek aplikace logiky a pracovním postupem.

Další informace o přenositelnosti, flexibilitě a vylepšeních výkonu najdete v následujících částech. Další informace o modulu runtime a Azure Logic Apps rozšiřitelnosti Azure Functions tenanta najdete v následující dokumentaci:

• Azure Logic Apps Spuštění kdekoli – za běhu do hloubky
• Seznámení s Azure Functions
• Azure Functions triggerů a vazeb

Přenositelnost a flexibilita

Když vytváříte aplikace logiky pomocí typu prostředku Aplikace logiky (Standard), můžete pracovní postupy nasadit a spustit v jiných prostředích, jako je Azure App Service Environment v3. Pokud používáte Visual Studio Code s rozšířením Azure Logic Apps (Standard), můžete místně vyvíjet, sestavovat a spouštět pracovní postupy ve vývojovém prostředí, aniž byste je museli nasazovat do Azure. Pokud váš scénář vyžaduje kontejnery, vytvořte aplikace logiky založené na jednom tenantovi Azure Arc s povoleným Logic Apps. Další informace najdete v Azure Arc povolených Logic Apps.

Tyto možnosti poskytují v porovnání s modelem s více tenanty velká vylepšení a významné výhody, které vyžadují vývoj oproti existujícímu spuštěnému prostředku v Azure. Model s více tenanty pro automatizaci nasazení prostředků aplikace logiky (Consumption) je také zcela založený na šablonách Azure Resource Manager (šablonách ARM), které kombinují a zřídí prostředky pro aplikace i infrastrukturu.

S typem prostředku Aplikace logiky (Standard) je nasazení jednodušší, protože nasazení aplikace můžete oddělit od nasazení infrastruktury. Modul runtime s jedním tenantem můžete Azure Logic Apps a pracovní postupy společně jako součást aplikace logiky. Můžete použít obecné kroky nebo úlohy, které sestaví, sestaví a zazipuje prostředky aplikace logiky do artefaktů připravených k nasazení. K nasazení infrastruktury můžete i nadále používat šablony ARM k samostatném zřizování těchto prostředků spolu s dalšími procesy a kanály, které pro tyto účely používáte.

Pokud chcete nasadit aplikaci, zkopírujte artefakty do hostitelského prostředí a pak aplikace spusťte, aby se spouštěly vaše pracovní postupy. Nebo můžete integrovat artefakty do kanálů nasazení pomocí nástrojů a procesů, které už znáte a používáte. Tímto způsobem můžete nasazovat pomocí vlastních zvolených nástrojů bez ohledu na technologii, kterou používáte pro vývoj.

Pomocí standardních možností sestavení a nasazení se můžete zaměřit na vývoj aplikací nezávisle na nasazení infrastruktury. V důsledku toho získáte obecnější model projektu, ve kterém můžete použít mnoho podobných nebo stejných možností nasazení, které používáte pro obecnou aplikaci. Můžete také využívat konzistentnější prostředí pro vytváření kanálů nasazení kolem projektů aplikací a pro spouštění požadovaných testů a ověření před publikováním do produkčního prostředí.

Výkon

Pomocí typu prostředku Aplikace logiky (Standard) můžete vytvořit a spustit více pracovních postupů ve stejné aplikaci logiky a tenantovi. Díky tomuto mapování 1:M tyto pracovní postupy sdílejí prostředky, jako jsou výpočetní prostředky, zpracování, úložiště a síť, a díky své blízkosti poskytují lepší výkon.

Typ prostředku aplikace logiky (Standard) a modul runtime Azure Logic Apps s jedním tenantem poskytují další významné vylepšení díky tomu, že oblíbenější spravované konektory jsou dostupné jako integrované operace. Můžete například použít integrované operace pro Azure Service Bus, Azure Event Hubs, SQL a další. Verze spravovaných konektorů jsou zatím stále k dispozici a nadále fungují.

Když použijete nové integrované operace, vytvoříte připojení nazývaná integrovaná připojení nebo připojení poskytovatele služeb. Jejich protějšky spravovaného připojení se nazývají připojení API, která se vytvářejí a spouštějí samostatně jako prostředky Azure, které pak musíte nasadit pomocí šablon ARM. Integrované operace a jejich připojení se spouští místně ve stejném procesu, který spouští vaše pracovní postupy. Obě jsou hostované v jednom tenantovi Azure Logic Apps runtime. Díky tomu poskytují integrované operace a jejich připojení lepší výkon z důvodu blízkosti vašich pracovních postupů. Tento návrh také dobře funguje s kanály nasazení, protože připojení poskytovatele služeb jsou zabalena do stejného artefaktu sestavení.

Rezidence dat

Prostředky aplikace logiky vytvořené pomocí typu prostředku Aplikace logiky (Standard) se hostují v tenantovi Azure Logic Apps, který neukládá, zpracovává ani replikuje data mimo oblast, ve které nasazujete tyto prostředky aplikace logiky, což znamená, že data v pracovních postupech aplikací logiky zůstanou ve stejné oblasti,ve které vytvoříte a nasadíte jejich nadřazené prostředky.

Možnosti vytvoření, sestavení a nasazení

Pokud chcete vytvořit aplikaci logiky na základě požadovaného prostředí, máte několik možností, například:

Prostředí s jedním tenantem

Prostředí s více tenanty

Prostředí integrační služby

I když se vaše vývojové prostředí liší v závislosti na tom, jestli vytváříte prostředky s využitím nebo standardní aplikace logiky, můžete najít a získat přístup ke všem nasazeným Logic Apps v rámci vašeho předplatného Azure.

Azure Portal například na stránce Logic Apps (aplikace logiky ) se zobrazuje Spotřeba a standardní typy prostředků aplikace logiky. v Visual Studio Code se nasazené aplikace logiky zobrazí v rámci vašeho předplatného Azure, ale jsou seskupené podle rozšíření, které jste použili, konkrétně pomocí azure: Logic Apps (spotřeba) a azure: Logic Apps (Standard).

Stavové a bezstavové pracovní postupy

Pomocí typu prostředku Aplikace logiky (Standard) můžete vytvořit tyto typy pracovních postupů v rámci stejné aplikace logiky:

• Uzlů

  Stavový pracovní postup vytvořte v případě, že potřebujete zachovat, zkontrolovat nebo odkazovat data z předchozích událostí. Tyto pracovní postupy ukládají a přenášejí všechny vstupy a výstupy pro každou akci a jejich stavy do externího úložiště, což umožňuje po dokončení každého spuštění zkontrolovat podrobnosti a historii spuštění. Stavové pracovní postupy poskytují vysokou odolnost, pokud dojde k výpadkům. Po obnovení služeb a systémů můžete znovu vytvořit přerušené běhy z uloženého stavu a znovu spustit pracovní postupy k dokončení. Stavové pracovní postupy můžou běžet mnohem déle než bezstavové pracovní postupy.

  ve výchozím nastavení se stavové pracovní postupy v jednom tenantovi i v jednom tenantovi Azure Logic Apps spouští asynchronně. Všechny akce založené na protokolu HTTP následují po standardním vzoru asynchronní operace. Tento vzorec určuje, že po volání akce HTTP nebo odeslání požadavku koncovému bodu, službě, systému nebo rozhraní API příjemce okamžitě vrátí odpověď "202 přijatý" . Tento kód potvrdí, že příjemce požadavek přijal, ale nedokončil zpracování. Odpověď může obsahovat location hlavičku, která určuje identifikátor URI a ID aktualizace, které volající může použít k cyklickému dotazování nebo kontrolu stavu asynchronního požadavku, dokud příjemce neukončí zpracování a vrátí odpověď na úspěch "200 OK" nebo jinou odpověď mimo 202. Volající ale nemusí čekat na dokončení zpracování žádosti a může pokračovat v běhu další akce. Další informace najdete v tématu asynchronní integrace mikroslužeb vynutila autonomiimikroslužeb.

• Bezstavová

  Vytvořte bezstavový pracovní postup, pokud nepotřebujete uchovávat, kontrolovat nebo odkazovat data z předchozích událostí v externím úložišti po dokončení každého spuštění pro pozdější kontrolu. Tyto pracovní postupy ukládají všechny vstupy a výstupy pro každou akci a jejich stavy pouze v paměti, nikoli v externím úložišti. V důsledku toho mají bezstavové pracovní postupy kratší dobu, která je obvykle kratší než 5 minut, rychlejší výkon při rychlejší odezvě, vyšší propustnost a snížené provozní náklady, protože podrobnosti a historie spuštění nejsou uloženy v externím úložišti. Pokud se ale dojde k výpadkům, přerušené běhy se automaticky neobnoví, takže volající musí ručně znovu odeslat přerušené běhy.

  Důležité

  Bezstavový pracovní postup poskytuje nejlepší výkon při zpracování dat nebo obsahu, jako je například soubor, který v celkové velikosti nepřekračuje 64 KB. Větší velikosti obsahu, jako je více velkých příloh, můžou výrazně zpomalit výkon pracovního postupu nebo dokonce způsobit selhání pracovního postupu kvůli výjimkám při nedostatku paměti. Pokud by váš pracovní postup mohl zpracovávat větší velikosti obsahu, použijte místo toho stavový pracovní postup.

  Bezstavové pracovní postupy se spouštějí jenom synchronně, takže nepoužívají standardní vzorec asynchronní operace , který používají stavové pracovní postupy. Místo toho všechny akce založené na protokolu HTTP, které vrátí odpověď "202 přijatý" , budou pokračovat k dalšímu kroku provádění pracovního postupu. Pokud odpověď obsahuje location hlavičku, nestavový pracovní postup nebude dotazovat se zadaným identifikátorem URI, aby zkontroloval stav. Chcete-li postupovat podle standardního vzorce asynchronní operace, použijte místo něj stavový pracovní postup.

  Pro snazší ladění můžete povolit historii spuštění pro bezstavový pracovní postup, který má vliv na výkon a po dokončení zakažte historii spuštění. další informace najdete v tématu vytváření pracovních postupů založených na jednom tenantovi v Visual Studio Code nebo vytváření pracovních postupů založených na jednom tenantovi v Azure Portal.

  Poznámka

  Bezstavové pracovní postupy aktuálně podporují jenom Akce pro spravované konektory, které jsou nasazené v Azure, a ne triggery. chcete-li spustit pracovní postup, vyberte buď integrovaný požadavek, Event Hubs nebo aktivační událost Service Bus. tyto triggery se spouštějí nativně v modulu runtime Azure Logic Apps. Další informace o omezených, nedostupných nebo nepodporovaných triggerech, akcích a konektorech najdete v tématu Změna, omezené, nedostupné nebo nepodporované funkce.

Vnořené rozdíly v chování mezi stavové a bezstavové pracovní postupy

Pracovní postup můžete vyvolat z dalších pracovních postupů, které existují ve stejném zdroji Aplikace logiky (Standard) pomocí triggeru žádosti, triggeru Webhooku protokolu HTTPnebo triggerů spravovaného konektoru, které mají typ vstupech apiconnectionwebhook a můžou přijímat požadavky HTTPS.

Tady jsou vzory chování, které mohou vnořené pracovní postupy sledovat poté, co nadřazený pracovní postup volá podřízený pracovní postup:

• Vzor asynchronního cyklického dotazování

  Nadřazený objekt nečeká na odezvu na počáteční volání, ale nepřetržitě kontroluje historii spuštění podřízeného objektu, dokud nebude podřízený objekt spuštěn. Ve výchozím nastavení se řídí stavové pracovní postupy, které jsou ideální pro dlouhotrvající podřízené pracovní postupy, které by mohly překročit limity časových limitů požadavků.

• Synchronní vzor ("oheň" a "zapomenout")

  Podřízená položka potvrdí volání okamžitým vrácením 202 ACCEPTED odpovědi a Nadřazená položka pokračuje k další akci, aniž by bylo nutné čekat na výsledky z podřízeného objektu. Místo toho nadřazený objekt obdrží výsledky po dokončení podřízeného prvku. Podřízené stavové pracovní postupy, které neobsahují akci odpovědi, se vždy řídí synchronním vzorem. V případě podřízených stavových pracovních postupů je k dispozici historie spuštění, kterou si můžete projít.

  Pokud chcete toto chování povolit, v definici JSON pracovního postupu nastavte operationOptions vlastnost na DisableAsyncPattern . Další informace naleznete v tématu Trigger a typy akcí – možnosti operací.

• Aktivovat a počkat

  V případě podřízených bezstavových pracovních postupů nadřazený objekt čeká na odpověď, která vrací výsledky z podřízeného objektu. Tento model funguje podobně jako použití integrovaného triggeru http nebo akce pro volání podřízeného pracovního postupu. Podřízené nestavové pracovní postupy, které nezahrnují akci odpovědi, okamžitě vrátí 202 ACCEPTED odpověď, ale nadřazený objekt čeká na dokončení podřízeného objektu před pokračováním další akce. Toto chování platí jenom pro podřízené pracovní postupy bez stavů.

Tato tabulka určuje chování podřízeného pracovního postupu na základě toho, zda jsou nadřazené a podřízené položky stavové, bezstavové, nebo jsou smíšené typy pracovních postupů:

Další možnosti modelu pro jeden tenant

Model jednoho tenanta a typ prostředku Logic App (Standard) obsahují mnoho současných a nových funkcí, například:

• Vytvářejte aplikace logiky a jejich pracovní postupy ze 400 a spravovaných konektorů pro aplikace typu software jako služba (SaaS) a PaaS (Platform-as-a-Service) a služby a konektory pro místní systémy.

  • Více spravovaných konektorů je nyní dostupných jako integrovaných operací a funguje podobně jako u jiných integrovaných operací, například Azure Functions. integrované operace se nativně spouštějí v prostředí Azure Logic Apps pro jednoho tenanta. mezi nové integrované operace patří například azure Service Bus, azure Event Hubs, SQL Server, MQ, DB2 a IBM Host.

    Poznámka

    pro integrovanou verzi SQL Server se může přímo připojit k virtuálním sítím Azure bez použití místní brány dat.

  • můžete vytvořit vlastní integrované konektory pro libovolnou službu, kterou potřebujete, pomocí architektury rozšíření Azure Logic Apps pro jednoho tenanta. podobně jako u integrovaných operací, jako je například Azure Service Bus a SQL Server, ale na rozdíl od vlastních spravovaných konektorů, které nejsou aktuálně podporovány, vlastní integrované konektory poskytují vyšší propustnost, nízkou latenci a místní připojení, protože jsou spouštěny ve stejném procesu jako modul runtime pro jeden tenant.

    funkce pro vytváření obsahu je aktuálně dostupná jenom v Visual Studio Code, ale ve výchozím nastavení není povolená. chcete-li vytvořit tyto konektory, přepněte projekt z rozšíření na základě sady prostředků (Node.js) na NuGet na základě balíčku (.net). další informace najdete v tématu Azure Logic Apps spouštění odkudkoli a integrovaných rozšíření konektorů.

  • Pro likvidní operace a operace XML bez účtu pro integraci můžete použít následující akce. Tyto operace zahrnují následující akce:

    • XML: transformace XML a ověřování XML

    • Liquid: Transformujte JSON na JSON, Transformujte JSON na text, transformovat XML na JSON a transformovat XML na text .

    Poznámka

    chcete-li tyto akce použít v jednom tenantovi Azure Logic Apps (Standard), je nutné mít k dispozici mapy kapalin, xml mapy nebo schémata xml. tyto artefakty můžete nahrát do Azure Portal z nabídky prostředků vaší aplikace logiky v části Artifacts, která zahrnuje schémata a Mapy oddíly. nebo můžete přidat tyto artefakty do složky Artifacts Visual Studio Code projektu pomocí příslušných složek Mapy a schémat . Tyto artefakty pak můžete použít napříč několika pracovními postupy v rámci stejného prostředku aplikace logiky.

  • prostředky aplikace logiky (Standard) můžou běžet kdekoli, protože Azure Logic Apps generuje připojovací řetězce sdíleného přístupového podpisu (SAS), které tyto aplikace logiky můžou použít k odesílání požadavků do koncového bodu cloudového připojení. služba Azure Logic Apps ukládá tyto připojovací řetězce s dalšími nastaveními aplikací, abyste je mohli snadno ukládat do Azure Key Vault při nasazení v Azure.

    Poznámka

    Ve výchozím nastavení má typ prostředku Aplikace logiky (standardní) pro ověřování připojení za běhu automaticky povolenou spravovanou identitu přiřazenou systémem . Tato identita se liší od přihlašovacích údajů k ověřování nebo připojovacího řetězce, který používáte při vytváření připojení. Pokud tuto identitu zakážete, nebude připojení v době běhu fungovat. Pokud chcete toto nastavení zobrazit, v nabídce vaší aplikace logiky v části Nastavení vyberte Identita.

    Spravovaná identita přiřazená uživatelem v současné době není k dispozici pro typ prostředku Aplikace logiky (Standard).

• Aplikace logiky a jejich pracovní postupy můžete spouštět, testovat a ladit místně v Visual Studio Code vývojovém prostředí.

  Před spuštěním a testováním aplikace logiky můžete usnadnit ladění přidáním a použitím zarážek v souboru workflow.json pro pracovní postup. Zarážky jsou ale podporované pouze pro akce v tuto chvíli, nikoli pro triggery. Další informace najdete v tématu Vytváření pracovních postupů založených na jednom tenantovi v Visual Studio Code.

• Přímo publikovat nebo nasazovat aplikace logiky a jejich pracovní postupy z Visual Studio Code různých hostitelských prostředí, jako je Azure a Azure Arc povolené Logic Apps.

• Povolte možnosti protokolování a trasování diagnostiky pro aplikaci logiky pomocí funkce Application Přehledy, pokud je podporuje vaše nastavení předplatného Azure a aplikace logiky.

• Přístup k síťovým funkcím, jako je například privátní připojení a integrace s virtuálními sítěmi Azure, podobně jako Azure Functions při vytváření a nasazování aplikací logiky pomocí Azure Functions Premium plánu. Další informace najdete v následující dokumentaci:

  • Možnosti sítí Azure Functions

  • Azure Logic Apps Spuštění kdekoli – možnosti sítí s Azure Logic Apps

• Obnovte přístupové klíče pro spravovaná připojení používaná jednotlivými pracovními postupy v prostředku aplikace logiky (Standard). Pro tuto úlohu použijte stejný postup pro prostředek Logic Apps (Consumption),ale na úrovni jednotlivých pracovních postupů, nikoli na úrovni prostředku aplikace logiky.

Změna, omezení, nedostupnost nebo nepodporované možnosti

U prostředku aplikace logiky (Standard) se tyto možnosti změnily nebo jsou aktuálně omezené, nedostupné nebo nepodporované:

• Triggery a akce: Integrované triggery a akce běží nativně v Azure Logic Apps, zatímco spravované konektory jsou hostované a spouštěné v Azure. Některé integrované triggery a akce jsou nedostupné, například Posuvné okno, Batch, Azure App Services a Azure API Management. Pokud chcete spustit stavový nebo bezstavový pracovní postup, použijte integrovaný trigger Opakování, Požadavek, HTTP, Webhook HTTP, Event Hubsnebo Service Bus . V návrháři se na kartě Předdefinování zobrazují integrované triggery a akce.

  U stavových pracovních postupů se triggery a akce spravovaného konektoru zobrazují na kartě Azure s výjimkou níže uvedených nedostupných operací. Pokud chcete vybrat aktivační událost, v případě bezvýsledných pracovních postupů se karta Azure nezobrazí. Můžete vybrat jenom akce spravovaného konektoru, ne triggery. Přestože můžete povolit spravované konektory hostované v Azure pro bezvýsledné pracovní postupy, návrhář pro vás nebude zobrazovat žádné triggery spravovaného konektoru, které byste mohli přidat.

  Poznámka

  Pokud chcete spouštět místně v Visual Studio Code, vyžadují triggery a akce založené na webhoocích další nastavení. Další informace najdete v tématu Vytváření pracovních postupů založených na jednom tenantovi v Visual Studio Code.

  • Tyto triggery a akce se změnily nebo jsou aktuálně omezené, nepodporované nebo nedostupné:

    • Triggery místní brány dat nejsou k dispozici, ale jsou k dispozici akce brány.

    • Integrovaná akce, Azure Functions – Zvolte funkci Azure teď je Operace s funkcemi Azure – Volání funkce Azure. Tato akce aktuálně funguje pouze pro funkce vytvořené ze šablony triggeru HTTP.

      V Azure Portal můžete vybrat funkci triggeru HTTP, ke které máte přístup vytvořením připojení prostřednictvím uživatelského prostředí. Pokud pomocí příkazu Visual Studio Code prohlédnete definici JSON akce funkce v zobrazení kódu nebo v souboru workflow.json, akce bude odkazovat na funkci pomocí connectionName odkazu. Tato verze abstrahuje informace funkce jako připojení, které najdete v souboru connections.json projektu aplikace logiky, který je k dispozici po vytvoření připojení v Visual Studio Code.

      Poznámka

      V modelu s jedním tenantem akce funkce podporuje pouze ověřování řetězce dotazu. Azure Logic Apps získá výchozí klíč z funkce při nahánění připojení, uloží tento klíč do nastavení vaší aplikace a použije klíč k ověření při volání funkce.

      Stejně jako u modelu s více tenanty i když tento klíč obnovíte, například prostřednictvím prostředí Azure Functions na portálu, akce funkce už nebude fungovat kvůli neplatnému klíči. Pokud chcete tento problém vyřešit, musíte znovu vytvořit připojení k funkci, kterou chcete volat nebo aktualizovat nastavení aplikace pomocí nového klíče.

    • Předdefinovaná akce Inline Code(Vložený kód) se přejmenuje na Inline Code Operations(Operace s vloženým kódem), už nevyžaduje účet integrace a má aktualizovaná omezení.

    • Integrovaná akce, Azure Logic Apps – Zvolte pracovní postup aplikace logiky je teď Operace s pracovními postupy – Vyvolání pracovního postupu v této aplikaci pracovního postupu.

    • Některé triggery a akce pro účty integrace nejsou k dispozici, například akce AS2 (V2) a AkceTtaNet.

    • Vlastní spravované konektory se v současné době nepodporují. Vlastní integrované operace však můžete vytvořit, když použijete Visual Studio Code. Další informace najdete v tématu Vytváření pracovních postupů založených na jednom tenantovi pomocí Visual Studio Code.

• Ověřování: Pro typ prostředku Aplikace logiky (Standard) momentálně nejsou k dispozici následující typy ověřování:

  • Azure Active Directory Otevřené ověřování (Azure AD OAuth) pro příchozí volání triggerů založených na žádostech, jako je trigger požadavku a trigger webhooku HTTP.

  • Spravovaná identita přiřazená uživatelem. V současné době je dostupná a automaticky povolená pouze spravovaná identita přiřazená systémem.

• Transformace XML: Podpora odkazování na sestavení z map není aktuálně k dispozici. V současné době se také podporuje pouze XSLT 1.0.

• Ladění zarážek v Visual Studio Code : I když můžete přidat a použít zarážky v souboru workflow.json pro pracovní postup, zarážky jsou podporované pouze pro akce v tuto chvíli, nikoli pro aktivační události. Další informace najdete v tématu Vytváření pracovních postupů založených na jednom tenantovi v Visual Studio Code.

• Historie triggerů a historie spuštění: Pro typ prostředku Aplikace logiky (Standard) se historie triggerů a historie spuštění v Azure Portal zobrazí na úrovni pracovního postupu, nikoli na úrovni aplikace logiky. Další informace najdete v tématu Vytváření pracovních postupů založených na jednom tenantovi pomocí Azure Portal.

• Ovládací prvek Lupa: Ovládací prvek lupy není v návrháři momentálně k dispozici.

• Cíle nasazení: Typ prostředku Aplikace logiky (Standard) nemůžete nasadit do prostředí integrační služby (ISE) ani do slotů nasazení Azure.

• Azure API Management: V současné době není možné importovat typ prostředku Aplikace logiky (Standard) do Azure API Management. Můžete ale importovat typ prostředku Aplikace logiky (Consumption).

Striktní oprávnění k provozu sítě a brány firewall

Pokud má vaše prostředí přísné požadavky na síť nebo brány firewall, které omezují provoz, musíte povolit přístup pro všechna připojení triggerů nebo akcí v pracovních postupech aplikací logiky. Pokud chcete najít plně kvalifikované názvy domén pro tato připojení, projděte si odpovídající části v těchto tématech:

• Oprávnění brány firewall pro aplikace logiky s jedním tenantem – Visual Studio Code
• Oprávnění brány firewall pro aplikace logiky s jedním tenantem – Azure Portal

Další kroky

• Vytváření pracovních postupů založených na jednom tenantovi v Azure Portal
• Vytváření pracovních postupů založených na jednom tenantovi v Visual Studio Code

Rádi bychom se také doslechly o vašich zkušenostech s jedno tenanty a Azure Logic Apps!

• V případě chyb nebo problémů vytvořte problémy v GitHub.
• V případě dotazů, žádostí, komentářů a dalších připomínek použijte tento formulář pro zpětnou vazbu.