Rozdíly mezi standardními aplikacemi logiky s jedním tenantem a víceklientovými aplikacemi logiky Consumption

Azure Logic Apps je cloudová platforma pro vytváření a spouštění pracovních postupů automatizovaných aplikací logiky , které integrují vaše aplikace, data, služby a systémy. S touto platformou můžete rychle vyvíjet vysoce škálovatelná integrační řešení pro scénáře B2B (Enterprise-to-Business). Při vytváření prostředku aplikace logiky vyberete možnost Consumption nebo Standard hostování. Aplikace logiky Consumption může mít pouze jeden pracovní postup, který běží ve víceklientských azure Logic Apps. Standardní aplikace logiky může mít jeden nebo více pracovních postupů, které běží v Azure Logic Apps s jedním tenantem nebo ve službě App Service Environment v3 (ASE v3).

Než zvolíte, který prostředek aplikace logiky se má vytvořit, projděte si následující průvodce a zjistěte, jak se typy pracovních postupů aplikace logiky vzájemně porovnávají. Pak můžete lépe zvolit, který pracovní postup a prostředí aplikace logiky nejlépe vyhovují vašemu scénáři, požadavkům řešení a cíli, kam chcete pracovní postupy nasadit a spouštět.

Pokud s Azure Logic Apps začínáte, přečtěte si, co je Azure Logic Apps? a co je pracovní postup aplikace logiky?

Typy a prostředí pracovního postupu aplikace logiky

Následující tabulka shrnuje rozdíly mezi pracovním postupem aplikace logiky Consumption a pracovním postupem standardní aplikace logiky. Dozvíte se také, jak se prostředí s jedním tenantem liší od prostředí s více tenanty pro nasazení, hostování a spouštění pracovních postupů.

Možnost hostování	Zaměstnanecké výhody	Sdílení a využití prostředků	Cenový a fakturační model	Správa omezení
Využití Hostitelské prostředí: Víceklientská služba Azure Logic Apps	- Nejjednodušší začít - Zaplatit za to, co používáte – Plně spravovaná	Jeden prostředek aplikace logiky může mít pouze jeden pracovní postup. Všechny aplikace logiky v tenantech Microsoft Entra sdílejí stejné zpracování (výpočetní prostředky), úložiště, síť atd. Pro účely redundance se data replikují ve spárované oblasti. Pro zajištění vysoké dostupnosti je povolené geograficky redundantní úložiště (GRS ).	Spotřeba (průběžné platby)	Azure Logic Apps spravuje výchozí hodnoty těchto limitů, ale některé z těchto hodnot můžete změnit, pokud tato možnost existuje pro určitý limit.
Standard (plán služby pracovního postupu) Hostitelské prostředí: Azure Logic Apps s jedním tenantem Poznámka: Pokud váš scénář vyžaduje kontejnery, vytvořte aplikace logiky založené na jednom tenantovi pomocí Logic Apps s podporou Azure Arc. Další informace najdete v tématu Co je Logic Apps s podporou Služby Azure Arc?	– Další integrované konektory hostované v modulu runtime s jedním tenantem pro zajištění vyšší propustnosti a nižších nákladů ve velkém měřítku - Větší možnosti řízení a vyladění kolem nastavení modulu runtime a výkonu – Integrovaná podpora virtuálních sítí a privátních koncových bodů. – Vytvořte si vlastní integrované konektory.	Jeden prostředek aplikace logiky může mít několik stavových a bezstavových pracovních postupů. Pracovní postupy v jedné aplikaci logiky a tenantovi sdílejí stejné zpracování (výpočetní prostředky), úložiště, síť atd. Data zůstanou ve stejné oblasti, ve které nasazujete aplikaci logiky.	Standard na základě plánu hostování s vybranou cenovou úrovní. Pokud spouštíte stavové pracovní postupy, které používají externí úložiště, modul runtime Azure Logic Apps provádí transakce úložiště, které se řídí cenami služby Azure Storage.	Výchozí hodnoty pro mnoho omezení můžete změnit na základě potřeb vašeho scénáře. Důležité: Některá omezení mají pevné horní maximum. V editoru Visual Studio Code se změny výchozích hodnot omezení v konfiguračních souborech projektu aplikace logiky nezobrazí v prostředí návrháře. Další informace najdete v tématu Úprava nastavení aplikace a prostředí pro aplikace logiky v Azure Logic Apps s jedním tenantem.
Standard (App Service Environment v3) Hostitelské prostředí: App Service Environment v3 (ASEv3) – pouze plány Windows	Stejné funkce jako jeden tenant a následující výhody: – Plně izolujte své aplikace logiky. – Vytváření a spouštění více aplikací logiky než v Azure Logic Apps s jedním tenantem – Platíte jenom za plán služby App Service SLUŽBY ASE bez ohledu na počet aplikací logiky, které vytvoříte a spustíte. – Umožňuje automatické škálování nebo ruční škálování s více instancemi virtuálních počítačů nebo jiným plánem služby App Service. – Zdědí nastavení sítě z vybrané služby ASEv3. Když například nasadíte do interní služby ASE, pracovní postupy budou mít přístup k prostředkům ve virtuální síti přidružené ke službě ASE a mají interní přístupové body. Poznámka: Pokud se přistupuje z vnějšku interní služby ASE, historie spuštění pracovních postupů v této službě ASE nemá přístup ke vstupům a výstupům akcí.	Jedna aplikace logiky může mít několik stavových a bezstavových pracovních postupů. Pracovní postupy v jedné aplikaci logiky a tenantovi sdílejí stejné zpracování (výpočetní prostředky), úložiště, síť atd. Data zůstanou ve stejné oblasti, ve které nasazujete aplikace logiky.	Plán služby App Service	Výchozí hodnoty pro mnoho omezení můžete změnit na základě potřeb vašeho scénáře. Důležité: Některá omezení mají pevné horní maximum. V editoru Visual Studio Code se změny výchozích hodnot omezení v konfiguračních souborech projektu aplikace logiky nezobrazí v prostředí návrháře. Další informace najdete v tématu Úprava nastavení aplikace a prostředí pro aplikace logiky v Azure Logic Apps s jedním tenantem.

Standardní aplikace logiky a pracovní postup

Standardní aplikace logiky a pracovní postup využívají přepracovaný modul runtime Azure Logic Apps s jedním tenantem. Tento modul runtime používá model rozšiřitelnosti služby Azure Functions a je hostovaný jako rozšíření v modulu runtime Azure Functions. Tento návrh poskytuje přenositelnost, flexibilitu a vyšší výkon pracovních postupů aplikace logiky a další možnosti a výhody zděděné z platformy Azure Functions a ekosystému služby Aplikace Azure Service. Můžete například vytvářet, nasazovat a spouštět aplikace logiky založené na jednom tenantovi a jejich pracovní postupy v prostředí Aplikace Azure Service Environment v3 (jenom plány Windows).

Standardní aplikace logiky zavádí strukturu prostředků, která může hostovat více pracovních postupů, podobně jako aplikace funkcí Azure může hostovat více funkcí. S mapováním 1:N sdílejí pracovní postupy ve stejné aplikaci logiky a tenantovi výpočetní prostředky a zpracovávají prostředky, což poskytuje 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ředkem aplikace logiky a pracovním postupem.

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

• Azure Logic Apps spuštěné kdekoli – Podrobné informace o modulu runtime
• Seznámení s Azure Functions
• Triggery a vazby Azure Functions

Přenositelnost a flexibilita

Když vytvoříte aplikaci a pracovní postup standardní logiky, můžete pracovní postup nasadit a spustit v jiných prostředích, jako je například Aplikace Azure Service Environment v3 (jenom plány Windows). 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í postup ve vývojovém prostředí bez nutnosti nasazení do Azure. Pokud váš scénář vyžaduje kontejnery, můžete vytvářet aplikace logiky s jedním tenantem pomocí Logic Apps s podporou Azure Arc. Další informace najdete v tématu Co je Logic Apps s podporou Služby Azure Arc?

Tyto funkce poskytují velká vylepšení a významné výhody v porovnání s víceklientovým modelem, které vyžadují vývoj proti existujícímu spuštěném prostředku v Azure. Víceklientový model pro automatizaci nasazení prostředků aplikace logiky Consumption je založený na šablonách Azure Resource Manageru (šablony ARM), které kombinují a zpracovávají zřizování prostředků pro aplikace i infrastrukturu.

S prostředkem aplikace logiky úrovně Standard je nasazení jednodušší, protože nasazení aplikace můžete oddělit od nasazení infrastruktury. Modul runtime Azure Logic Apps s jedním tenantem a pracovní postupy můžete zabalit společně jako součást prostředku nebo projektu aplikace logiky. Můžete použít obecné kroky nebo úlohy, které sestaví, sestaví a zazipují prostředky aplikace logiky do artefaktů připravených k nasazení. Pokud chcete nasadit infrastrukturu, můžete šablony ARM dál používat k samostatnému zřizování těchto prostředků spolu s dalšími procesy a kanály, které pro tyto účely používáte.

Pokud chcete aplikaci nasadit, zkopírujte artefakty do hostitelského prostředí a spusťte aplikace, aby se spouštěly vaše pracovní postupy. Nebo integrujte artefakty do kanálů nasazení pomocí nástrojů a procesů, které už znáte a používáte. Tímto způsobem můžete nasadit 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í odděleně od nasazení infrastruktury. V důsledku toho získáte obecnější projektový model, kde můžete použít mnoho podobných nebo stejných možností nasazení, které používáte pro obecnou aplikaci. Můžete také využít konzistentnější prostředí při sestavování kanálů nasazení pro vaše aplikace a při spouštění požadovaných testů a ověření před publikováním do produkčního prostředí.

Výkon

Pomocí standardní aplikace logiky můžete vytvořit a spustit více pracovních postupů ve stejném prostředku a tenantovi jedné aplikace logiky. Díky tomuto mapování 1:N tyto pracovní postupy sdílejí prostředky, jako jsou výpočetní prostředky, zpracování, úložiště a síť, což poskytuje lepší výkon z důvodu jejich blízkosti.

Prostředek aplikace logiky Standard a modul runtime Azure Logic Apps s jedním tenantem poskytují další významné vylepšení tím, že zpřístupníte nejoblíbenější spravované konektory jako integrované operace konektoru. Můžete například použít integrované operace konektoru pro Azure Service Bus, Azure Event Hubs, SQL Server a další. Mezitím jsou verze spravovaného konektoru stále dostupné a dál fungují.

Při použití nových integrovaných operací konektoru vytvoříte připojení označovaná jako integrovaná připojení nebo připojení poskytovatele služeb. Jejich protějšky spravovaného připojení se nazývají připojení ROZHRANÍ API, která se vytvářejí a spouštějí samostatně jako prostředky Azure, které musíte nasadit také pomocí šablon ARM. Integrované operace a jejich připojení běží místně ve stejném procesu, který spouští vaše pracovní postupy. Oba jsou hostované v modulu runtime Azure Logic Apps s jedním tenantem. Díky tomu integrované operace a jejich připojení poskytují 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í.

Umístění dat

Prostředky standardní aplikace logiky jsou hostované v Azure Logic Apps s jedním tenantem, které neukládají, zpracovávají ani replikují data mimo oblast, ve které nasazujete tyto prostředky aplikace logiky, což znamená, že data ve vašich pracovních postupech zůstanou ve stejné oblasti, ve které vytváříte a nasazujete jejich nadřazené prostředky.

Přímý přístup k prostředkům ve virtuálních sítích Azure

Pracovní postupy spuštěné v Azure Logic Apps s jedním tenantem můžou přímo přistupovat k zabezpečeným prostředkům, jako jsou virtuální počítače, další služby a systémy, které existují ve virtuální síti Azure.

Azure Logic Apps s jedním tenantem je vyhrazená instance služby Azure Logic Apps, používá vyhrazené prostředky a běží odděleně od víceklientských Azure Logic Apps. Spouštění pracovních postupů ve vyhrazené instanci pomáhá snížit dopad, který můžou mít ostatní tenanti Azure na výkon aplikace, označovaný také jako "hlučné sousedy".

Azure Logic Apps s jedním tenantem také nabízí následující výhody:

• Vaše vlastní statické IP adresy, které jsou oddělené od statických IP adres sdílených aplikacemi logiky ve víceklientských azure Logic Apps. Můžete také nastavit jednu veřejnou, statickou a předvídatelnou odchozí IP adresu pro komunikaci s cílovými systémy. Tímto způsobem nemusíte v těchto cílových systémech nastavovat další otevření brány firewall.

• Zvýšené limity doby trvání běhu, uchovávání úložiště, propustnosti, časového limitu požadavků HTTP a odpovědí, velikostí zpráv a požadavků na vlastní konektory. Další informace najdete v tématu Omezení a konfigurace pro Azure Logic Apps.

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

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

Prostředí s jedním tenantem

Možnost	Prostředky a nástroje	Více informací
portál Azure	Standardní aplikace logiky	Vytvoření ukázkového pracovního postupu standardní aplikace logiky v Azure Logic Apps s jedním tenantem – Azure Portal
Visual Studio Code	Rozšíření Azure Logic Apps (Standard)	Vytvoření ukázkového pracovního postupu standardní aplikace logiky v Azure Logic Apps s jedním tenantem – Visual Studio Code
Azure CLI	Rozšíření Azure CLI pro Logic Apps	az logicapp
Azure Resource Manager	- Místní - DevOps	Azure Logic Apps s jedním tenantem
Logic Apps s podporou Azure Arc	Ukázka Logic Apps s podporou Azure Arc	- Co je Logic Apps s podporou Azure Arc? - Vytváření a nasazování pracovních postupů aplikací logiky založených na jednom tenantovi s využitím Logic Apps s podporou Azure Arc
Azure REST API	rozhraní REST API služby Aplikace Azure* Poznámka: Rozhraní REST API standardní aplikace logiky je součástí rozhraní REST API služby Aplikace Azure.	Začínáme s referenčními informacemi k rozhraní Azure REST API

Víceklientové prostředí

Možnost	Prostředky a nástroje	Více informací
portál Azure	Aplikace logiky Consumption	Rychlý start: Vytvoření ukázkového pracovního postupu aplikace logiky Consumption ve víceklientských azure Logic Apps – Azure Portal
Visual Studio Code	Rozšíření Azure Logic Apps (Consumption)	Rychlý start: Vytvoření ukázkového pracovního postupu aplikace logiky Consumption ve víceklientských aplikacích Azure Logic Apps – Visual Studio Code
Azure CLI	Rozšíření Azure CLI pro Logic Apps	- Rychlý start: Vytváření a správa pracovních postupů aplikací logiky Consumption ve víceklientských azure Logic Apps – Azure CLI - az logic
Azure Resource Manager	Vytvoření šablony ARM aplikace logiky	Rychlý start: Vytvoření a nasazení pracovních postupů aplikace logiky Consumption ve víceklientských azure Logic Apps – šablona ARM
Azure PowerShell	Modul Az.LogicApp	Začínáme s Azure PowerShellem
Azure REST API	Azure Logic Apps REST API	Začínáme s referenčními informacemi k rozhraní Azure REST API

I když se vaše vývojové prostředí liší podle toho, jestli vytváříte prostředky aplikace logiky Consumption nebo Standard , můžete najít a získat přístup ke všem nasazenám aplikacím logiky v rámci předplatného Azure.

Například na webu Azure Portal se na stránce Aplikace logiky zobrazují prostředky aplikace logiky Consumption i Standard. V editoru Visual Studio Code se nasazené aplikace logiky zobrazí v rámci předplatného Azure, ale aplikace logiky Consumption se zobrazí v okně Azure v rozšíření Azure Logic Apps (Consumption), zatímco standardní aplikace logiky se zobrazují v části Prostředky.

Stavové a bezstavové pracovní postupy

V aplikaci standardní logiky můžete vytvořit následující typy pracovních postupů:

• Stavové

  Pokud potřebujete zachovat, zkontrolovat nebo odkazovat data z předchozích událostí, vytvořte stavový pracovní postup. Tyto pracovní postupy ukládají všechny vstupy, výstupy a stavy operací do externího úložiště. Tyto informace umožňují po dokončení každého spuštění zkontrolovat podrobnosti a historii spuštění pracovního postupu. Stavové pracovní postupy poskytují vysokou odolnost, pokud dojde k výpadkům. Po obnovení služebach Stavové pracovní postupy můžou běžet mnohem déle než bezstavové pracovní postupy.

  Ve výchozím nastavení běží stavové pracovní postupy ve víceklientských i jednoklientských azure Logic Apps asynchronně. Všechny akce založené na protokolu HTTP se řídí standardním vzorem asynchronní operace. Jakmile akce HTTP zavolá nebo odešle požadavek do koncového bodu, služby, systému nebo rozhraní API, příjemce požadavku okamžitě vrátí odpověď 202 ACCEPTED . Tento kód potvrdí, že příjemce přijal požadavek, ale nedokončil zpracování. Odpověď může obsahovat hlavičkulocation, která určuje identifikátor URI a ID aktualizace, které volající může použít k dotazování nebo kontrole stavu asynchronního požadavku, dokud příjemce nezastaví zpracování a nevrátí odpověď na úspěch 200 OK nebo jinou odpověď, která není 202. Volající ale nemusí čekat na dokončení zpracování požadavku a může pokračovat ve spuštění další akce. Další informace najdete v tématu Asynchronní integrace mikroslužeb vynucuje autonomii mikroslužeb.

• Bez státní příslušnosti

  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, vytvořte bezstavový pracovní postup. Tyto pracovní postupy ukládají všechny vstupy a výstupy pro každou akci a jejich stavy pouze v paměti, ne v externím úložišti. V důsledku toho mají bezstavové pracovní postupy kratší běhy, které obvykle končí za 5 minut nebo méně, rychlejší výkon s rychlejší dobou odezvy, vyšší propustností a nižšími průběžnými náklady, protože externí úložiště neukládá podrobnosti a historii spuštění pracovního postupu. Pokud dojde k výpadkům, přerušované spuštění se automaticky neobnoví, takže volající musí ručně znovu spustit přerušená spuštění.

  Bezstavový pracovní postup poskytuje nejlepší výkon při zpracování dat nebo obsahu, který nepřekračuje celkovou velikost 64 kB, jako je například soubor. Větší velikosti obsahu, například více velkých příloh, můžou výrazně zpomalit výkon pracovního postupu nebo dokonce způsobit chybové ukončení pracovního postupu kvůli výjimkám nedostatku paměti. Pokud je možné, že pracovní postup bude muset zpracovat větší velikosti obsahu, použijte místo toho stavový pracovní postup.

  Poznámka:

  V bezstavových pracovních postupech můžete použít pouze triggery nabízených oznámení, ve kterých nezadáte plán spuštění pracovního postupu. Tyto triggery založené na webhooku čekají na to, až se událost stane, nebo se zpřístupní data. Trigger opakování je například k dispozici pouze pro stavové pracovní postupy. Pokud chcete spustit pracovní postup, vyberte aktivační událost nabízených oznámení, jako je například požadavek, služba Event Hubs nebo trigger služby Service Bus. 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.

  Bezstavové pracovní postupy běží synchronně, takže nepoužívají standardní vzor asynchronní operace používaný stavovými pracovními postupy. Místo toho všechny akce založené na protokolu HTTP, které vrací odpověď 202 ACCEPTED, budou pokračovat dalším krokem v provádění pracovního postupu. Pokud odpověď obsahuje hlavičku location , bezstavový pracovní postup se nebude dotazovat na zadaný identifikátor URI a zkontroluje stav. Pokud chcete postupovat podle standardního vzoru asynchronní operace, použijte místo toho stavový pracovní postup.

  Pro snadnější ladění můžete povolit historii spuštění pro bezstavový pracovní postup, který má nějaký vliv na výkon, a po dokončení zakázat historii spuštění. Další informace najdete v tématu Vytváření pracovních postupů založených na jednom tenantovi v nástroji Visual Studio Code nebo vytváření pracovních postupů založených na jednom tenantovi na webu Azure Portal.

Důležité

Musíte se rozhodnout o typu pracovního postupu( stavový nebo bezstavový), který se má implementovat při vytváření. Změny typu pracovního postupu po vytvoření způsobí chyby za běhu.

Souhrnné rozdíly mezi stavovými a bezstavovými pracovními postupy

Stavové	Bezstavové
Ukládá historii spuštění, vstupy a výstupy.	Neukládá ve výchozím nastavení historii spuštění, vstupy ani výstupy.
Triggery spravovaného konektoru jsou dostupné a povolené.	Triggery spravovaného konektoru nejsou k dispozici nebo nejsou povolené.
Podporuje vytváření bloků dat.	Žádná podpora pro vytváření bloků dat
Podporuje asynchronní operace.	Žádná podpora asynchronních operací
Úprava výchozí maximální doby běhu v konfiguraci hostitele	Nejvhodnější pro pracovní postupy s maximální dobou trvání do 5 minut
Zpracovává velké zprávy.	Nejvhodnější pro zpracování malých velikostí zpráv (do 64 kB)

Rozdíly vnořeného chování mezi stavovými a bezstavovými pracovními postupy

Pracovní postup můžete volat z jiných pracovních postupů, které existují ve stejné standardní aplikaci logiky, pomocí triggeru požadavku, triggeru webhooku HTTP nebo triggerů spravovaného konektoru, které mají typ ApiConnectionWebhook a mohou přijímat požadavky HTTPS.

Následující seznam popisuje vzorce chování, které mohou vnořené pracovní postupy následovat po volání podřízeného pracovního postupu nadřazeného pracovního postupu:

• Model asynchronního dotazování

  Nadřazený pracovní postup nečeká, až podřízený pracovní postup odpoví na počáteční volání. Nadřazený objekt však průběžně kontroluje historii spuštění dítěte, dokud se podřízená položka nedokončí. Stavové pracovní postupy ve výchozím nastavení se řídí tímto vzorem, což je ideální pro dlouhotrvající podřízené pracovní postupy, které můžou překročit limity časového limitu požadavků.

• Synchronní vzor ("fire and forget")

  Podřízený pracovní postup potvrdí volání nadřazeného pracovního postupu okamžitě vrácením 202 ACCEPTED odpovědi. Nadřazený objekt ale nečeká na vrácení výsledků podřízeného objektu. Místo toho nadřazený objekt pokračuje k další akci v pracovním postupu a obdrží výsledky po dokončení spuštění podřízené položky. Podřízené stavové pracovní postupy, které nezahrnují akci Odpovědi, vždy dodržují synchronní vzor a poskytují historii spuštění, kterou můžete zkontrolovat.

  Pokud chcete toto chování povolit, nastavte operationOptions v definici JSON pracovního postupu vlastnost na DisableAsyncPatternhodnotu . Další informace najdete v tématu Typy aktivačních událostí a akcí – Možnosti operace.

• Aktivační událost a čekání

  Bezstavové pracovní postupy běží v paměti. Takže když nadřazený pracovní postup volá podřízený bezstavový pracovní postup, nadřazený počká na odpověď, která vrátí výsledky z podřízené položky. Tento model funguje podobně jako použití integrovaného triggeru HTTP nebo akce k volání podřízeného pracovního postupu. Podřízené bezstavové pracovní postupy, které neobsahují akci Odpovědi, okamžitě vrátí 202 ACCEPTED odpověď, ale nadřazený proces čeká na dokončení podřízené akce, než bude pokračovat k další akci. Toto chování platí pouze pro podřízené bezstavové pracovní postupy.

Následující tabulka identifikuje chování podřízeného pracovního postupu na základě toho, jestli jsou nadřazené a podřízené typy stavových, bezstavových nebo smíšených typů pracovních postupů. Seznam za tabulkou

Nadřazený pracovní postup	Podřízený pracovní postup	Chování dítěte
Stavové	Stavové	Asynchronní nebo synchronní s "operationOptions": "DisableAsyncPattern" nastavením
Stavové	Bezstavové	Aktivační událost a čekání
Bezstavové	Stavové	Synchronní
Bezstavové	Bezstavové	Aktivační událost a čekání

Další funkce modelu s jedním tenantem

Model s jedním tenantem a aplikace logiky Standard zahrnují mnoho aktuálních a nových funkcí, například:

• Vytvářejte aplikace logiky a jejich pracovní postupy z 1 400 spravovaných konektorů pro aplikace a služby Typu software jako služba (SaaS) a platformy jako služba (PaaS) a konektory pro místní systémy.

  • Další spravované konektory jsou nyní k dispozici jako integrované konektory v pracovních postupech Standard. Integrované verze běží nativně v modulu runtime Azure Logic Apps s jedním tenantem. Některé integrované konektory se také neformálně označují jako konektory poskytovatele služeb. Seznam najdete v části Integrované konektory ve spotřebě a standardu.

  • Vlastní integrované konektory můžete vytvořit pro libovolnou službu, kterou potřebujete, pomocí architektury rozšiřitelnosti Azure Logic Apps s jedním tenantem. Podobně jako integrované konektory, jako je Azure Service Bus a SQL Server, poskytují vlastní integrované konektory vyšší propustnost, nízkou latenci a místní připojení, protože běží ve stejném procesu jako modul runtime s jedním tenantem. Vlastní integrované konektory se ale podobají vlastním spravovaným konektorům, které se v současné době nepodporují. Další informace najdete v přehledu vlastních konektorů a vytváření vlastních integrovaných konektorů pro aplikace logiky Standard v Azure Logic Apps s jedním tenantem.

  • Pro operace Liquid a OPERACE XML bez účtu integrace můžete použít následující akce. Mezi tyto operace patří následující akce:

    • XML: Transformace XML, ověřování XML, vytváření XML se schématem a analýza XML se schématem

    • Liquid: Transformace JSON na JSON, transformace JSON na TEXT, transformace XML na JSON a transformace XML na text

    Poznámka:

    Pokud chcete tyto akce použít ve standardních pracovních postupech, musíte mít mapování Liquid, mapování XML nebo schémata XML. Tyto artefakty můžete nahrát na webu Azure Portal z nabídky prostředků aplikace logiky v části Artefakty, které zahrnují oddíly Schémata a Mapy . Nebo můžete tyto artefakty přidat do složky Artefakty projektu editoru Visual Studio Code pomocí příslušných složek Mapy a schémata. Tyto artefakty pak můžete použít napříč několika pracovními postupy ve stejné aplikaci logiky.

  • Pracovní postupy standardní aplikace logiky se můžou aktivovat odkudkoli, protože Azure Logic Apps generuje sdílený přístupový podpis (SAS) připojovací řetězec, které tyto aplikace logiky můžou použít k odesílání požadavků do koncového bodu modulu runtime cloudového připojení. Azure Logic Apps tyto připojovací řetězec ukládá s dalšími nastaveními aplikace, abyste tyto hodnoty mohli snadno uložit ve službě Azure Key Vault při nasazení v Azure.

  • Pracovní postupy standardní aplikace logiky podporují povolení spravované identity přiřazené systémem i více spravovaných identit přiřazených uživatelem najednou, i když můžete vybrat jenom jednu identitu, která se má použít najednou. I když integrované konektory založené na poskytovatelích služeb podporují použití identity přiřazené systémem, většina aktuálně nepodporuje výběr spravovaných identit přiřazených uživatelem pro ověřování, s výjimkou SQL Serveru a konektorů HTTP.

    Poznámka:

    Ve výchozím nastavení je identita přiřazená systémem už povolená k ověřování připojení za běhu. Tato identita se liší od přihlašovacích údajů ověřování nebo připojovací řetězec, které používáte při vytváření připojení. Pokud tuto identitu zakážete, připojení nebudou za běhu fungovat. Pokud chcete toto nastavení zobrazit, vyberte v nabídce aplikace logiky v části Nastavení možnost Identita.

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

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

• Přímo publikujte nebo nasazujte aplikace logiky a jejich pracovní postupy ze sady Visual Studio Code do různých hostitelských prostředí, jako jsou Azure a Azure Arc s podporou Logic Apps.

• Povolte možnosti protokolování a trasování diagnostiky pro vaši aplikaci logiky pomocí Application Insights , pokud je podporováno nastavením předplatného Azure a aplikace logiky.

• Při vytváření a nasazování aplikací logiky pomocí plánu Azure Functions Premium můžete přistupovat k síťovým možnostem, jako je připojení a integrace soukromě s virtuálními sítěmi Azure Functions. Další informace najdete v následující dokumentaci:

  • Možnosti sítí Azure Functions

  • Azure Logic Apps běžící kdekoli – Možnosti sítí s Využitím Azure Logic Apps

• Znovu vygenerujte přístupové klíče pro spravovaná připojení používaná jednotlivými pracovními postupy ve standardní aplikaci logiky. Pro tuto úlohu použijte stejný postup pro aplikaci logiky Consumption , ale na úrovni pracovního postupu, nikoli na úrovni prostředku aplikace logiky.

Integrované konektory pro standard

Standardní pracovní postup může používat mnoho stejných integrovaných konektorů jako pracovní postup Consumption, ale ne všechny. Naopak má pracovní postup Standard řadu integrovaných konektorů, které nejsou dostupné v pracovním postupu Consumption.

Pracovní postup Standard má například spravované konektory i integrované konektory pro Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server a další. I když pracovní postup Consumption nemá stejné integrované verze konektorů, jsou k dispozici i další integrované konektory, jako je Azure API Management a Aplikace Azure Services.

V Azure Logic Apps s jedním tenantem jsou integrované konektory s konkrétními atributy neformálně označované jako poskytovatelé služeb. Některé integrované konektory podporují pouze jeden způsob ověřování připojení k podkladové službě. Další integrované konektory můžou nabídnout volbu, například použití připojovací řetězec, ID Microsoft Entra nebo spravované identity. Všechny integrované konektory běží ve stejném procesu jako přepracovaný modul runtime Azure Logic Apps. Další informace najdete v integrovaném seznamu konektorů pro pracovní postupy standardní aplikace logiky.

Důležité

Ujistěte se, že je správně nastavená a otestovaná aktivační událost založená na poskytovateli služeb, abyste potvrdili úspěšnou operaci. Trigger založený na poskytovateli služeb, který selhal, může způsobit zbytečné škálování, což může výrazně zvýšit náklady na fakturaci. Běžnou chybou je například nastavení triggeru bez udělení oprávnění aplikace logiky nebo přístupu k cíli, jako je například fronta služby Service Bus, kontejner objektů blob služby Azure Storage atd. Také se ujistěte, že tyto triggery monitorujete vždy, abyste mohli rychle rozpoznat a opravit všechny problémy.

Změněné, omezené, nedostupné nebo nepodporované funkce

Pro pracovní postup standardní aplikace logiky se následující funkce liší, aktuálně jsou 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é pomocí sdílených prostředků v Azure. U standardních pracovních postupů nejsou aktuálně k dispozici některé předdefinované triggery a akce, jako jsou posuvné okno a operace služby Aplikace Azure. Pokud chcete spustit stavový nebo bezstavový pracovní postup, použijte předdefinovaný trigger, například trigger Request, Event Hubs nebo Service Bus. Aktivační událost opakování je k dispozici pro stavové pracovní postupy, ale ne pro bezstavové pracovní postupy. V návrháři se předdefinované triggery a akce zobrazují s popiskem v aplikaci, zatímco triggery a akce spravovaného konektoru se zobrazí se sdíleným popiskem.

  Bezstavové pracovní postupy můžou používat jenom triggery nabízených oznámení, ve kterých nezadáte plán spuštění pracovního postupu. Tyto triggery založené na webhooku čekají na to, až se událost stane, nebo se zpřístupní data. Trigger opakování je například k dispozici pouze pro stavové pracovní postupy. Pokud chcete spustit pracovní postup, vyberte aktivační událost nabízených oznámení, jako je například požadavek, služba Event Hubs nebo trigger služby Service Bus. I když můžete povolit spravované konektory pro bezstavové pracovní postupy, galerie konektorů nezobrazuje žádné triggery dotazování spravovaných konektorů, které můžete přidat.

  Poznámka:

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

  • Následující triggery a akce se buď změnily, nebo jsou aktuálně omezené, nepodporované nebo nedostupné:

    • Integrovaná akce Azure Functions – Volba funkce Azure je teď operace Azure Functions – Volání funkce Azure. Tato akce aktuálně funguje jenom pro funkce vytvořené ze šablony triggeru HTTP.

      Na webu 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 zkontrolujete definici JSON akce funkce v zobrazení kódu nebo v souboru workflow.json pomocí editoru Visual Studio Code, akce odkazuje na funkci pomocí connectionName odkazu. Tato verze abstrahuje informace o funkci jako připojení, které najdete v souboru connections.json projektu aplikace logiky, který je k dispozici po vytvoření připojení v editoru 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 vytváření připojení, uloží tento klíč do nastavení vaší aplikace a použije ho k ověřování při volání funkce.

      Stejně jako u víceklientských modelů platí, že pokud tento klíč obnovíte, například prostřednictvím prostředí Azure Functions na portálu, nebude akce funkce 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 Vložený kód se přejmenuje na Operace vloženého kódu, už nevyžaduje účet integrace a má aktualizované limity.

    • Integrovaná akce Azure Logic Apps – Volba pracovního postupu aplikace logiky je nyní Operace pracovního postupu – Vyvolání pracovního postupu v této aplikaci pracovního postupu.

    • Vlastní spravované konektory se momentálně nepodporují. Při použití editoru Visual Studio Code však můžete vytvářet vlastní integrované operace . Další informace najdete v tématu Vytváření pracovních postupů založených na jednom tenantovi pomocí editoru Visual Studio Code.

    • Standardní pracovní postup může mít pouze jeden trigger a nepodporuje více triggerů.

• Authentication

  • Některé triggery založené na žádostech, které zpracovávají příchozí volání, jako je trigger Požadavku, v současné době nepodporují otevřené ověřování Microsoft Entra ID (Microsoft Entra ID OAuth), zatímco jiné jako trigger HTTP Webhook mají tuto podporu.

  • Některé integrované konektory založené na poskytovatelích služeb v současné době nepodporují výběr spravované identity přiřazené uživatelem pro ověřování. Podpora spravované identity přiřazená systémem i spravovaná identita přiřazená uživatelem jsou ale obecně dostupná. Ve výchozím nastavení je spravovaná identita přiřazená systémem automaticky povolená.

• Ladění zarážek v editoru Visual Studio Code: I když můžete přidávat a používat zarážky uvnitř souboru workflow.json pro pracovní postup, zarážky se podporují jenom pro akce v tuto chvíli, ne pro triggery. Další informace najdete v tématu Vytváření pracovních postupů založených na jednom tenantovi v nástroji Visual Studio Code.

• Historie triggerů a historie spuštění: Pro pracovní postup standardní aplikace logiky se historie triggerů a historie spuštění na webu Azure Portal zobrazují na úrovni pracovního postupu, ne na úrovni prostředku aplikace logiky. Další informace najdete v tématu Vytvoření pracovních postupů založených na jednom tenantovi pomocí webu Azure Portal.

• Šablony Terraformu: Tyto šablony nemůžete použít s prostředkem aplikace logiky Standard pro úplné nasazení infrastruktury. Další informace najdete v tématu Co je Terraform v Azure?

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

Pokud vaše prostředí má 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í ve vašich pracovních postupech. Volitelně můžete povolit provoz ze značek služeb a použít stejnou úroveň omezení nebo zásad jako služba Aplikace Azure Service. Musíte také najít a použít plně kvalifikované názvy domén (FQDN) pro vaše připojení. Další informace najdete v odpovídajících částech následující dokumentace:

• Oprávnění brány firewall pro aplikace logiky jednoho tenanta – Azure Portal
• Oprávnění brány firewall pro aplikace logiky jednoho tenanta – Visual Studio Code

Další kroky

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

Rádi bychom také slyšeli o vašich zkušenostech s Azure Logic Apps s jedním tenantem!

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